Cloudflare Tunnel: When the Daemon Dies, How to Recover (cfOrigin;dur=122)

A Cloudflare Tunnel that worked yesterday and refuses to serve today usually has one of three failures: the cloudflared daemon died, the local origin died, or the local origin is alive but slow enough that Cloudflare’s edge gives up and serves a 502. They look identical from the browser. The fix for each is different, and most recovery guides skip the slow-origin case. This playbook is the recovery flow we use on the Agentic Bot Sitter VPS — verified against cloudflared 2026.5.2 after a real cfOrigin;dur=122 incident on the night of 2026-07-13.

Scope: CLI-managed named tunnels where cloudflared runs as a systemd service on the VPS. Quick Tunnels and Docker-managed connectors need slightly different steps but the diagnostic order is the same.

The first 60 seconds

Five checks, in order. They go from cheapest to most-disruptive:

1. systemctl status cloudflared — is the daemon alive?
2. cloudflared tunnel info <tunnel> — is the connector registered?
3. tail -n 200 /var/log/cloudflared.log — last 200 lines, look for connection closed or tunnel down
4. curl -sS -I https://agenticbotsitter.com/healthz | head -1 — confirm the origin is healthy behind the tunnel
5. systemctl restart cloudflared — only after 1–4 are green elsewhere

Step 5 is the only disrupting action. Doing it first costs you the recovered state to compare against.

If step 1 shows active (running) and step 2 shows at least one active connector, the daemon is fine. The problem is downstream. Skip to step 4 and beyond.

The cfOrigin;dur=122 trap

A bad cfOrigin duration — anything above ~80ms — is a tell that the local origin daemon (the backend at :8793, the static nginx at :80, etc.) is doing something slow on every connection. The most common cause: a backend that accepts the connection but doesn’t respond for 5–30 seconds. Network latency, DNS, or a long-running startup cost all show up here. Check /opt/data/abs/backend/ or whatever your origin is.

On the night of 2026-07-13, response headers on https://agenticbotsitter.com/ started showing cfOrigin;dur=122 after a backend deploy. 122ms is not catastrophic in isolation — the threshold is roughly 30s — but the real signal was the trend: dur climbed from ~12ms to 122ms to 900ms over twenty minutes. By the time it crossed 5s, the edge was returning 502s and the daemon looked healthy the entire time.

The trap is that cfOrigin;dur=122 is a Cloudflare response header you only see with curl -sS -I (or DevTools → Response Headers). The browser page just shows a 502. If you don’t probe the headers, you can’t see the climb, and you’ll restart a healthy cloudflared instead of the actual origin.

If dur is climbing across several requests, the tunnel is not the problem. Restart the origin, not the connector. A cloudflared restart in this state does nothing useful and resets your evidence.

When the origin is the issue, not the tunnel

Open a second shell:

curl -sS -I http://127.0.0.1:8793/healthz
curl -sS -I http://127.0.0.1:80/

If those fail with connection-refused or hang, the tunnel is fine — the origin died. Restart the origin first, then re-test through the tunnel.

Two signs you’ve landed in this branch:

• The public probe (step 4 above) fails with 502, 503, or a hang past 5s.
• The local probe (this section) fails with Connection refused, Connection timed out, or takes >5s to respond.

Restart the origin process — for the ABS stack this is systemctl restart abs-backend plus, if you serve static assets separately, systemctl restart nginx. Re-probe the local origin. Only when the local probe is fast (under ~200ms) should you re-probe through the tunnel.

When the tunnel is the issue, not the origin

systemctl restart cloudflared
cloudflared tunnel info <tunnel> | grep -E 'Connectors|Healthy'

Watch the log: tail -f /var/log/cloudflared.log. You should see Registered tunnel connection lines within 5 seconds. If they don’t appear, the credentials in /etc/cloudflared/<UUID>.json may have been rotated — re-import from the Cloudflare dashboard.

Three signs you’ve landed in this branch:

• systemctl status cloudflared shows inactive (dead) or failed.
• cloudflared tunnel info <tunnel> shows the tunnel exists but lists zero connectors.
• The log file ends with connection closed or tunnel down instead of Registered tunnel connection.

After restart, confirm the Registered tunnel connection line appears. If it does not, the issue is credentials, not the daemon. Don’t loop restarts — re-import the JSON.

What not to do

• Don’t restart cloudflared before checking the origin. A restart of a healthy daemon hides the symptom for ~30s and then the 502 returns; meanwhile you’ve lost your evidence.
• Don’t delete the tunnel and re-create from scratch — that takes the downtime from minutes to hours. Most “broken” tunnels are recoverable in place.
• Don’t trust https://<host> returning 200 in isolation — always probe the origin too. A cached 200 on the edge hides an origin that’s already down.
• Don’t edit /etc/cloudflared/config.yml while the daemon is in a bad state — commit what you have, then change. An invalid config plus a restart leaves you with neither the old nor the new config running.

Verification checklist

#	Command	What it proves
1	systemctl status cloudflared	Daemon alive
2	cloudflared tunnel info	Connector registered
3	tail -f /var/log/cloudflared.log	Last 200 lines visible
4	`curl -sS -I https:///	head -1`
5	cfOrigin;dur<60ms in response headers	Origin latency acceptable

Run these in order. The first four should all be green within 30 seconds of the restart. Step 5 is the long-term signal — if dur is climbing again hours later, you have a slow-origin problem and should read the “When the origin is the issue” section above, not this recovery flow.

Sources

• Cloudflare Tunnel troubleshooting
• ABS companion: Cloudflare Tunnel Setup for a Static Site
• ABS companion: Cloudflare Tunnel Multi-Hostname

Last verified: 2026-07-14 against the live cfOrigin;dur=122 incident on agenticbotsitter.com, with cloudflared 2026.5.2 running as a systemd service on the VPS.