[Bug] T3 Connect: Relay environment endpoint unavailable on CachyOS x86_64 #7139

Activity

1. sguergachi

   changed the title [-]T3 Connect: Relay environment endpoint unavailable on CachyOS x86_64[/-] [+](Bug) T3 Connect: Relay environment endpoint unavailable on CachyOS x86_64[/+] on Aug 15, 2026
2. sguergachi

   changed the title [-](Bug) T3 Connect: Relay environment endpoint unavailable on CachyOS x86_64[/-] [+][Bug] T3 Connect: Relay environment endpoint unavailable on CachyOS x86_64[/+] on Aug 15, 2026
3. codewarnab commented on Sep 8, 2026

   

   codewarnab

   on Sep 8, 2026

   Last edited by codewarnab

   More actions

   Can confirm this exact behavior on CachyOS x86_64 (7.2.3-1-cachyos) running t3code.service under systemd --user.

   What is actually happening (Root Cause):

   This is not a CachyOS/kernel incompatibility, but a port desync in the T3 Connect relay lifecycle:

   1. The local server is healthy:
      Locally on the box, t3 serve is running and curl -i http://127.0.0.1:<port>/ returns HTTP 200 with the full web app.
   2. The Cloudflare tunnel is connected:
      cloudflared tunnel run is actively connected to Cloudflare edge locations with QUIC.
   3. The port desync:
      When t3code.service starts or restarts, t3 serve picks an ephemeral/dynamic loopback port (e.g. 3773) if none is explicitly specified.
      However, the managed Cloudflare Tunnel / T3 Connect relay link routes incoming traffic to whatever local port was registered when t3 connect link was run.
      When the service restarts or the port changes, incoming requests forwarded through the relay hit a dead local port (ECONNREFUSED), returning a 502 to the relay, which surfaces in the client as:
      Relay environment endpoint is unavailable: endpoint_request_failed.

   Temporary Workarounds:

   • Re-run npx t3 connect link on the box so the relay receives the current port.
   • Or pin the port in ~/.config/systemd/user/t3code.service by adding --port <port> to ExecStart.

   This is directly related to #7458 and should be resolved by PR #8353 (fix(server): use listener port for managed tunnel origins).

   cc @juliusmarminge @mateo-m
4. juliusmarminge commented on Oct 2, 2026

   

   juliusmarminge

   on Oct 2, 2026

   Member

   More actions

   Thanks for taking the time to report this and provide the details. We revisited it during the orchestrator V2 cleanup.

   The specific port-desynchronization cause supplied in the latest comment is addressed: startup derives the origin from the actual listening address.port and registers managed-tunnel recovery using that origin.

   I’m closing this based on the current source and the evidence in this thread.

   Source reviewed.

   Original generic endpoint_request_failed can have other causes; closure applies to the diagnosed stale-port case, not every relay failure.

   If you still hit this on a current build, please reply with the app/server versions and the steps that reproduce it. We can reopen this if the original problem is still there.
5. juliusmarminge

   closed this as completedon Oct 2, 2026