WireGuard tunnel fails behind corporate TLS inspection (101 expected, got 200) — network team confirms the URL itself isn't blocked

Questions / Help Build debugging
1

I’m trying to get flyctl postgres connect / flyctl ssh console working from a machine on a corporate network that does TLS inspection, and the WireGuard tunnel won’t establish.

The confusing part: our network/security team checked and confirmed the domain itself is not on any block list. So this isn’t a simple “URL denied” situation — whatever’s happening is more specific than that.

Error:

flyctl doctor
Testing authentication token... PASSED
Testing flyctl agent... PASSED
Testing local Docker instance... PASSED
Pinging WireGuard gateway... FAILED
(Error: wireguard ping gateway: pinger: websocket: failed to WebSocket dial: expected handshake response status code 101 but got 200)

From the flyctl agent logs, the actual connection attempt is:

srv (re-)connecting to wss://iad3.gateway.6pn.dev:443/
"...websocket: failed to WebSocket dial: expected handshake response status code 101 but got 200"

It’s reaching the gateway fine, on port 443 — not a port block. The response just comes back as a plain 200 instead of the 101 Switching Protocols a WebSocket upgrade needs. That’s consistent with a TLS-inspecting proxy that decrypts and re-proxies the HTTPS connection but doesn’t pass the Upgrade: websocket handshake through for this host — which would explain why a straightforward “is this URL blocked” check comes back clean while the actual connection still fails.

What I’ve tried:

  • flyctl wireguard reset — no change
  • flyctl wireguard websockets enable + flyctl agent restart — identical error, even with the websockets-over-HTTPS fallback already active
  • Confirmed with our network team: the domain isn’t blocked at the URL/category level

Environment: Windows, flyctl v0.4.95, corporate network with TLS-inspecting proxy/firewall (exact product unknown to me).

Question: Given this fails even with the websockets fallback on, is there something more specific than “is the domain blocked” I should ask our network team to check — e.g., whether their inspection layer allows WebSocket Upgrade headers through for *.gateway.6pn.dev specifically? Is there a way to get flyctl to show the actual request/response headers during the handshake, so I can hand them something more concrete than “it fails”?

2

You should ask and confirm whether there is a HTTP proxy on your network and whether that proxy supports Websockets correctly.