How do you fix Cloudflare 522 timeout?

Confirm whether the TCP connection from Cloudflare to the origin is timing out, compare direct-origin latency with proxied latency, check firewall allow rules for Cloudflare IP ranges, and inspect origin CPU, worker, database, and upstream network pressure.

Is Cloudflare 522 a DNS problem?

Usually no. A 522 means Cloudflare has an origin address but cannot complete the connection or response in time. DNS mistakes can lead to the wrong origin, but the first useful split is timeout versus refused or unreachable behavior.

Question

How to fix Cloudflare 522 connection timed out

Updated June 7, 2026

522 means Cloudflare has a route toward your origin, but the connection or response does not complete fast enough. In practice it is usually one of four things: a dropped TCP handshake, an overloaded origin, a firewall rule that silently drops Cloudflare traffic, or an upstream network path that is unhealthy from the Cloudflare edge.

The fastest way to avoid guessing is to compare three views of the same URL: public Cloudflare URL, direct origin IP, and hostname forced to the origin IP with SNI. Those three checks separate "my app is slow" from "Cloudflare cannot reach the origin cleanly".

Checks in order

Measure public URL latency and status through Cloudflare.
Measure direct origin latency from a network outside your server provider.
Use --resolve to test the same hostname and TLS/SNI against the origin IP.
Check CPU, memory, IO wait, web worker saturation, and database pool exhaustion.
Review firewall, WAF, fail2ban, load balancer, and upstream rate-limit rules.

If you are unsure whether this is timeout or malformed response behavior, start with Cloudflare 520 vs 524 quick split.

What makes 522 different

Do not treat every Cloudflare 5xx as the same incident. A 521 is usually refused connection or a down web server. A 523 points more toward an unreachable origin IP or route. A 524 means the connection was established but the origin took too long to finish the response. A 522 sits earlier in the chain: Cloudflare is timing out while trying to connect to, or wait on, the origin path.

Cloudflare's own 522 documentation describes it as a timeout while contacting the origin web server. That small distinction matters because adding application cache may help an overloaded origin, but it will not fix a network ACL silently dropping Cloudflare IP ranges.

Command block for first response

# Public endpoint latency check
time curl -s -o /dev/null -w '%{http_code}\n' https://yourdomain.com/

# Direct origin checks
time curl -s -o /dev/null -w '%{http_code}\n' http://ORIGIN_IP/
time curl -s -o /dev/null -w '%{http_code}\n' --resolve yourdomain.com:443:ORIGIN_IP https://yourdomain.com/

# Runtime pressure
top -bn1 | head -n 20
vmstat 1 5
iostat -xz 1 3

# Service logs
sudo journalctl -u caddy --since '30 minutes ago' --no-pager | tail -n 120
sudo journalctl -u nginx --since '30 minutes ago' --no-pager | tail -n 120

Evidence to collect before changing settings

Ray ID and data center: save the Cloudflare Ray ID from the error page. If only one colo appears, routing may be involved.
Origin access logs: check whether the 522 request ever arrived. No log entry points to network/firewall/drop before the app.
Kernel and firewall logs: look for dropped SYN packets, conntrack pressure, or fail2ban rules matching Cloudflare ranges.
Load graphs: compare the first 522 timestamp with CPU steal, IO wait, worker count, database wait, and queue backlog.

Typical 522 patterns

Only dynamic pages timeout: application layer bottleneck.
Everything slow at the same time: host pressure or upstream network saturation.
Direct origin fast, proxied path slow: edge-to-origin path, firewall, or routing issue.
First request fails, refresh works: cold workers, idle upstream connections, or slow TLS/origin wake-up behavior.
Only crawlers fail: bot firewall, rate-limit rules, or reverse proxy timeouts triggered by crawler bursts.

Fix order that reduces blast radius

Stabilize origin health first (CPU/memory/worker pool).
Confirm Cloudflare IP ranges are allowed at the host firewall, provider firewall, and any load balancer.
Move heavy sync tasks to async jobs or queues, especially report generation and remote API calls.
Add caching for high-repeat read endpoints, but only after confirming the origin is reachable.
Increase reverse proxy and upstream worker capacity only when logs show queueing rather than dropped network paths.
Re-test through Cloudflare and compare status/latency over 30-60 minutes.

Small production example

A static marketing page and /robots.txt return 200, but a pricing page returns 522 during crawler bursts. Direct origin curl is fast for /robots.txt and slow for /pricing/. That points away from DNS and toward application work on the pricing route. In that case, fix the route's database/API dependency and add cache. If none of the failing requests appears in origin logs, the better path is firewall and provider network investigation, not app tuning.

After-fix validation

For successful recovery, public pages should return mostly 200/301/304 and no repeated 522 on homepage, sitemap, and high-traffic question pages.

Useful references: Cloudflare 522 support docs and the LLMs File 52x checklist generator.

If requests are refused instead of timing out, continue with Cloudflare 521 web server down.

Generate full 522 checklist