Cloudflare error 520 occurs when your origin web server returns an empty, unknown, or unexpected response to Cloudflare’s proxy. This 2026 guide shows you how to diagnose server-side misconfigurations, firewall blocks, and resource exhaustion issues, then apply proven fixes to restore connectivity between Cloudflare and your origin server.
Error 520 is one of the most frustrating Cloudflare issues because it indicates a fundamental breakdown in communication between the CDN edge and your origin server. According to Cloudflare’s public incident reports, over 35% of enterprise support tickets related to 5xx errors stem from origin server misconfigurations rather than Cloudflare itself. When your site throws a 520, visitors see a generic error page, search engines may temporarily de-index pages, and e-commerce sites lose revenue during every minute of downtime.
Error 520 is a catch-all status code Cloudflare returns when your origin web server sends back a response that violates HTTP protocol expectations or simply fails to respond within the timeout window. Unlike more specific errors like 521 (server down) or 523 (unreachable), a 520 means Cloudflare successfully connected to your server but received something it couldn’t interpret or process.
Common underlying causes include:
Start by checking whether the issue is site-wide or affecting specific URLs. Visit your origin server directly using its IP address or a hosts file override to bypass Cloudflare entirely. If pages load normally when accessed directly, the problem lies in how your server handles Cloudflare’s proxy requests.
Next, examine your origin server logs during the exact timestamps when 520 errors occurred. Look for:
Cloudflare provides detailed diagnostic data in the Ray ID shown on the error page. Visit your Cloudflare dashboard, navigate to Analytics → Traffic, and filter by Ray ID to see exactly which request triggered the error, including headers, origin response time, and edge location.
The most common culprit is a firewall or security module that doesn’t recognize Cloudflare’s IP addresses as legitimate proxy traffic. When you enable Cloudflare, all visitor requests arrive from Cloudflare edge servers rather than end-user IPs. If your server firewall or intrusion detection system isn’t configured to whitelist Cloudflare’s published IP ranges, it will block or rate-limit those connections.
Apache and Nginx configurations can also trigger 520 errors when:
According to OWASP best practices, overly restrictive ModSecurity Core Rule Set configurations frequently false-positive on Cloudflare’s CF-Connecting-IP and CF-Ray headers, interpreting them as potential attack vectors.
Download the current Cloudflare IPv4 and IPv6 ranges from https://www.cloudflare.com/ips/ and configure your firewall to allow all traffic from these addresses. For iptables on Linux:
for ip in $(curl https://www.cloudflare.com/ips-v4); do
iptables -I INPUT -s $ip -j ACCEPT
done
for ip in $(curl https://www.cloudflare.com/ips-v6); do
ip6tables -I INPUT -s $ip -j ACCEPT
done
service iptables save
If you use CSF (ConfigServer Security & Firewall), add Cloudflare IPs to /etc/csf/csf.allow and restart CSF.
Install mod_remoteip (Apache) or ngx_http_realip_module (Nginx) to restore the actual visitor IP from Cloudflare’s CF-Connecting-IP header. Without this, your logs and security rules see only Cloudflare edge IPs.
For Apache, add to your VirtualHost or .htaccess:
RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 103.21.244.0/22
# Add all Cloudflare IPv4 ranges
For Nginx, add to your http or server block:
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
# Add all Cloudflare IPv4 ranges
real_ip_header CF-Connecting-IP;
If your origin server runs out of PHP workers, database connections, or memory, it may fail to respond properly to Cloudflare. Adjust PHP-FPM pool settings:
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500
request_terminate_timeout = 60s
Monitor server load with top, htop, or your hosting control panel to identify resource bottlenecks during traffic spikes.
Temporarily disable ModSecurity, Wordfence, Sucuri, or other security layers to test if they’re blocking Cloudflare. If the 520 errors stop, re-enable protections and whitelist Cloudflare IPs or specific User-Agent strings in your WAF rules.
In your Cloudflare dashboard under SSL/TLS → Origin Server, enable “Always Use HTTPS” and verify your SSL mode is set to “Full” or “Full (Strict)” rather than “Flexible.” Flexible mode can cause unexpected protocol mismatches that manifest as 520 errors.
Under Network settings, temporarily disable features like HTTP/2 to Origin, HTTP/3, or 0-RTT to isolate protocol-level incompatibilities.
If you’ve whitelisted Cloudflare IPs, restored real IPs, increased resource limits, and reviewed security rules but still see 520 errors, the issue likely stems from application-level crashes or database query timeouts. Enable verbose error logging in your application framework (WordPress debug mode, Laravel log level, Django DEBUG=True) and capture stack traces during the next error occurrence.
For WordPress specifically, add to wp-config.php:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
Then check wp-content/debug.log for PHP fatal errors or database connection failures coinciding with 520 timestamps in Cloudflare analytics.
Contact your hosting provider if server-level issues like kernel panics, out-of-memory killer events, or network routing problems are suspected. Managed hosting providers like Kinsta and WP Engine maintain pre-configured Cloudflare compatibility and can diagnose platform-specific conflicts.
Not necessarily. A 520 error means Cloudflare successfully connected to your origin server but received an unexpected or empty response. Your server may still be partially operational or serving direct IP requests, but something is causing it to fail when handling Cloudflare proxy traffic specifically.
Disabling Cloudflare will stop 520 errors because traffic will bypass the proxy entirely, but you’ll lose CDN caching, DDoS protection, and performance benefits. Instead, fix the underlying server misconfiguration causing the error so you can keep Cloudflare enabled.
Firewall rule changes on your origin server are immediate. However, Cloudflare edge caches may retain error responses for up to 5 minutes. Clear your Cloudflare cache manually under Caching → Configuration → Purge Everything to force fresh origin requests after applying fixes.
Temporary 520 errors lasting minutes are unlikely to harm rankings, but prolonged outages spanning hours or days will cause search engines to de-index affected pages. Google Search Console will flag server errors in the Coverage report, and Core Web Vitals scores will suffer from poor availability metrics.
Yes. If your origin server runs out of available worker processes, database connections, or memory during traffic spikes, it may stop responding to Cloudflare requests properly. Scale your server resources vertically or implement horizontal scaling with load balancers to handle traffic surges without errors.