Cloudflare Errors 520-530: What Each Says About Your Origin

In short. Every Cloudflare 5xx in the 520-530 range is Cloudflare reporting that your origin server misbehaved, not that Cloudflare failed. The code tells you exactly which step broke: 521 means the origin refused the TCP connection, 522 means it never answered the handshake, 524 means it connected but answered too slowly, and 525/526 mean the TLS between Cloudflare and the origin failed.

Why these errors are not Cloudflare outages

The 520-530 family is generated by Cloudflare's edge after a request from a visitor has already reached it successfully. The edge then tries to fetch the page from your origin, and something in that second leg fails. The visitor sees a Cloudflare-branded error page, which is why these get misreported as "Cloudflare is down" — but the branding shows whose proxy printed the message, not whose infrastructure failed.

This distinction is the whole diagnostic shortcut. If you see a 520-530, you can stop investigating the public internet path and start investigating one specific link: edge to origin.

A Cloudflare error page always carries a Ray ID. If the failing response has no Ray ID and no cf-ray header, the error did not come from Cloudflare and this article is the wrong one — look at your own web server logs instead.

Confirm the error really came from the edge

Before reading any further, establish who answered. Two headers settle it:

curl -sI https://example.com | grep -iE '^(cf-ray|server|cf-cache-status):'
# cf-ray: 8f3a1c2d4e5f6789-FRA
# server: cloudflare

# Compare against the origin directly, bypassing the proxy entirely.
# Replace 203.0.113.10 with the real origin IP from your DNS panel.
curl -sv --resolve example.com:443:203.0.113.10 https://example.com/ -o /dev/null 2>&1 | tail -20

If the direct call to the origin succeeds and the proxied call fails, the problem sits between Cloudflare and your server — a firewall rule, a closed port, a TLS mismatch. If the direct call fails the same way, the origin is simply broken and the proxy is reporting it honestly.

Error 520: the origin answered, but not with HTTP

520 is the catch-all. Cloudflare completed a TCP connection and sent the request, then received something it could not parse as a valid HTTP response: an empty reply, a connection reset mid-response, headers exceeding the size limit, or a response with no status line.

The common real causes, in rough order of frequency:

• The origin process crashed or was OOM-killed while generating the response.
• Response headers are too large — usually a runaway Set-Cookie or a session cookie that grew unbounded.
• The origin sent a raw TCP reset because a security module (mod_security, a WAF, fail2ban) terminated the connection instead of returning a status code.
• An application returned an empty body with no headers on an unhandled exception.

Because 520 is generic, do not guess. Read the origin's error log for the exact second of the Ray ID:

# nginx: look for "upstream prematurely closed" or a worker crash
sudo tail -n 200 /var/log/nginx/error.log

# Apache
sudo tail -n 200 /var/log/apache2/error.log

# Was the process killed for memory?
sudo journalctl -k --since "10 minutes ago" | grep -i 'killed process'

Error 521: the origin actively refused the connection

521 means the TCP handshake got an explicit refusal — a RST packet. Something answered on that IP and said "nothing is listening here" or "you are not allowed". That is a very specific signal, and it has only two realistic causes: the web server is not running, or a firewall is rejecting Cloudflare's addresses.

Refusal is loud. That is what separates 521 from 522, where packets vanish silently.

# Does anything listen on 443 at the origin?
sudo ss -tlnp | grep -E ':(80|443)\s'

# From an outside host, is the port refused or dropped?
nc -vz -w 5 203.0.113.10 443
# "Connection refused"  -> 521 territory
# hangs then times out  -> 522 territory

If you allowlist Cloudflare at the firewall, the allowlist has to be refreshed. Cloudflare publishes its ranges at https://www.cloudflare.com/ips-v4 and ips-v6, and they change. A stale allowlist produces 521 for a fraction of visitors — the ones routed through a newly added edge — which is why intermittent 521 is so often blamed on the application.

Error 522: the handshake never completed

522 is the silent twin of 521. Cloudflare sent SYN and got nothing back within the timeout. No refusal, no reset — the packets were dropped. Typical causes: a firewall configured to DROP rather than REJECT, an origin so overloaded its accept queue is full, an incorrect IP in the DNS record, or asymmetric routing that breaks the return path.

