Cloudflare Tunnel Error 1033: 7 Fixes in Order

Cloudflare’s error 1033 entry is short, and it is the whole diagnosis in one sentence: “Your tunnel is not connected to Cloudflare’s network because Cloudflare’s network cannot find a healthy cloudflared instance to receive the traffic.”

That narrows the problem enormously. The request reached Cloudflare. DNS worked. Cloudflare knows which tunnel should serve that hostname. What it could not find was a live connector on the other side. Everything that follows is about why a connector that used to be there is not there now.

First: is it really a 1033?

Tunnel errors point at different segments of the path, and treating them as interchangeable is the most reliable way to waste an afternoon.

Symptom	What it means	Where to look
Error 1033	Cloudflare cannot find a healthy cloudflared instance	The connector host: process, egress, credentials
502 Bad Gateway	The tunnel is connected, but cloudflared cannot reach your origin service	The service itself: is it running, right port, right protocol
ERR_TOO_MANY_REDIRECTS	cloudflared does not recognise the TLS certificate the origin presents	Set originServerName to the hostname on the origin’s certificate
x509: certificate signed by unknown authority	The origin’s certificate is not trusted by the connector, often because a proxy is doing TLS inspection between the two	Trust the issuing CA, or point --origin-ca-pool at it
”cloudflared service already installed”	A second service install attempted on one machine	Only one cloudflared service is allowed per machine

A 1033 and a 502 point at opposite ends of the same path. A 502 is actually good news in the sense that the tunnel itself is healthy. If you are seeing 502s, stop reading this and check whether the service listens on the port your ingress rule names, using curl from the connector host and ss or lsof to confirm the binding.

The diagnostic order for a 1033

Run these in sequence. Each one is cheap, and doing them out of order is how people end up rebuilding a working tunnel.

1. Ask Cloudflare what it thinks the tunnel status is. The documented first step is to check the tunnel’s status in the dashboard or with cloudflared tunnel list. Healthy, Inactive, Down and Degraded each send you somewhere different. Inactive means no connector has ever registered. Down means one did and stopped.

2. Check whether the connector process is alive on the host. This is the single most common cause, and it is almost always mundane: the host rebooted and the daemon was never installed as a service, a foreground cloudflared tunnel run was killed when an SSH session closed, the process crashed, or the machine is simply off. Cloudflare’s own guidance for a Down tunnel is to confirm the service is running and to rule out server-side problems such as power loss or a crash.

3. Confirm outbound egress still works. A connector that was healthy for months can 1033 the morning after a firewall change. cloudflared needs outbound port 7844 over TCP for HTTP/2 and UDP for QUIC, reaching region1.v2.argotunnel.com and region2.v2.argotunnel.com. If the firewall enforces SNI, cftunnel.com, h2.cftunnel.com and quic.cftunnel.com must be allowed as well. Port 443 outbound is used optionally for update checks and feature discovery.

A specific trap here: if UDP/7844 gets blocked but TCP/7844 stays open, the connector can still come up over HTTP/2, so the tunnel looks fine while QUIC is quietly unavailable. Egress that is blocked entirely produces the clean 1033.

4. Read the connector’s own logs. The daemon says why it cannot connect. Authentication failures, DNS resolution failures for the argotunnel endpoints, and refused connections each look different in the log and each point at a different fix. Guessing before reading the log is how a firewall problem gets misdiagnosed as a credentials problem.

5. Check the credentials file still exists at the path the config names. For a locally-managed tunnel, config.yml names a credentials-file written when the tunnel was created. Host rebuilds, container images that do not persist ~/.cloudflared/, and configuration management that copies config.yml but not the credentials JSON all produce a connector that starts and cannot register.

6. Confirm the DNS record still points at this tunnel. cloudflared tunnel route dns creates a CNAME to <UUID>.cfargotunnel.com. If the tunnel was deleted and recreated, the UUID changed and the old record now points at a tunnel that no longer exists, which is a textbook 1033. A record that was later un-proxied is another variant of the same failure.

7. Confirm the hostname is still in the ingress rules or routes. For remotely-managed tunnels, check the tunnel’s Routes tab. For locally-managed tunnels, check config.yml. Remember that ingress rules are evaluated “from top to bottom to find which rule matches the request,” so a broad rule inserted above a specific one can capture traffic that was meant for a hostname further down, and the last rule must be a catch-all such as http_status:404.

Causes that look like something else

Only some users see the error. Cloudflare routes a request to the geographically closest replica. If one replica of a multi-replica tunnel is dead and others are healthy, the failure is regional rather than global. Check every replica, not just the one you happen to be logged into.

It fails intermittently and fixes itself. A connector that is flapping, or a host with a scheduled job that saturates it, will produce intermittent 1033s. The tunnel status history is more useful than a single point-in-time check.

It broke right after a config change. A config.yml that fails to parse means the daemon does not start, which presents as a 1033 rather than as a configuration error in the browser. Validate the file and restart under supervision so you see the startup output.

It broke right after a certificate or token rotation. Regenerating a tunnel token without updating the running connector leaves the daemon holding credentials Cloudflare no longer accepts.

Stopping it from happening again

Most 1033 incidents are availability problems wearing an error code, so the fixes are availability fixes.

Run it as a service, not in a terminal. A connector that does not survive a reboot will eventually not survive a reboot at the worst possible moment. One cloudflared service per machine is the documented limit.

Run replicas on separate hosts. Each cloudflared instance already opens four outbound connections to four Cloudflare servers across at least two data centers, which covers edge-side failure. It does nothing for the host dying. Additional replicas of the same tunnel on different machines cover that.

Two caveats shape how you use replicas. They do not support traffic steering: Cloudflare forwards to the closest replica and fails over, but you cannot control which one serves a request, so nothing stateful should assume affinity. And private hostname routes are not currently compatible with Load Balancing, so replicas are the redundancy mechanism there rather than a load balancer.

Alert on tunnel health, not on the hostname. Monitoring the public hostname tells you a user is already affected. Monitoring connector status tells you a replica died while the others still carry traffic, which is the moment worth waking someone for.

Keep the credentials with the config. Whatever provisions the host should place config.yml and the credentials JSON together, so a rebuild produces a working connector instead of one that starts and cannot register.

Write down which tunnel serves which hostname. After a year, the reason nobody can fix a 1033 quickly is that nobody remembers which of the account’s tunnels is supposed to answer for that name.

Related reading

If you are building the tunnel rather than repairing one, the step-by-step first tunnel walkthrough covers the prerequisites, both setup paths and the ingress rules whose ordering causes so many of these failures.

For the layer above the tunnel, Zero Trust access and tunnels instead of VPN ingress explains why closing the inbound port is only half the job, and Cloudflare Access compared with Tailscale covers when a proxied model is the right shape at all.

To plan replica counts before an incident forces the question, the tunnel and Access planning calculator gives first-pass figures with its assumptions stated on the page.