Cloudflare 显示 520 错误但源站正常怎么回事如何修复

Cloudflare 显示 520 错误但源站能 ping 通，通常是因为源站应用层返回了空内容、响应头过大或连接被意外重置，优先排查源站错误日志和防火墙规则。

先说结论：520 错误代表 Cloudflare 收到了源站的 TCP 连接，但 HTTP 响应不符合预期，问题大概率在源站应用配置而非网络连通性。

先确认：源站 Web 服务（Nginx/Apache）及 PHP-FPM 是否正在运行
先处理：检查源站错误日志、Cloudflare 后台安全事件及响应头大小
再验证：绕过 Cloudflare 直接访问源站 IP 确认是否复现

命令速用版

在源站服务器上执行以下命令，快速查看服务状态和响应头：

# 检查 Web 服务状态
systemctl status nginx
# 或
systemctl status httpd

# 检查 PHP-FPM 状态（常见 520 诱因）
systemctl status php-fpm

# 本地测试响应头大小
curl -I http://localhost

# 查看实时错误日志
tail -f /var/log/nginx/error.log

为什么会这样

520 错误与其他 5xx 错误不同，它不是单纯的超时或连接拒绝。Cloudflare 作为反向代理，已经成功与源站建立了 TCP 连接，但源站返回的 HTTP 响应头为空、包含了未知指令，或者在传输数据前就关闭了连接。常见情况包括 PHP 进程崩溃、源站防火墙拦截了 Cloudflare 的请求、或者 SSL 握手配置不一致导致数据流中断。

分步处理

检查源站服务状态
登录源站服务器，确认 Web 服务进程存在。如果是 PHP 网站，务必检查 PHP-FPM 状态，进程崩溃会导致连接重置。
排查响应头大小
Cloudflare 对响应头大小有限制，如果源站返回的 Header 过大（例如过多的 Cookie 或自定义头），会被判定为无效响应。检查应用代码是否写入了大量日志到 Header 中。
检查防火墙规则
确认源站防火墙（如 iptables、安全组）没有拦截 Cloudflare 的 IP 段。如果源站只允许特定 IP 访问，需将 Cloudflare 的 IP 段加入白名单。

获取 Cloudflare IP 段：可通过命令 curl https://api.cloudflare.com/client/v4/ips 获取，或访问官方列表 https://www.cloudflare.com/ips/。
查看 Cloudflare 后台日志
登录 Cloudflare Dashboard，进入分析 -> 安全 -> 事件，查看是否有来自源站的异常连接记录或 WAF 拦截记录，辅助定位问题。
核对 SSL 设置
在 Cloudflare 后台 SSL/TLS 设置中，如果源站没有有效证书，将 SSL 模式调整为“完全”模式（加密但不验证证书），避免握手失败。不要随意使用“完全（严格）”除非源站有可信证书。

怎么验证是否生效

修复后，在本地终端使用 curl 命令带上 Host 头直接请求源站 IP，确认能拿到正常的 HTTP 200 响应。同时刷新浏览器，观察 Cloudflare 缓存是否已更新。

curl -H "Host: yourdomain.com" http://your_origin_ip

如果返回 200 OK 且内容正常，说明源站已恢复，Cloudflare 侧通常会在几分钟内自动恢复代理。

常见坑

缓存误导：有时源站已修复，但浏览器或 Cloudflare 边缘节点缓存了错误页面，尝试强制刷新或清除缓存。
日志轮转：排查问题时确认正在查看的是当前有效的日志文件，而非已轮转的旧日志。
IP 封禁：某些安全插件（如 Wordfence）可能误判 Cloudflare 流量为攻击，需在插件内 whitelist Cloudflare IPs。

参考来源

Cloudflare 官方支持中心，Troubleshooting Cloudflare 5xx errors，https://developers.cloudflare.com/support/troubleshooting/cloudflare-errors/troubleshooting-cloudflare-5xx-errors/