Cloudflare Error 520 Not Working: 7 Fixes (2026)

What Error 520 Actually Means

Cloudflare's edge server connects to your origin successfully—TCP handshake completes, nothing blocked at the network layer. But then the origin sends back something Cloudflare can't parse as valid HTTP, or it sends nothing at all before the connection times out.

Error 520 is a catch-all for 'unexpected response from origin.' That includes empty responses, malformed headers, SSL handshake failures after the TCP connection opens, and application errors that crash the web server mid-response. It does not mean your server is down. The connection reached your server; what happened next is the problem.

Check your origin's error logs first. Apache's error.log, Nginx's error.log, application logs—whatever your stack writes to. The timestamp of the 520 error in Cloudflare's dashboard should match an entry in your origin logs that explains what broke.

Fix 1: Increase Origin Timeout Settings

Cloudflare waits up to 100 seconds for your origin to send a complete HTTP response. If your origin web server or application has a lower timeout, it closes the connection before Cloudflare receives the full response. Result: Error 520.

For Apache, check the Timeout directive in httpd.conf or your virtualhost config. Default is often 60 seconds. Set it to 100 or higher:

For Nginx, adjust proxy_read_timeout, proxy_connect_timeout, and proxy_send_timeout in your server block. Default proxy_read_timeout is 60 seconds:

Application-level timeouts matter too. PHP's max_execution_time, Node.js server timeouts, Python WSGI timeouts—all of these can cut off a response before Cloudflare finishes reading it. If your application runs long queries or generates large responses, bump those limits.

Test by making a direct request to your origin IP (bypassing Cloudflare) that takes longer than your current timeout. If it fails, you've confirmed the timeout is too low.

• Apache: add 'Timeout 120' to httpd.conf and reload
• Nginx: set 'proxy_read_timeout 120s;' in the server block
• PHP: increase 'max_execution_time' in php.ini or .htaccess
• Node.js: set server.timeout = 120000 in your app code

Fix 2: Whitelist Cloudflare IP Ranges in Your Firewall

Your firewall might allow the initial connection from Cloudflare but then rate-limit or block subsequent requests from the same IP. This is common with fail2ban, CSF (ConfigServer Security & Firewall), and some managed firewall services that treat Cloudflare's automated health checks as suspicious traffic.

Cloudflare publishes its IP ranges at https://www.cloudflare.com/ips/. You need to whitelist all of them—both IPv4 and IPv6—at the firewall level, not just in your web server config. Many admins whitelist in Apache or Nginx but forget the OS-level firewall, which still drops packets.

For iptables, add rules that accept traffic from Cloudflare ranges before your rate-limiting or blocking rules. For CSF, add the ranges to csf.allow. For UFW, use 'ufw allow from <cloudflare_ip_range>'. Order matters—whitelist rules must come first.

After whitelisting, test by checking your origin's access logs. You should see requests coming from Cloudflare IPs without corresponding firewall drops in your system logs. If you still see blocks, your firewall might be inspecting application-layer traffic (like mod_security rules) rather than just network-layer packets.

Fix 3: Match SSL/TLS Mode to Your Origin Certificate

Cloudflare offers four SSL/TLS modes: Off, Flexible, Full, and Full (strict). If the mode doesn't match your origin's certificate setup, the SSL handshake fails and you get Error 520.

Flexible mode means Cloudflare uses HTTPS between the visitor and Cloudflare, but HTTP between Cloudflare and your origin. If your origin only accepts HTTPS (because you force SSL redirects or bind only to port 443), Cloudflare's HTTP connection fails.

Full mode requires your origin to have an SSL certificate, but Cloudflare doesn't validate it. Self-signed certificates work. Full (strict) validates the certificate—it must be issued by a trusted CA, match your domain, and not be expired. If your origin uses a self-signed cert and you choose Full (strict), the handshake fails.

In support tickets, the typical mistake is enabling Full (strict) with a self-signed certificate or an expired Let's Encrypt cert. Cloudflare connects, starts the SSL handshake, rejects the certificate, and returns 520. Check your origin certificate expiration date first. Run 'openssl s_client -connect your_origin_ip:443' to see what certificate your origin presents.

• Flexible: Use only if your origin accepts HTTP and you have no SSL certificate
• Full: Use with self-signed or internal certificates that your origin trusts
• Full (strict): Use only if your origin has a valid certificate from a public CA
• Off: Almost never appropriate; disables encryption between Cloudflare and visitors

Fix 4: Check for Application-Level Errors and Crashes

