Gateway authenticates request but it never reaches server (401, no request_id) — reproduced independently on 3 self-hosted servers

### MCP server URL

https://[REDACTED-TAILSCALE-FUNNEL-HOSTNAME]/proxmox/sse

### Where does the issue occur?

During a conversation (after initial auth)

### Transport used

streamable-http

### Client registration type

Dynamic Client Registration (DCR)

### SSE only: Does your server return the expected status code for POST requests?

Not applicable (my server does not use SSE)

### When did you last reproduce this?

2026-08-24, ~4:41 PM EDT (20:41 UTC per gateway logs)

### Browser and OS

N/A — server-to-server, not a browser. The client making the call is Claude.ai's own connector-calling infrastructure. My server runs in Docker on a Debian 12 host.

### Describe the issue

Gateway authenticates the request successfully, but it never reaches my MCP server's own code -- confirmed via debug instrumentation at the application layer and at supergateway's own request handler, cross-checked against gateway auth logs showing the same window as successful. Reproduced independently on 3 separate self-hosted servers with different codebases.

### Issue details

```shell
Ruled out, in order, most recently confirmed at the timestamp above:
1. Stale OAuth grant -- used Disconnect/Reconnect in Settings, Connectors. Confirmed a complete, clean OAuth handshake in the gateway's own logs.
2. Stale/incorrect API token -- tested the exact token the running container held, directly against the backend API, from inside the container. Got a clean 200.
3. Stale in-process credential object -- force-restarted the container directly (not an idempotent compose up, which wouldn't have recreated it). The 401 persisted immediately after.
4. Wrong token ID / API URL / TLS config -- verified all relevant env vars matched exactly what the successful manual test used.
5. Request never reaching the MCP server's own application code -- added debug logging inside the request-handling function (fires on every call, before any outbound API call). Confirmed live, restarted, triggered the failure again: zero log output, despite the gateway logging successful auth for the same window.
6. Request never reaching supergateway's own code -- added debug logging at the literal first line of supergateway's Express POST handler, before session lookup or anything else. Same result: confirmed live, restarted, triggered again: zero log output.
7. Mixed public/private DNS on the Funnel hostname -- queried the hostname against public DNS directly. Both returned addresses are ordinary public IPs, nothing private/CGNAT.

Notably, the 401 returned is the bare string "Error: Request failed with status code 401", without a request_id, unlike other connector-level errors seen the same day (hostname-resolution-style messages, which do include one).
Same pattern reproduced independently on two other self-hosted servers with completely different application code (a Plex management server and a 1Password server), both freshly rebuilt during this investigation -- same signature: gateway logs show successful auth, but the request never reaches the server's own code, confirmed via the same debug-instrumentation technique on each.
```

### Expected behavior

The tool call should either succeed -- which a direct manual test against the same backend, using the same token, confirms it should -- or fail with an error that's actually traceable server-side. Instead it fails with a bare 401 that never appears in any log I have access to, gateway included.

### Logs from your server

```shell
Gateway logs (oauth proxy in front of my MCP server), showing successful auth in the exact window a 401 was returned to Claude.ai:

2026-08-24T20:41:14.615Z POST /sse auth=yes
2026-08-24T20:41:15.058Z POST /sse auth=yes
2026-08-24T20:41:15.310Z GET /sse auth=yes
2026-08-24T20:41:17.988Z POST /sse auth=yes
2026-08-24T20:41:18.363Z POST /sse auth=yes
2026-08-24T20:41:18.612Z GET /sse auth=yes

My own server's application logs and supergateway's own request-handler logs show nothing at all for this same window -- confirmed via debug instrumentation added at both layers (see Issue details above).
```

### Additional context

Happy to share the actual server URL and any account/org identifiers privately with the Anthropic team if that helps -- omitted above since it's a personal Tailscale Funnel domain tied to my family name.

Also seeing this same failure signature (auth succeeds at the gateway, request never reaches the server) referenced in #111, #199, #209, #214, #227, and #374 -- possibly the same underlying issue across all of these.