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

**URL:** <https://community.fly.io/t/wireguard-tunnel-fails-behind-corporate-tls-inspection-101-expected-got-200-network-team-confirms-the-url-itself-isnt-blocked/28576>\
**Category:** Questions / Help\
**Tags:** flyctl\
**Created:** [August 31, 2026, 4:52pm UTC](https://community.fly.io/t/wireguard-tunnel-fails-behind-corporate-tls-inspection-101-expected-got-200-network-team-confirms-the-url-itself-isnt-blocked/28576 "2026-08-31T16:52:52Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![melogna](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/melogna/32/50029_2.png) [@melogna](https://community.fly.io/u/melogna)\
**Post date:** [August 31, 2026, 4:52pm UTC](https://community.fly.io/t/wireguard-tunnel-fails-behind-corporate-tls-inspection-101-expected-got-200-network-team-confirms-the-url-itself-isnt-blocked/28576/1 "2026-08-31T16:52:52Z")

</div>

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:**

```auto
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:

```auto
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”?

---

<div class="post-metadata">

**Author:** ![PeterCxy](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/petercxy/32/36155_2.png) [@PeterCxy](https://community.fly.io/u/PeterCxy)\
**Post date:** [August 31, 2026, 5:37pm UTC](https://community.fly.io/t/wireguard-tunnel-fails-behind-corporate-tls-inspection-101-expected-got-200-network-team-confirms-the-url-itself-isnt-blocked/28576/2 "2026-08-31T17:37:19Z")

</div>

> [@melogna](#):
>
> something more specific than “is the domain blocked” I should ask our network team to check

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

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/fly1/original/3X/6/e/6e8955d00cb218e186ebbe3a6ab06fefdce15290.svg) [@system](https://community.fly.io/u/system)\
**Post date:** [September 11, 2026, 4:36pm UTC](https://community.fly.io/t/wireguard-tunnel-fails-behind-corporate-tls-inspection-101-expected-got-200-network-team-confirms-the-url-itself-isnt-blocked/28576/5 "2026-09-11T16:36:28Z")

</div>

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.