Your web server might accept the connection and start processing the request, then crash before sending a response. PHP fatal errors, uncaught exceptions in Node.js, segfaults in compiled applications—all of these terminate the connection abruptly, which Cloudflare sees as an invalid response.

Check your application error logs around the timestamp of the 520 error. Look for stack traces, out-of-memory errors, or messages about closed connections. If you're running PHP-FPM, check both the PHP error log and the FPM error log (often /var/log/php-fpm/error.log).

Common causes: database connection pool exhaustion, unhandled exceptions in middleware, memory_limit too low in PHP, or max open files limit hit at the OS level. Test by reproducing the request locally. If it crashes your local server too, the application code is the problem.

For Laravel users seeing '419 page expired error' or '419 error code laravel' in combination with 520 errors, check session storage. If session writes fail (because the session directory isn't writable or Redis is down), Laravel throws a 419, which can cascade into a 520 if the exception handler also fails.

Fix 5: Rule Out Resource Exhaustion on the Origin

Even if your web server process is running, it can fail to respond if the server is out of CPU, memory, or disk I/O. The process hangs, times out, or returns an incomplete response. Cloudflare sees this as 520.

Check server load with 'top' or 'htop' during the time the error occurs. If load average is above the number of CPU cores, the server is struggling. Check memory usage with 'free -h'—if swap is being used heavily, you're out of RAM. Check disk I/O with 'iostat' (part of the sysstat package)—if await times are above 50ms, disk is the bottleneck.

Another common cause: hitting the max connections limit for your web server or database. Apache's MaxRequestWorkers, Nginx worker_connections, MySQL max_connections—if you hit any of these limits, new requests queue or fail. Check your web server status page (mod_status for Apache, stub_status for Nginx) to see active connections.

If resource exhaustion is the cause, you'll see the problem come and go with traffic spikes. The fix is either vertical scaling (more RAM, more CPU), horizontal scaling (more origin servers), or optimizing your application to use fewer resources per request.

Fix 6: Temporarily Disable Origin Firewall to Isolate the Problem

If you've checked timeouts, SSL, and application logs and still see 520 errors, disable your origin firewall completely for five minutes and test again. This tells you whether a firewall rule is the root cause.

Run 'systemctl stop firewalld' (RHEL/CentOS), 'ufw disable' (Ubuntu), or 'csf -x' (CSF) to stop the firewall. Test your site through Cloudflare. If the 520 errors stop, the firewall is blocking or rate-limiting Cloudflare's traffic. Re-enable the firewall and go back to Fix 2—you need to whitelist Cloudflare IPs correctly.

Make sure you re-enable the firewall immediately after testing. Leaving a production server firewallless is asking for trouble. If you're uncomfortable disabling the firewall on a live server, clone the server to a staging environment and test there first.

Fix 7: Compare Direct Origin Response to Cloudflare Response

Bypass Cloudflare and hit your origin directly using its IP address. If the site loads fine via IP but fails through Cloudflare, the problem is in how Cloudflare and your origin are communicating, not in the origin itself.

In your browser, visit 'http://your_origin_ip' or add an entry to your hosts file mapping your domain to the origin IP. Or use curl from the command line: 'curl -I http://your_origin_ip'. Compare the response headers and timing to a request through Cloudflare.

If direct requests work but Cloudflare requests fail, focus on the settings that only affect Cloudflare traffic: SSL/TLS mode, firewall whitelist, and any origin rules that treat Cloudflare's IPs differently. If direct requests also fail or time out, the problem is on the origin and Cloudflare is just surfacing it.

Which Fix Should You Try First?

Start with the easiest diagnostic: check your origin error logs. If you see crashes, SSL errors, or timeouts there, you've found the cause without changing any config.

If logs are clean, check firewall rules next. In my experience, firewall blocks account for more than half of persistent 520 errors. Whitelist Cloudflare IPs at the OS level, test, and if that fixes it, you're done.

If the firewall isn't the issue, compare your Cloudflare SSL/TLS mode to your origin's certificate setup. Mismatch here is the second most common cause. Fix that before touching timeout settings.

Only if none of the above work, increase timeout settings and check for resource exhaustion. Those fixes require you to understand your application's behavior under load, so they take more time.

• Check origin error logs for crashes or timeouts (1 minute)
• Whitelist Cloudflare IP ranges in firewall (5 minutes)
• Match SSL/TLS mode to origin certificate type (2 minutes)
• Increase origin timeout settings to 100+ seconds (5 minutes)
• Test direct origin response and compare to Cloudflare (2 minutes)
• Check server load, memory, and disk I/O during errors (ongoing)
• Temporarily disable origin firewall to isolate network-level blocks (5 minutes, restore immediately)