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

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?