Because 522 and 521 are so close in appearance but opposite in cause, always establish which one you have before touching configuration. We cover the deeper 522 path in the dedicated 522 guide.

Error 523: Cloudflare cannot route to the address at all

523 means the origin IP is unreachable at the network layer — not filtered, not refusing, simply not routable from the edge. In practice this almost always means the DNS record points somewhere wrong: a private address such as 10.0.0.5 or 192.168.1.10 left in an A record, a decommissioned server IP, or a record edited to a typo.

# What does the origin record actually hold?
dig +short example.com A
dig +short example.com AAAA

# Is that address routable from outside your network?
traceroute -n 203.0.113.10

Confirm the published address with an external lookup rather than your own resolver, which may still hold a cached older answer. Our DNS lookup queries from outside your network, and propagation check shows whether resolvers worldwide agree on the same value.

Error 524: connected, but the origin took too long

524 is the only code in this family where the network is fine. TCP connected, TLS succeeded, the request was delivered, and then the origin simply did not finish the response within Cloudflare's proxy timeout — 100 seconds by default on most plans.

This is an application problem wearing a network costume. The usual sources are an unindexed database query, an external API call with no timeout of its own, a report or export generated synchronously, or a lock contention stall.

# How long does the origin actually take, measured directly?
curl -o /dev/null -s -w 'connect:%{time_connect}s ttfb:%{time_starttransfer}s total:%{time_total}s\n' \
  --resolve example.com:443:203.0.113.10 https://example.com/slow-page

# MySQL / MariaDB: what is running right now and for how long?
sudo mysql -e "SELECT id, time, state, LEFT(info,120) FROM information_schema.processlist
               WHERE command <> 'Sleep' ORDER BY time DESC LIMIT 10;"

The durable fix is almost never raising a timeout. Move the long work to a background job and return immediately, or cache the expensive result. Raising the limit converts a 524 into a visitor who waits two minutes and then leaves.

Errors 525 and 526: the TLS between Cloudflare and your origin

These two only appear when your SSL/TLS mode is Full or Full (strict), which makes Cloudflare open its own HTTPS connection to your origin. Both describe a failure on that inner connection, and they fail for different reasons.

Code	What failed	Typical cause	First command
525	The TLS handshake itself	No shared protocol or cipher; port 443 closed at origin; origin does not honour SNI	openssl s_client -connect IP:443 -servername example.com
526	Certificate validation	Expired, self-signed, wrong hostname, or an incomplete chain, under Full (strict)	openssl s_client -connect IP:443 -servername example.com -verify_return_error

# Full inner-connection check against the origin, as Cloudflare would do it
openssl s_client -connect 203.0.113.10:443 -servername example.com \
  -verify_return_error < /dev/null 2>&1 | grep -E 'Verify return code|Protocol|Cipher|subject=|issuer='

An incomplete chain is the single most common 526. The certificate is valid, the browser accepts it because browsers fetch missing intermediates opportunistically, and Cloudflare's stricter validation does not. Our SSL checker reports the served chain explicitly, and the chain guide explains how to reassemble it. For handshake-level failures, the 525 walkthrough goes deeper.

Error 530: read the number underneath it

530 on its own means nothing. It is always displayed alongside a four-digit Cloudflare code, and that second number is the real error. By far the most frequent pairing is 1016, "Origin DNS error", which means a CNAME in your Cloudflare DNS points at a hostname that does not resolve.

Look at the error page body, find the Error 1xxx line, and diagnose that instead. Related access-layer codes such as 1020 come from Firewall Rules rather than the origin — that path is covered in the 1020 guide.

The whole family in one table

Code	Layer that broke	Meaning in one line	Where to look first
520	HTTP response	Origin replied with something unparseable	Origin error log at the Ray ID timestamp
521	TCP	Origin explicitly refused the connection	Is the service running; firewall allowlist
522	TCP	Handshake packets were dropped, not refused	DROP rules, accept queue, wrong IP
523	Routing	Origin address is not routable from the edge	A/AAAA record contents
524	Application	Connected, but the response never finished in time	Slow queries, synchronous external calls
525	TLS	Handshake with the origin failed	Protocol and cipher overlap, SNI, port 443
526	TLS	Origin certificate failed validation	Expiry, hostname, chain completeness
527	Legacy	Railgun error; the product has been retired	Treat as historical, not current
530	Varies	Placeholder — the paired 1xxx code is the error	The 1xxx number on the error page

