The relay connection, and only it and update downloads, goes through the proxy
HTTPS_PROXY or ALL_PROXY names (short of NO_PROXY), else the system's: macOS's
network settings, Windows's Internet settings, GNOME's. It asks an HTTP proxy
to CONNECT, with the name and password the proxy URL holds, and trusts the
certificates the system trusts, so a proxy that inspects HTTPS works once the
system trusts its authority. SMB never goes through it.

Where something on the way refuses the WebSocket, the app joins the same room
with ?poll=1 instead: GET /v1/poll/<id> waits for what is to come and POST
sends, each body a run of WebSocket frames, so the relay hears the same
messages either way. This needs the new relay; deploy it.

Why the relay can't be reached is told apart and said with what to try: its
name not found, nothing answering (a firewall), no answer in time, the proxy
not there, the proxy asking for a password, the proxy refusing (its status),
a certificate the system doesn't trust, or the network blocking the relay.

Tested through a local proxy that asks for a password, one that refuses
WebSockets inside its tunnels (the guest then joins and publishes by
polling), a proxy that isn't there and a relay name that doesn't resolve.

Assisted-by: claude-opus-5.5