Cloudflare Error 520: 7 Fixes That Actually Work

What Error 520 Actually Means

Cloudflare's edge server makes a TCP connection to your origin and waits for an HTTP response. Error 520 means the connection opened but the response was empty, malformed, or never arrived. This differs from 521 (server down) or 522 (connection timeout). Your server accepted the connection, then failed to deliver valid HTTP.

In support tickets I handled, the usual culprit was either the application timing out after 60 seconds while Cloudflare waited, or the web server closing the connection without sending headers. PHP-FPM crashing mid-request triggers it. So does a firewall rule that allows the initial SYN packet but drops subsequent data. Less common: an SSL mismatch between Cloudflare's origin requests and your server's expected protocol.

The error surfaces intermittently if your server is near resource limits. One request succeeds, the next triggers a crash. Check your error logs first. They'll show whether the web server process died, PHP hit max_execution_time, or the database connection pool ran dry.

Origin Server Health Check vs Cloudflare Settings

If you lack SSH or root access, you're limited to Cloudflare-side changes and application-level timeout adjustments through a control panel. That's fine for fast mitigation. Just understand you're treating symptoms. Someone with server access should review logs and resource usage before the next incident.

• Origin fix priority: crashes, resource exhaustion, application timeouts, firewall blocks against Cloudflare IPs. These solve the problem permanently.
• Cloudflare adjustment priority: Page Rules causing loops, Workers with infinite retries, SSL/TLS mode mismatches. These work around origin rigidity.
• Time investment: origin fixes take 15-30 minutes including log review and config changes. Cloudflare adjustments take 2-5 minutes but may mask deeper issues.

Comparing Timeout Adjustments Across the Stack

Test with a script that sleeps for 70 seconds then returns a response. If that triggers 520, you've confirmed a timeout mismatch. Extending the timeout to 120 seconds across all layers gives you margin. Going higher risks masking slow queries or infinite loops that should be optimized instead.

• PHP-FPM: set max_execution_time = 120 in php.ini or .user.ini; restart PHP-FPM after changes.
• Apache: add 'Timeout 120' in httpd.conf or VirtualHost block; reload Apache with 'systemctl reload httpd' or 'apachectl graceful'.
• Nginx: set 'proxy_read_timeout 120s;' and 'fastcgi_read_timeout 120s;' in the server block; reload with 'systemctl reload nginx'.
• Database query timeout: increase wait_timeout and interactive_timeout in MySQL if long queries contribute to the delay.

Firewall Whitelisting: Quick Win or False Security?

The trade-off: whitelisting means you trust Cloudflare's network to filter malicious traffic before it reaches you. If an attacker compromises a Cloudflare account or exploits a cache poisoning vector, your origin firewall won't stop them. That risk is theoretical for most sites and far outweighed by the operational simplicity of letting Cloudflare handle DDoS and bot filtering.

False security happens when you whitelist but never enable Cloudflare's firewall rules or rate limiting. You've opened the door without adding the lock. Use Cloudflare's WAF, configure rate limits for login endpoints, and enable Bot Fight Mode at minimum.

• CSF: add Cloudflare ranges to /etc/csf/csf.allow, then 'csf -r' to reload.
• iptables: insert rules with 'iptables -I INPUT -s <cloudflare-ip-range> -j ACCEPT' for each range; save with 'iptables-save'.
• Wordfence/Sucuri: add Cloudflare ranges to the allowlist in plugin settings; this prevents WAF blocks.
• Automatic updates: some server management tools (cPGuard, Imunify360) have built-in Cloudflare whitelist options that auto-update.

When to Disable Keep-Alive Connections

I've seen this resolve 520 errors on servers with unstable PHP-FPM worker pools or mismatched Apache MPM settings. The performance cost is real but small—typically under 50ms per request for nearby servers. If your origin is already slow, the keep-alive overhead won't be noticeable.

• Apache: add 'KeepAlive Off' in httpd.conf or VirtualHost block; reload Apache.
• Nginx: add 'keepalive_timeout 0;' in the http or server block; reload Nginx.
• Testing: use 'curl -I https://yoursite.com' multiple times in quick succession; with keep-alive off, each request opens a new connection.

Cloudflare SSL/TLS Mode Mismatches

If you recently enabled HTTPS on your origin and forgot to switch from Flexible to Full, you'll see 520 errors. Cloudflare tries to connect via HTTP, but your server redirects to HTTPS or rejects the request entirely. The fix is instant—change the SSL/TLS mode and clear Cloudflare's cache.

• HTTP-only origin: use 'Flexible' SSL mode; Cloudflare handles encryption to visitors.
• HTTPS origin with self-signed cert: use 'Full' mode; Cloudflare accepts the cert without validation.
• HTTPS origin with Let's Encrypt or commercial cert: use 'Full (strict)'; this is the most secure option.
• Testing: run 'curl -I https://your-origin-ip' to confirm your origin serves HTTPS and check the certificate.

Page Rules and Workers That Cause Loops

I've debugged 520 errors caused by a Page Rule that forwarded /admin to /admin/ (with a trailing slash), while the origin redirected /admin/ back to /admin. Each request bounced twice, then failed. The fix was deleting the redundant Page Rule and handling the trailing slash logic in the application.

• Page Rule audit: review rules in order; higher rules take precedence. Check for conflicting forwarding rules.
• Worker debugging: add console.log() statements (visible in 'wrangler tail' or the Cloudflare dashboard's real-time logs) to trace execution flow.
• Temporary disable: pause all Page Rules and Workers, test if 520 disappears, then re-enable one at a time.

Decision Framework: Which Fix to Try First

For hosting customers without SSH, the fastest path is: whitelist Cloudflare IPs via cPanel's firewall interface, increase PHP timeout via MultiPHP INI Editor, and verify SSL/TLS mode in Cloudflare dashboard. Each takes two minutes. If that doesn't fix it, escalate to a support engineer with log access.

• Consistent 520 on every request: origin server is down, firewall blocking Cloudflare, or SSL/TLS mode mismatch. Check server status and Cloudflare SSL settings.
• Intermittent 520 during traffic spikes: resource exhaustion (RAM, CPU, PHP-FPM workers) or timeout under load. Scale resources or optimize slow queries.
• 520 only on specific URLs: application bug, database deadlock on that endpoint, or a Page Rule/Worker targeting that path.
• 520 after recent changes: rollback the change (new plugin, server config, Cloudflare setting) and test.