A three-minute triage order that works for all of them

The codes differ, but the isolation sequence does not. Work outward from the smallest assumption:

1. Confirm the source. Is there a cf-ray header? If not, this is not a Cloudflare error.
2. Get the origin IP from your Cloudflare DNS panel — not from a public lookup, which returns the proxy address.
3. Test TCP directly: nc -vz origin_ip 443. Refused, dropped or open tells you 521 versus 522 versus "go further".
4. Test TLS directly with openssl s_client and the correct -servername. This separates 525 from 526.
5. Test HTTP directly with curl --resolve and read the timing breakdown. A slow time_starttransfer is your 524.

Each step either fails — and names your code — or passes and eliminates a layer. Five commands cover the whole family.

How to check your site right now

You can run most of this triage without a terminal. Use the HTTP header checker to see whether a cf-ray header is present and which server answered, the SSL checker to inspect the certificate and chain your origin actually serves, the port checker to see whether 80 and 443 are open, refused or filtered from outside your network, and traceroute to confirm the origin address is routable.

Because 520-530 errors are frequently intermittent — a stale firewall allowlist or a periodic memory spike produces them for minutes at a time — a single manual check can easily land in a healthy window. Uptime monitoring records the status code and response time of every check, which turns "it happens sometimes" into a timestamped pattern you can correlate with deploys, cron jobs and traffic peaks.

Frequently asked questions

Does a 520-530 error mean Cloudflare is down?

No. These codes are generated by Cloudflare's edge after it has already accepted the visitor's request. They describe a failure between the edge and your origin server. A genuine Cloudflare outage looks different: the edge itself becomes unreachable, and you get no Cloudflare error page at all.

Why do I see the error but my hosting says the server is fine?

Because both statements can be true. Your server can be healthy for direct visitors and still refuse or drop Cloudflare's specific source addresses because of a firewall allowlist that has not been refreshed. Test from outside using the origin IP, not from the server itself, where the firewall rule does not apply.

Will pausing Cloudflare fix it?

Pausing removes the proxy, so the error disappears and visitors reach the origin directly. That is a diagnostic, not a fix: it confirms the failure is on the edge-to-origin leg, and it also removes whatever protection you were relying on. Use it to isolate, then restore the proxy and repair the underlying cause.

Should I just raise the 524 timeout?

Only as a temporary measure, and only if you have confirmed the slow operation is legitimately long-running. Raising it changes what the visitor experiences from an error page to a very long wait. The durable answer is to make the request return quickly and do the heavy work asynchronously.

Is 526 a problem with my certificate if browsers show no warning?

Very often, yes. Browsers tolerate an incomplete chain by fetching missing intermediate certificates on their own; strict server-side validation does not. A certificate that looks perfect in a browser can still fail validation from Cloudflare, and the fix is to serve the full chain from your web server.

Why is the error intermittent?

Intermittent 521 and 522 usually mean a partial condition: only some edge addresses are blocked, or the origin only exhausts its connection queue under load. Intermittent 524 usually tracks a specific slow endpoint or a scheduled job. In both cases, correlate the failures against time rather than retrying manually.

Checklist

• Confirm a cf-ray header is present before treating it as a Cloudflare error.
• Take the origin IP from the Cloudflare DNS panel, never from a public lookup.
• Distinguish refused from dropped with nc -vz — that alone separates 521 from 522.
• Check A and AAAA records for private or stale addresses when you see 523.
• Measure time_starttransfer directly against the origin before blaming the network for a 524.
• Validate the origin chain with -verify_return_error, not by trusting a green browser padlock.
• Refresh firewall allowlists of Cloudflare ranges on a schedule, not once at setup.
• Read the four-digit code underneath any 530 — that number is the actual error.
• Record status codes over time so intermittent failures become a pattern instead of a rumour.