Cloudflare Error 530 (1033 Argo Tunnel Error)

What’s actually happening

You get a 530 in the status line wrapping a 1033 in the page body. This is specific to hosts fronted by a Cloudflare Tunnel (formerly Argo) — the DNS record is a CNAME to a UUID.cfargotunnel.com target rather than a normal IP. The edge can't find a live connector for that tunnel, so it can't forward anything. The tunnel showing 'INACTIVE' or 'DOWN' in Zero Trust → Networks → Tunnels is the tell.

Common causes

• The cloudflared daemon on the origin stopped, crashed, or was never restarted after a reboot
• The tunnel's outbound connection is blocked — egress firewall rules stop cloudflared reaching Cloudflare on 7844 (it needs outbound, not inbound)
• The tunnel credentials/token are stale or were rotated, so cloudflared authenticates but registers no routes
• Public hostname routing in the tunnel config points at a service that isn't running (e.g. http://localhost:8080 with nothing on 8080)
• DNS for the hostname CNAMEs to a tunnel UUID that no longer exists or was deleted and recreated with a new ID

How to fix it

1. Check cloudflared is running and connectedOn the origin: systemctl status cloudflared and journalctl -u cloudflared -n 50. A healthy daemon logs 'Registered tunnel connection' lines (usually four, to different Cloudflare colos). If it's dead, systemctl restart cloudflared. If it logs auth errors, the token is the problem — see below.
2. Confirm the tunnel shows healthy in Zero TrustIn the Cloudflare dashboard, Zero Trust → Networks → Tunnels. The tunnel should read ACTIVE with at least one connector. INACTIVE means no cloudflared has checked in. Cross-check that the tunnel ID here matches the UUID in your DNS CNAME — a mismatch (often after recreating a tunnel) produces 1033 even though everything looks 'up'.
3. Allow cloudflared's outbound connectioncloudflared dials out to Cloudflare on TCP/UDP 7844 — it does not accept inbound connections. If an egress firewall or locked-down security group blocks outbound, the tunnel never registers. Allow outbound to 7844 (QUIC) or force HTTP/2 mode with --protocol http2 if UDP is filtered on the network.
4. Verify the local service the tunnel points toOpen the tunnel's public hostname config (dashboard or config.yml). The service URL — say http://localhost:3000 — must point at something actually listening. curl that URL on the origin. cloudflared can be perfectly connected to Cloudflare and still fail because the app behind it is down; the request reaches the connector, then dies locally.
5. Re-issue the tunnel token if auth is staleIf logs show credential errors, regenerate: cloudflared tunnel token <TUNNEL_NAME> and update the service (systemd unit, Docker env, or credentials file). For token-run tunnels, paste the fresh token into the install command Cloudflare shows in the dashboard, then restart.