How is 1033 different from 521, 522, and 523?

They fail at different layers. Errors 521 (connection refused), 522 (timeout), and 523 (origin unreachable) are about Cloudflare trying to reach your origin server over a normal network connection and failing. Error 1033 is about a Cloudflare Tunnel: the hostname is configured to be served through a cloudflared connector instead of a direct origin, and the edge can't find a healthy connector to hand the request to. There's nothing for Cloudflare to connect *to* — the tunnel side is simply absent. So 521–523 point you at firewall and origin reachability; 1033 points you at the cloudflared process and its outbound connection.

The origin server is up. Why do I still get 1033?

Because with a Tunnel, Cloudflare never talks to your origin directly — it talks to cloudflared, and cloudflared talks to the origin. Your web server can be perfectly healthy, but if the cloudflared process isn't running or isn't connected to Cloudflare's edge, the request has nowhere to land. The edge holds it, finds no connector, and returns 1033. Health of the origin is irrelevant until the connector is back up. This is why 1033 so often follows a reboot, a deploy, or a service that wasn't set to auto-start: the origin came back, the tunnel didn't.

Can a visitor fix Error 1033?

No. Nothing in the browser — reload, cache clear, different network, VPN off — changes the outcome, because the failure is entirely on the operator's side of the tunnel. If you're a visitor, the site owner has to restore the connector. If you're the owner, the fix is on the machine running cloudflared: confirm the service is running, that it has outbound internet, and that its credentials and route still point at the right tunnel. The Ray ID at the bottom of the error page is what Cloudflare support and your own logs use to trace it.

Views: 21

Cloudflare Error 1033: Argo Tunnel Error Fix

Cloudflare Error 1033: the hostname routes to a Tunnel with no live cloudflared connector. Check the tunnel, route, connector. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

A site behind Cloudflare returns Error 1033: Cloudflare Tunnel error (older setups say “Argo Tunnel error”). The edge served the page frame, so Cloudflare itself is reachable — but it couldn’t hand your request to the backend, because the backend is connected through a Cloudflare Tunnel and no healthy cloudflared connector is currently answering.

Symptoms

The Cloudflare error page shows Error 1033 with “Cloudflare Tunnel error” and a Ray ID.
It started right after a server reboot, a deploy, a container restart, or a credential change — the origin came back but the tunnel didn’t.
The origin web server is up and healthy when you check it locally, yet every request through the hostname returns 1033.
cloudflared tunnel list or the Zero Trust dashboard shows the tunnel as inactive, down, or with zero connections.

What This Error Actually Means

Most Cloudflare sites use a normal origin: the edge opens a network connection to your server’s IP on port 443 or 80. A Cloudflare Tunnel inverts that. Instead of Cloudflare dialing in, a lightweight daemon called cloudflared runs next to your origin and dials out to Cloudflare’s edge, holding open a persistent connection. The hostname’s DNS is a CNAME to a <UUID>.cfargotunnel.com target, and the edge routes requests down that outbound tunnel to the connector, which forwards them to your local service. No inbound ports, no exposed origin IP.

Error 1033 means the edge received a request for a hostname that’s wired to a tunnel, went looking for a healthy cloudflared connector to send it down, and found none. The tunnel exists in configuration but has no live connection right now. That’s a fundamentally different failure from 520–524, which all assume a direct origin that Cloudflare is trying and failing to reach. Here there’s no direct origin to reach — the whole point of the tunnel is that the connector reaches out, and the connector is gone.

The practical translation: your origin might be fine, but the thing that carries traffic to it — cloudflared — isn’t connected to Cloudflare right now.

Top 3 Causes

The cloudflared process isn’t running - It crashed, was stopped, or the machine rebooted and the service wasn’t set to start on boot. This is the single most common cause and the reason 1033 so reliably appears after maintenance: the origin comes back, the tunnel daemon doesn’t. A deploy that restarts the box without re-enabling the service produces exactly this.
The connector can’t reach Cloudflare’s edge - cloudflared dials outbound to Cloudflare (over QUIC/HTTP2 on port 7844). If a firewall, egress policy, or network change blocks that outbound connection, the daemon may be running but unable to register — so the edge still sees zero healthy connectors. The machine can browse the web and still fail to establish the tunnel if 7844 is filtered.
The route or credentials point at the wrong (or a deleted) tunnel - The DNS CNAME or the tunnel’s public-hostname ingress rule maps the hostname to a tunnel UUID that no longer has a running connector — often after recreating a tunnel, rotating the tunnel token, or migrating between named and legacy tunnels. The old route resolves, the new connector runs under a different ID, and the two don’t meet.

Diagnose with DechoNet

HTTP Check fetches the hostname from outside your network and shows the live edge response. It confirms whether the 1033 is still happening for everyone (a real down connector) versus something local, and tells you the moment the tunnel recovers.
DNS Check shows the hostname’s records. A tunnel hostname should resolve to a cfargotunnel.com CNAME target through Cloudflare — this confirms the request really is routed to a tunnel and not a stale direct A record.
SSL Check confirms the edge is terminating TLS normally, so you’re diagnosing the connector, not a certificate problem sitting in front of it.

Resolution Checklist

Confirm it’s a tunnel, not a direct origin: the hostname should be a Cloudflare-proxied CNAME to <UUID>.cfargotunnel.com. Run DNS Check to verify the routing before you go chasing the origin server.
On the connector machine, check the daemon is running — systemctl status cloudflared (or your service manager) — and restart it if it’s stopped. Set it to start on boot so the next reboot doesn’t reproduce this.
Verify the tunnel shows healthy connections: cloudflared tunnel info <name> or Zero Trust → Networking → Tunnels. Zero connections means the connector isn’t registered with the edge.
Confirm outbound connectivity from the connector to Cloudflare (port 7844). A running daemon that can’t dial out looks identical to a stopped one from the edge’s side.
If you recently recreated the tunnel or rotated its token, re-check that the DNS route and ingress rules point at the tunnel UUID the running connector actually uses. Re-authenticate the connector if the credentials changed.
Re-run HTTP Check to confirm the hostname now serves your app instead of 1033.

When to Escalate

If you’re a visitor, there’s nothing to escalate on your end — the site owner has to restore the connector. Reloading, clearing cache, or switching networks won’t help.
If the connector is running and can reach port 7844 but the tunnel still shows no connections, open a Cloudflare ticket with the Ray ID and tunnel ID — the edge-side registration may need their attention.
If 1033 flaps in and out under load or after every deploy, escalate it as a process-supervision problem, not a Cloudflare one: cloudflared needs a proper service definition, health checks, and auto-restart so it survives reboots and redeploys.