What is the difference between Cloudflare 520 to 526 errors?

520 is unexpected origin response behavior, 521/522/523/524 are origin connectivity or timeout problems, and 525/526 are origin TLS issues.

Which Cloudflare 52x errors are TLS problems?

525 and 526 are TLS/certificate problems between Cloudflare and the origin. Check SNI, certificate chain, hostname coverage, and strict SSL validation before changing application code.

Which Cloudflare 52x errors should be checked in server logs first?

For 520, 524, and intermittent 522, compare the Cloudflare Ray ID time with origin access and error logs. For 521 and 523, first confirm listener, firewall, DNS target, and route reachability.

Question

Cloudflare 52x error differences

Updated July 8, 2026

When teams mix up 52x codes, they spend hours checking the wrong layer. Use this quick map before changing settings.

Fast map

520: Origin returned an unexpected or malformed response.
521: Origin refused connection.
522: Cloudflare timed out reaching origin.
523: Origin IP unreachable / routing problem.
524: Origin connected but too slow to respond in time.
525: TLS handshake failed between Cloudflare and origin.
526: Origin certificate invalid for strict validation.

Practical rule

For 520-524, check origin availability, response integrity, routing, and latency first. For 525-526, check certificate, SNI, chain, and strict TLS compatibility.

Which layer to check first

Error	First layer	Fast evidence	Common wrong fix
520	Origin response	Origin returns malformed headers, reset, empty reply, or an unexpected HTTP response.	Changing DNS before checking app/proxy logs.
521	Listener/firewall	Port 80/443 refuses the connection or the service is not bound.	Changing SSL mode for a refused TCP connection.
522	Reachability timeout	Cloudflare cannot complete the connection to origin in time.	Debugging app latency before checking firewall, route, or SYN drops.
523	Routing/DNS target	Origin IP is unreachable from Cloudflare edge networks.	Restarting the web server when DNS or route is wrong.
524	Application latency	TCP/TLS succeeds, but the origin takes too long to send a response.	Replacing certificates for a slow endpoint.
525	TLS handshake	Handshake fails before HTTP starts; SNI or TLS config is suspect.	Switching to Flexible SSL instead of fixing origin TLS.
526	Certificate validation	Handshake completes, but strict validation rejects hostname, expiry, or chain.	Treating it as an Nginx upstream error.

One command set to separate network, TLS, and app issues

Run these from a machine outside the origin network, then compare the timestamp with the Cloudflare Ray ID shown on the error page.

# Replace example.com and ORIGIN_IP.
curl -Iv --connect-timeout 8 https://example.com/
curl -Iv --connect-timeout 8 --resolve example.com:443:ORIGIN_IP https://example.com/
openssl s_client -connect ORIGIN_IP:443 -servername example.com -showcerts </dev/null | head -n 80

# On the origin:
sudo ss -lntp | grep -E ':80|:443'
sudo tail -n 100 /var/log/nginx/error.log
sudo journalctl -u caddy --since '30 minutes ago' --no-pager | tail -n 100

If the forced-origin curl --resolve fails the same way as the public URL, the problem is on the origin side. If it succeeds while the public URL fails, check Cloudflare DNS, SSL mode, edge firewall rules, and whether the proxied record points to the same origin IP you tested.

If you are choosing between 520 and 524 under pressure, use this quick 520 vs 524 split.

If the error happens only for AI crawler or preview traffic, compare user agent, method, and path before assuming a site-wide outage. Bot-specific WAF rules can create a crawler-only failure while normal browser checks keep returning 200.

For a full topic map, open the Cloudflare AI crawler troubleshooting hub.

Generate the checklist for your code