Intermittent 52x errors behind Cloudflare that look like origin connection pool exhaustion

Question

An application behind Cloudflare's proxy shows intermittent failures that resemble connection pool exhaustion at the origin, but the origin's pool metrics do not clearly confirm saturation during the affected windows. The goal is to isolate one unresolved behavior: whether the intermittence is caused by Cloudflare's edge keep-alive reuse racing the origin's idle timeout, by Tunnel (cloudflared) reconnects, or by genuine origin pool saturation.

Relevant constraints: Cloudflare does not operate an origin-side pool, so diagnosis must target documented edge-to-origin connection reuse and timeout behavior. If the origin's keep-alive timeout is shorter than the edge's reuse window, the origin can close a connection the edge still considers reusable, producing intermittent 52x-style errors after idle periods. If cloudflared is in the path, its persistent connections and transport behavior (QUIC or HTTP/2) add another possible source of reconnects. If Workers is involved, the documented per-invocation connection cap is a fixed platform limit rather than a tunable pool.

Assume a proxied (orange-cloud) setup and current Cloudflare documentation as the reference, since exact timeout values and Tunnel defaults are release-sensitive.

Which timestamp-correlated signals (edge 52x codes, origin pool active/idle/waiter metrics, TCP resets, cloudflared reconnect logs) most reliably separate these three causes? Is there a documented recommended origin keep-alive timeout relative to the edge's reuse behavior? How should the isolation approach differ when Tunnel or Workers is in the request path?

Tasadduq Burney · Answer

To isolate whether 52x errors are caused by keep-alive races, Tunnel reconnects, or pool saturation, you must correlate transport-level TCP signals with origin-side state metrics.

1. The Likely Cause: Keep-Alive Timeout Race
The most common cause of intermittent 52x errors—where metrics appear healthy—is a mismatch between the origin's keep-alive timeout and the Cloudflare edge's reuse window. If the origin closes an idle connection exactly when Cloudflare edge attempts to reuse it for a new request, the edge receives a TCP Reset (RST), resulting in a 522 (Bad Gateway) or 504 (Gateway Timeout).

**Recommended Fix:** Set your origin-side keep-alive timeout to be higher than the Cloudflare edge timeout. While Cloudflare's default is typically 60 seconds, it is recommended to set the origin to **75 seconds or more** to ensure the edge initiates the closure first.

2. Isolation Signals by Cause
Use the following signals to differentiate between the three scenarios:

Cause
Primary Signal
Secondary Signal

Keep-Alive Race
TCP Resets (RST) on origin/firewall
522 errors occurring after periods of low traffic

Pool Saturation
High 'Waiter' count / Queue depth
504 errors with high origin CPU/RAM usage

Tunnel Reconnects
cloudflared 'reconnecting' logs
Intermittent QUIC/HTTP/2 transport errors

3. Path-Specific Logic (Tunnel vs. Workers)
The isolation approach shifts based on the architecture components:

Cloudflare Tunnel (cloudflared): Focus on the connection between the daemon and origin. If you see frequent connection establishment in the tunnel daemon logs, the issue is likely the tunnel-to-origin link or MTU issues, not the edge-to-tunnel link.
  Cloudflare Workers: These do not use a connection pool in the traditional sense. If errors occur here, you are likely hitting the platform-specific concurrency limits or memory caps, which manifest as hard failures rather than pool exhaustion.
  Standard Proxied Origin: Focus on the origin's TCP socket state. If the pool isn't saturated but errors persist, focus on the keep-alive timeout mismatch mentioned in section 1.

Diagnostic Question: Are you observing specific TCP Reset (RST) packets in your origin's packet capture at the exact timestamp of the 52x errors?

Intermittent 52x errors behind Cloudflare that look like origin connection pool exhaustion

1 answer

1. The Likely Cause: Keep-Alive Timeout Race

2. Isolation Signals by Cause

3. Path-Specific Logic (Tunnel vs. Workers)

Your perspective belongs here.

0 question comments

Cause	Primary Signal	Secondary Signal
Keep-Alive Race	TCP Resets (RST) on origin/firewall	522 errors occurring after periods of low traffic
Pool Saturation	High 'Waiter' count / Queue depth	504 errors with high origin CPU/RAM usage
Tunnel Reconnects	`cloudflared` 'reconnecting' logs	Intermittent QUIC/HTTP/2 transport errors