Repository navigation
[Bug]: The QUIC → HTTP/2 fallback is lost on every server restart, so each update brings back minutes of 530 on QUIC-hostile networks #26513
Description
Before submitting
- I searched existing issues and did not find a duplicate. (T3 Connect: let users force the managed cloudflared to HTTP/2 — on QUIC-blocking corporate networks the tunnel stays down because cloudflared won't fall back #16344 added the automatic QUIC → HTTP/2 switch; [Bug]: Every server restart takes T3 Connect remote access down for 1–1.5 minutes: HTTP and the tunnel both wait for DB recovery, and the client backs off up to 5 minutes #24661 covers the restart gap itself. This report is about the switch being lost across restarts.)
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- Run T3 Code with T3 Connect on a network where QUIC to the tunnel edge (UDP 7844) stalls but TCP 7844 works. Here: macOS behind a TUN-mode proxy.
- Wait for
ManagedEndpointRuntimeto seeQUIC_STALLS_BEFORE_HTTP2stalls and restart cloudflared with--protocol http2. The tunnel is then healthy. - Restart the server or desktop app (here an auto-update restart: "Keeping the managed tunnel across the update restart").
Expected behavior
The connector keeps using HTTP/2 after the restart, because this machine has already shown that QUIC does not work for it.
Actual behavior
http2Ref is Ref.make(false) inside the runtime (apps/server/src/cloud/ManagedEndpointRuntime.ts, around L197), so every new server process starts cloudflared with protocol: "auto" again and has to relearn the fallback. Timeline from server.trace.ndjson (local time, UTC+8, 2026-10-28):
- 20:40:51 update restart; 20:41:00 relay client started,
protocol: "auto"; 20:41:06Tunnel connected · 4 connections · QUIC - 20:45:33
cloudflared has not connected to Cloudflare yet(0 ready connections) - 20:47:18 relay client restarted with
protocol: "http2" - 20:52:22
Tunnel connected · 4 connections · HTTP2
Before the restart, the same machine had been on HTTP/2 with 4 connections (20:32).
Impact
Each restart on such a network costs several minutes of HTTP 530 for remote clients, including outside MCP agents that reach the environment only through T3 Connect. Nightly updates restart often, so this keeps happening.
Version or commit
v0.1.4-nightly.20261028.3824 (desktop), managed cloudflared 2026.10.4. Same code on main @ 5211acf.
Environment
macOS (Apple silicon), desktop app with the bundled server, T3 Connect managed tunnel, system-wide TUN proxy.
Logs or stack traces
Relay client start events from the trace (ids omitted):
20:41:00 Relay client process started; waiting for tunnel connection { version: "2026.10.4", protocol: "auto" }
20:47:18 Relay client process started; waiting for tunnel connection { version: "2026.10.4", protocol: "http2" }
Workaround
Set TUNNEL_TRANSPORT_PROTOCOL=http2 in the server's environment (on macOS: launchctl setenv before T3 Code starts). T3 then treats it as the user's choice.
Suggestion
Persist the fallback, for example in server state per network or with a TTL, or start with HTTP/2 when the previous run had to fall back.
Activity
Matt-BF commentedon Oct 29, 2026
Hey t3 team! First of all, thanks for this great software, It has been quite useful for my workflow in bio research.
I think I'm having a similar issue. I'm running t3 code inside an HPC environment, and trying to connect to it via t3 connect from my desktop app. The connection keeps falling randomly, and when I first try to start in the morning it takes quite a long time to actually connect the environments. If it helps, here's what codex (GPT-6.1-Sol medium, CLI) via
t3 triagehas suggested: