Cloudflare Error 520: Step-by-Step Fix, Comparison and Best Practices

What Cloudflare Error 520 Means and Why It Occurs

Error 520 is Cloudflare's generic response when the origin server returns something unexpected. The HTTP status code means 'Web Server Returned an Unknown Error,' which happens when Cloudflare receives a response that does not conform to HTTP protocol standards or receives no response headers at all after the TCP connection succeeds.

Common root causes include: web server crashes or restarts during request processing, application timeouts where the backend takes too long to generate a response, incorrect or missing HTTP headers sent by the origin, firewall or security software blocking or modifying responses, server resource exhaustion (CPU, memory, or connection limits), and misconfigurations in reverse proxy setups or load balancers sitting between Cloudflare and your application server.

Understanding the difference between error 520 and similar errors helps narrow the diagnostic path. Error 521 means the origin server refused the connection entirely. Error 522 means Cloudflare could not establish a TCP connection within the timeout window. Error 524 means a connection was established but the origin did not send a complete response within 100 seconds. Error 520 is distinct because the connection succeeds and the server responds, but the response itself is malformed or incomplete.

Diagnostic Approach Comparison: Logs vs. Direct Testing vs. Firewall Review

**Recommendation by use case**: Start with server logs if you have access—this identifies application and server-level failures in under two minutes. Use direct IP testing next to confirm whether the origin responds correctly outside of Cloudflare. Review firewall rules last, focusing on recent configuration changes or known restrictive policies. For shared hosting without log access, contact your provider first and use direct IP testing to provide them diagnostic context.

• **Origin server logs (fastest, most direct)**: Check your web server error logs (Apache error_log, Nginx error.log, or application logs) for entries correlating with the timestamp of the 520 error. This method immediately reveals server crashes, application exceptions, or timeout events. Trade-off: Requires server access and familiarity with log locations. Best for: VPS, dedicated servers, or shared hosting with log access via control panel.
• **Direct IP testing (definitive isolation test)**: Access your origin server directly using its IP address (http://your-server-ip or https://your-server-ip if SSL is configured on the origin) to bypass Cloudflare entirely. If the site loads correctly via direct IP but fails through Cloudflare, the issue involves Cloudflare's communication with your origin (firewall rules, rate limiting, or IP restrictions). If it also fails via direct IP, the problem exists on the origin server itself. Trade-off: Exposes your origin IP during testing and may trigger security warnings if testing HTTPS without matching certificate. Best for: Isolating whether the issue is Cloudflare-specific or origin-specific.
• **Firewall and security rule review (necessary when logs and direct testing are inconclusive)**: Verify that your server firewall, security plugins, or web application firewall (WAF) allow traffic from Cloudflare IP ranges. Check for rate limiting rules that might block Cloudflare's requests, mod_security rules flagging legitimate traffic, or IP whitelisting that excludes Cloudflare. Trade-off: Time-consuming if you have multiple security layers (server firewall, application firewall, WordPress security plugins). Best for: Environments with strict security policies or after recent security configuration changes.

Step-by-Step Fix for Shared Hosting Environments

If direct IP access works but Cloudflare access fails, the issue involves your hosting provider's firewall or Cloudflare IP allowlisting. Request they whitelist Cloudflare's published IP ranges in their firewall configuration. If direct IP access also fails, the problem is application-level or resource-related; focus on optimizing site performance or upgrading your hosting plan.

• **Step 1**: Log into your hosting control panel and navigate to error logs or access logs if available. Look for HTTP 5xx errors, timeout messages, or resource limit warnings around the time error 520 occurred.
• **Step 2**: Test your site by accessing it via your server's direct IP address or temporary domain provided by your host. If your hosting provider uses a shared IP, use the temporary subdomain (often something like username.hostingprovider.com) to bypass Cloudflare.
• **Step 3**: Check your hosting resource usage dashboard for CPU, memory, or entry process limit violations. Shared hosting accounts have enforced limits; exceeding them causes the server to drop connections or return incomplete responses.
• **Step 4**: Review recent plugin or theme updates if you are running WordPress, Joomla, or similar CMS platforms. A poorly coded update may trigger fatal errors or infinite loops that prevent proper HTTP responses.
• **Step 5**: Temporarily disable any security plugins or WAF features within your CMS. Some security plugins block or modify responses to requests they perceive as suspicious, which can interfere with Cloudflare's proxying.
• **Step 6**: Contact your hosting provider with specific details: the exact time error 520 occurred, the URL that triggered it, and whether direct IP access works. Request they check server-level logs and verify no rate limiting or ModSecurity rules are blocking Cloudflare IPs.

Step-by-Step Fix for VPS and Dedicated Server Environments

After applying a fix, restart your web server or application service. For Apache: `sudo systemctl restart apache2`. For Nginx: `sudo systemctl restart nginx`. For PHP-FPM: `sudo systemctl restart php-fpm` or the version-specific service name. Monitor logs in real-time as you test: `sudo tail -f /var/log/nginx/error.log` to catch any immediate errors after restart.

• **Step 1**: SSH into your server and verify your web server is running. For Apache: `sudo systemctl status apache2` or `sudo systemctl status httpd`. For Nginx: `sudo systemctl status nginx`. If the service is stopped or failed, review the service logs: `sudo journalctl -u apache2 -n 50` or `sudo journalctl -u nginx -n 50`.
• **Step 2**: Check your web server error logs. Apache: `/var/log/apache2/error.log` or `/var/log/httpd/error_log`. Nginx: `/var/log/nginx/error.log`. Look for segmentation faults, out-of-memory errors, or timeout messages corresponding to the error 520 timestamp.
• **Step 3**: Test direct IP access from your local machine: `curl -I http://your-server-ip` or `curl -I https://your-server-ip`. A successful response shows HTTP headers; a failed response indicates an application or configuration issue independent of Cloudflare.
• **Step 4**: Verify your firewall allows Cloudflare IP ranges. For iptables-based firewalls, ensure rules permit traffic from Cloudflare IPs. For UFW: `sudo ufw status` and verify port 80/443 are open. For firewalld: `sudo firewall-cmd --list-all` and verify http/https services are allowed. Cloudflare publishes its IP ranges at https://www.cloudflare.com/ips/; ensure your firewall configuration includes them.
• **Step 5**: Check application-level timeouts. For PHP-FPM, review `max_execution_time` and `request_terminate_timeout` settings. For Node.js applications, verify request timeout configurations in your application code or reverse proxy (Nginx proxy_read_timeout, Apache ProxyTimeout).
• **Step 6**: Review server resource usage: `top`, `htop`, or `free -m` to check memory usage; `df -h` to check disk space. If resources are exhausted, optimize your application, increase server resources, or implement caching.
• **Step 7**: If running a reverse proxy (Nginx proxying to Apache, or Nginx proxying to an application server), verify the backend is responding correctly. Test the backend directly: `curl -I http://localhost:backend-port`. Check proxy timeout settings to ensure they are sufficient for your application's response time.

Using Cloudflare Diagnostics and Temporary Workarounds

Temporary workarounds like pausing Cloudflare are diagnostic tools, not permanent solutions. Use them to isolate the issue, then address the root cause on your origin server or in your Cloudflare configuration. Leaving Cloudflare paused exposes your origin IP and removes DDoS protection and performance optimizations.

• **Pause Cloudflare on the domain**: In your Cloudflare dashboard under Overview, click 'Pause Cloudflare on Site.' This temporarily disables Cloudflare's proxy, routing traffic directly to your origin IP. If the error resolves, the issue involves Cloudflare's interaction with your origin (firewall rules, IP restrictions, or request headers). If the error persists, the problem exists on your origin server. Remember to unpause Cloudflare after testing to restore protection and caching.
• **Check Cloudflare's origin health**: Navigate to Analytics > Traffic in the Cloudflare dashboard and review origin response time and error rates. Spikes in response time or elevated 5xx errors from your origin confirm server-side performance issues.
• **Review Cloudflare cache settings**: Misconfigured cache rules or aggressive caching of dynamic content can cause incomplete responses. Under Caching > Configuration, verify your Cache Level setting and review Page Rules for overly broad caching directives.
• **Adjust Cloudflare timeout settings (Enterprise plans only)**: Standard Cloudflare plans enforce a 100-second origin response timeout. If your application requires longer processing time, contact Cloudflare support to discuss Enterprise features or optimize your application to respond faster.
• **Examine Cloudflare Firewall Events**: Under Security > Events, look for blocked or challenged requests around the error 520 timestamp. A misconfigured WAF rule might block or modify responses that trigger error 520. Adjust rule sensitivity or create exceptions as needed.

Preventive Measures and Long-Term Best Practices

Combining these practices creates a resilient hosting environment where error 520 occurrences are rare and, when they do occur, are quickly diagnosed and resolved. Treat each error 520 incident as a learning opportunity—document what caused it, what fixed it, and what monitoring or configuration changes will prevent it from recurring.

• **Implement origin health monitoring**: Set up external uptime monitoring (using services like UptimeRobot, Pingdom, or your hosting provider's monitoring tools) to alert you when your origin server becomes unresponsive or returns errors. Configure checks to test both direct IP access and Cloudflare-proxied access.
• **Configure server resource alerts**: Set up alerts for CPU usage above 80%, memory usage above 85%, and disk space usage above 90%. Proactively scaling resources or optimizing code prevents resource exhaustion that causes incomplete responses.
• **Maintain Cloudflare IP allowlisting**: Automate the process of updating your firewall rules to include Cloudflare's published IP ranges. Cloudflare occasionally adds new IP addresses; outdated firewall rules will block legitimate Cloudflare traffic. Use Cloudflare's API or regularly review their IP list page.
• **Test configuration changes in staging**: Before deploying changes to web server configurations, application code, or Cloudflare settings, test them in a staging environment that mirrors production. This identifies issues that might cause error 520 before they affect live traffic.
• **Keep detailed rollback plans**: Document your current working configurations (web server settings, Cloudflare rules, firewall rules) so you can quickly revert to a known-good state if a change introduces error 520. Use version control for configuration files and maintain backup snapshots of your server.
• **Review and optimize application performance**: Slow database queries, inefficient code, or unoptimized assets increase response times and the likelihood of timeouts. Regularly profile your application, implement caching (database query caching, object caching, full-page caching), and optimize asset delivery.
• **Schedule regular log reviews**: Periodically review your origin server logs for warnings, slow requests, or resource limit hits even when no errors are visible to end users. Early detection of degrading performance prevents outages.