T3 Connect: managed cloudflared keeps dead connections after host IPv6 prefix change; health check detects no_connector but doesn't restart relay client #24936

What happened

T3 Connect's managed cloudflared kept dead connections after the host's dynamic IPv6 prefix changed. T3's external health check detected no_connector but did not restart the managed relay client, leaving the mobile app showing the host offline until cloudflared was killed manually.

Timeline on 2026-10-26, local CST (UTC+8):

• 01:09:53–01:14:58: The home router was restarted. The host lost its default route and DNS (the router is the resolver). Managed cloudflared crash-looped with lookup ... argotunnel.com on 127.0.0.53:53: no such host; T3 restarted it correctly (connector_not_running → restart). That part worked fine.
• 01:14:52: The router briefly re-advertised the OLD IPv6 prefix. 01:14:59–01:15:01: cloudflared registered four connections (khh01/tpe01) using a source address from the old prefix. 01:15:05: T3 logged "T3 Connect is reachable from other devices. Tunnel connected · 4 connections · HTTP2".
• 01:15:05: The router switched to a NEW IPv6 prefix. The old address remained on the interface as deprecated (preferred_lft 0) but was no longer routable upstream. All four tunnel connections silently died.
• 01:15:39: T3 logged origin_unreachable. 01:19:41: T3 logged ✕ T3 Connect is NOT reachable from other devices — Cloudflare has no live connection from this machine for the tunnel. cause: no_connector, and advised "Restart T3 Code".
• Meanwhile local cloudflared reported healthy: /ready returned {"status":200,"readyConnections":4}, metrics showed cloudflared_tunnel_ha_connections 4 and zero request errors. Requests to https://prod-40c55292cc53fb43.t3coderelay.com/ returned HTTP 530 / Cloudflare error 1033. The mobile T3 Code app showed the host offline.
• T3 did not restart the relay client after detecting no_connector. It stayed broken for at least approximately six minutes, until cloudflared was killed manually at 01:21:19. T3 respawned it, it registered four connections from the new prefix within approximately three seconds, T3 logged "reachable" at 01:21:25, and the public URL returned 200.

Diagnosis

The supplied incident evidence indicates stale local cloudflared connection accounting after the IPv6 source prefix becomes unusable: local readiness still claims four live connections while Cloudflare reports no connector. T3 detects the external failure but does not recover by restarting the managed client. This diagnosis is based on the user's recorded timeline and observations; no independent source-level root-cause confirmation is claimed.

Steps to reproduce

Observed sequence (network timing dependent):

1. Run T3 Connect with managed cloudflared using HTTP2 and connecting to Cloudflare edges over IPv6, behind a router advertising a dynamic IPv6 prefix via RA.
2. Restart the router, temporarily losing default route and DNS.
3. Let the router briefly advertise the old prefix so cloudflared registers four connections using it.
4. Switch to a new IPv6 prefix while retaining the old host address as deprecated but no longer routable upstream.
5. Observe local readiness continuing to claim four connections, public endpoint HTTP 530 / error 1033, and T3 health check no_connector without an automatic managed-client restart.

Expected behavior

When T3's health check gets no_connector (Cloudflare reports no live connector) while local cloudflared still claims ready connections, treat the connector as stale and restart managed cloudflared automatically, perhaps after a short grace period or consecutive failures, rather than only logging "Restart T3 Code".

Possible additional hardening: restart the managed relay client on host network/address changes (IPv6 prefix or default-route changes), and/or offer an option to pin cloudflared to IPv4 (--edge-ip-version 4) for hosts with unstable IPv6 prefixes.

Version

Server and triage CLI: 0.1.2-nightly.20261021.3473.

Environment

• Host: the-cocoon; Linux x64, CachyOS (kernel 7.3.0-2-cachyos).
• Managed cloudflared 2026.10.0, protocol HTTP2.
• Tunnel: t3coderelay-managedendpoint-prod-40c55292cc53fb43.
• Home router on HiNet, Taiwan; dynamic IPv6 prefix via RA; cloudflared connects to Cloudflare edges over IPv6.
• Affected client: mobile T3 Code app.

Evidence

The timestamps, log messages, readiness response, metrics, and public HTTP results above were supplied by the user. No raw log files, diagnostics, machine-context file, tokens, email addresses, or public host IP addresses are attached.

Related issues

Searches for no_connector and cloudflared IPv6 did not identify a matching issue. #8035 concerns environment discovery and #16810 concerns link provisioning returning 504; neither describes established tunnel connections becoming stale after a host IPv6 prefix change.

Fix applied or workaround

During the incident the user ran pkill -f 'cloudflared tunnel', after which T3 respawned cloudflared and connectivity recovered. Restarting T3 Code is another workaround. No services were restarted or configuration changed while filing this report.

Filed by

Codex agent, gpt-6.1-sol, following the t3 triage workflow on the affected machine. Submission explicitly authorized by the user.