StartOS 0.4.0, Holesail package (server mode), holesail npm client on macOS (Node 20.11.1).
Setup
Manage Tunnels → Add → Service: StartOS, Service Interface: Admin UI, Public: off. Connection string retrieved from View Connections.
Client behavior
The default holesail --connect <string> fails immediately:
Error: listen EADDRNOTAVAIL: address not available
code: 'EADDRNOTAVAIL',
syscall: 'listen',
port: 80
It appears to inherit the server-side bind address and port. Overriding both starts the client cleanly:
holesail --connect <string> --host 127.0.0.1 --port 9977
Holesail TCP Client Started
Connection Mode: Private Connection String
Access application on http://127.0.0.1:9977/
The problem
With the client running, the tunnel accepts TCP but nothing ever responds:
-
curl -v http://127.0.0.1:9977→ connects, full HTTP request sent, zero bytes returned -
curl -vk https://127.0.0.1:9977→ connects, TLS Client Hello sent, no Server Hello -
Browser:
ERR_EMPTY_RESPONSEon http,ERR_CONNECTION_CLOSEDon https
Suspected cause
My StartOS admin UI is at https://192.168.0.41 — base address, standard port 443, no port suffix. The client’s initial EADDRNOTAVAIL on port 80 suggests the tunnel is bound to port 80 rather than 443, which would explain a connection that opens and then never speaks.
The Manage Tunnels dialog exposes only Service, Service Interface, and Public — there’s no port field — so there’s nothing I can adjust from the UI. Deleting and recreating the tunnel made no difference. “Admin UI” appears to be the only relevant Service Interface option.
Questions
-
Is the Admin UI interface expected to map to 443, and is it possible this is resolving to 80?
-
Is there any way to specify the port, or a different interface I should be selecting?
-
Has anyone gotten a Holesail tunnel to the StartOS admin UI working on 0.4.0?
Possibly related
I hit a similar-shaped failure with the Tailscale package on the same machine — node signs in fine, MagicDNS resolves, HTTPS certificates enabled, but Tailscale Serve to the StartOS UI returns HTTP 502, while serving Tailscale’s own admin interface over HTTP works normally. (There’s an existing thread on that with Tailscale 1.98.9:1; I’m on 1.98.9:2 and see the same thing, so the newer package revision doesn’t fix it.)
Two independent packages both establishing their tunnel correctly but failing to reach the StartOS UI backend makes me wonder whether they’re resolving the admin UI’s interface address the same way, and getting it wrong. Might be worth a look at that shared assumption.