Bug description
When configuring a Cloudflare Named Tunnel with an existing stable hostname, provisioning can report success even though that hostname still points to a different tunnel ID.
In this state:
- the local C2C bridge is healthy;
- local MCP and OAuth discovery endpoints work correctly;
- the current Named Tunnel is healthy and has active Cloudflare edge connections;
- but the public hostname returns Cloudflare
530 / error 1033;
- the C2C tunnel state references the current tunnel, while DNS still routes the hostname to another tunnel.
Environment
- Windows
- cloudflared
2026.8.3
- Cloudflare Named Tunnel
- A stable hostname that had previously been used with another C2C tunnel
Observed behavior
The current C2C state referenced:
tunnelName: c2c-<workspace-id>
tunnelId: <CURRENT_TUNNEL_ID>
hostname: c2c.example.com
provider: cloudflare-named
Both:
cloudflared tunnel list --output json
and:
cloudflared tunnel info <tunnel-name>
showed <CURRENT_TUNNEL_ID> as healthy, with an active connector and active edge connections.
The running cloudflared process was also using the same current tunnel.
However, the existing Cloudflare DNS record still pointed to:
c2c.example.com
CNAME
<DIFFERENT_TUNNEL_ID>.cfargotunnel.com
So the effective state was:
C2C state:
<CURRENT_TUNNEL_ID>
cloudflared tunnel list:
<CURRENT_TUNNEL_ID>
running cloudflared process:
<CURRENT_TUNNEL_ID>
stable hostname DNS target:
<DIFFERENT_TUNNEL_ID>
Public requests to /mcp and the OAuth discovery endpoints therefore returned:
HTTP 530
error code: 1033
while the equivalent local endpoints were healthy.
Suspected cause
In src/tunnel/named-provision.ts, routeDns() treats messages matching:
already exists
duplicate
exists as a cname
as benign:
if (result.ok || isBenignRouteError(`${result.stdout}\n${result.stderr}`)) return;This appears to allow provisioning to continue when the hostname already exists, without verifying that the existing CNAME target actually points to the current tunnel ID.
As a result, the saved C2C tunnel state can reference Tunnel A while the public hostname still routes to Tunnel B.
Expected behavior
When a Named Tunnel uses an already-existing hostname:
- Verify that the hostname currently routes to the selected/current tunnel ID.
- If it already points to
<CURRENT_TUNNEL_ID>.cfargotunnel.com, treat it as success.
- If it points to a different tunnel ID, either:
- update the route safely; or
- return an explicit mismatch/repair state.
- Ideally,
c2c doctor should also detect the condition:
current tunnel healthy + stable hostname routed to a different tunnel.
This would prevent a misleading state where the local tunnel appears healthy while the public hostname consistently returns Cloudflare 1033.
Bug description
When configuring a Cloudflare Named Tunnel with an existing stable hostname, provisioning can report success even though that hostname still points to a different tunnel ID.
In this state:
530 / error 1033;Environment
2026.8.3Observed behavior
The current C2C state referenced:
Both:
and:
showed
<CURRENT_TUNNEL_ID>as healthy, with an active connector and active edge connections.The running
cloudflaredprocess was also using the same current tunnel.However, the existing Cloudflare DNS record still pointed to:
So the effective state was:
Public requests to
/mcpand the OAuth discovery endpoints therefore returned:while the equivalent local endpoints were healthy.
Suspected cause
In
src/tunnel/named-provision.ts,routeDns()treats messages matching:as benign:
This appears to allow provisioning to continue when the hostname already exists, without verifying that the existing CNAME target actually points to the current tunnel ID.
As a result, the saved C2C tunnel state can reference Tunnel A while the public hostname still routes to Tunnel B.
Expected behavior
When a Named Tunnel uses an already-existing hostname:
<CURRENT_TUNNEL_ID>.cfargotunnel.com, treat it as success.c2c doctorshould also detect the condition:current tunnel healthy + stable hostname routed to a different tunnel.This would prevent a misleading state where the local tunnel appears healthy while the public hostname consistently returns Cloudflare 1033.