WebSocket /api/remote.mux fails behind Cloudflare Tunnel (HTTP/2 edge)

[afonsoft]

Summary

DeepSeek Harness Web UI fails to establish the WebSocket connection to /api/remote.mux when served behind Cloudflare Tunnel. The browser-trust fence and authentication work correctly, but the WebSocket upgrade is rejected (404) because Cloudflare edge speaks HTTP/2 to the browser, and HTTP/2 does not support the Upgrade: websocket header — it uses Extended CONNECT (RFC 8441) instead.

Environment

• @deepseek-ai/dsh 0.1.0-rc.7
• dsh web --no-open --trusted-host harness.afonsoft.dev
• Behind Cloudflare Tunnel (cloudflared) → nginx reverse proxy → 127.0.0.1:3080
• Browser: Chrome 152 (HTTP/2 + HTTP/3 to Cloudflare edge)

Symptoms

1. Browser console:

   WebSocket connection to wss://harness.afonsoft.dev/api/remote.mux failed
   [connection] connection lost, retry #1
   

2. The Models page shows:

   Loading the provider directory failed: settings are unavailable in this browser
   

3. The settings.describe RPC (which the Models page reads through the WebSocket mirror) never loads because the WebSocket never establishes.

4. SSE stream also fails:

   GET https://harness.afonsoft.dev/plugins/events net::ERR_QUIC_PROTOCOL_ERROR 200 (OK)
   EventSource response has MIME type text/plain instead of text/event-stream
   

Diagnosis

Test	Protocol	Result
curl --http1.1 to /api/remote.mux with WS upgrade	HTTP/1.1	101 OK
curl (default HTTP/2) to /api/remote.mux with WS upgrade	HTTP/2	404 FAIL
Direct to 127.0.0.1:3080 (bypass Cloudflare)	HTTP/1.1	101 OK
Via nginx 127.0.0.1:80 (bypass Cloudflare)	HTTP/1.1	101 OK

The WebSocket works at every layer except through Cloudflare HTTP/2 edge. Cloudflare Tunnel HTTP origin service does not translate HTTP/2 Extended CONNECT to HTTP/1.1 Upgrade: websocket for the origin.

The SSE /plugins/events stream also fails with ERR_QUIC_PROTOCOL_ERROR when HTTP/3 (QUIC) is enabled.

Workaround

Disabling HTTP/2 and HTTP/3 in the Cloudflare dashboard for the zone forces HTTP/1.1 between browser and edge, which supports Upgrade: websocket natively. This is not ideal for performance on other subdomains sharing the same zone.

Request

1. Consider documenting Cloudflare Tunnel as a supported reverse proxy with the required configuration.
2. Consider whether the WebSocket mux could fall back to HTTP long-polling or SSE when the WebSocket upgrade fails, so the UI degrades gracefully behind HTTP/2-only proxies.
3. The SSE /plugins/events stream should handle QUIC/HTTP/3 interruptions more gracefully (reconnect with backoff).

Reproduction

# Works (HTTP/1.1 forced):
curl --http1.1 -o /dev/null -w "%{http_code}" \
  "https://your-domain/api/remote.mux" \
  -H "Connection: Upgrade" -H "Upgrade: websocket" \
  -H "Sec-WebSocket-Version: 13" -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
  -b "dsh-auth-xxx=yyy"
# → 101

# Fails (HTTP/2 default):
curl -o /dev/null -w "%{http_code}" \
  "https://your-domain/api/remote.mux" \
  -H "Connection: Upgrade" -H "Upgrade: websocket" \
  -H "Sec-WebSocket-Version: 13" -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
  -b "dsh-auth-xxx=yyy"
# → 404

[sambouli]

Workaround

Disabling HTTP/2 and HTTP/3 in the Cloudflare dashboard for the zone forces HTTP/1.1 between browser and edge, which supports Upgrade: websocket natively. This is not ideal for performance on other subdomains sharing the same zone.

And free plans cannot even disable HTTP/2...