Cloudflare 报错 521/522/524 是什么意思？排查与解决方法

引言

给网站套上 Cloudflare 之后，本来图的是加速和安全，结果访客打开却看到一张 Cloudflare 的报错页，上面写着 Error 521: Web server is down、Error 522: Connection timed out 或 Error 524: A timeout occurred。你直接访问服务器 IP 或者用直连域名访问却是正常的，偏偏走 Cloudflare 就打不开，于是怀疑是不是 Cloudflare 挂了。其实这三个错误都指向同一个方向——Cloudflare 连不上你的源服务器（也就是你真正放 WordPress 的那台主机）。差别在于「连不上」的具体阶段不同：521 是源站拒绝连接，522 是连接超时，524 是连上了但源站迟迟不给回应。搞懂它们分别卡在哪一步，才能对症下药。这篇会把三种错误拆开讲清，给你一套从易到难的排查顺序。

故障原因分析

源服务器宕机或重启中。Web 服务（Nginx/Apache）没运行、面板在升级、服务器正在重启，Cloudflare 自然连不上，通常表现为 521。

防火墙拦截了 Cloudflare 的 IP。这是新手最容易踩的坑。为了防攻击，你在服务器上只放行了自己的 IP，把 Cloudflare 的一大段 IP 段挡在门外，导致 521 或 522。因为 Cloudflare 是「代理」，访客请求都从它的节点发出。

端口或协议不匹配。源站只监听 80，而 Cloudflare 按 443 去连；或者 SSL 模式配置错误，连不上对应端口就报 521/522。

源站响应太慢。PHP 脚本执行时间长，超过 Cloudflare 默认约 100 秒的等待上限，就报 524。常见于大批量导入、未加缓存的动态请求、慢查询。

主机商网络或负载问题。源站所在机房网络抖动、CPU 打满，请求处理不过来，也会触发 522 或 524。

分步解决方案

第一步：确认源站本身是否正常

先在服务器上用命令确认 Web 服务在跑，并在服务器本地 curl 一下自己，绕过 Cloudflare 检查源站：

# 检查 Nginx 是否运行
systemctl status nginx

# 从服务器本地直接访问源站，看是否返回正常页面
curl -I http://127.0.0.1

如果本地都返回不了 200，说明问题在源站本身，先把 Web 服务和站点修好，与 Cloudflare 无关。

第二步：放行 Cloudflare 的 IP 段

这是解决 521/522 的高频关键。你需要把 Cloudflare 官方公布的 IP 段加入服务器防火墙白名单。Cloudflare 的 IPv4 段包括 173.245.48.0/20、103.21.244.0/22、104.16.0.0/13、172.64.0.0/13 等，IPv6 段以 2400:cb00::/32、2606:4700::/32 开头。完整列表以 Cloudflare 官方文档为准。以 iptables 为例：

# 放行常见 Cloudflare IPv4 段（示例，实际请以官方最新列表为准）
iptables -I INPUT -s 173.245.48.0/20 -j ACCEPT
iptables -I INPUT -s 103.21.244.0/22 -j ACCEPT
iptables -I INPUT -s 104.16.0.0/13 -j ACCEPT
iptables -I INPUT -s 172.64.0.0/13 -j ACCEPT
iptables -I INPUT -s 162.158.0.0/15 -j ACCEPT

用宝塔面板的话，可以在「安全」里把这些网段逐条添加为放行规则，或临时关闭防火墙验证是否是这个原因。如果关掉防火墙后网站立即恢复，就基本坐实是 IP 被拦。

第三步：检查端口与 SSL 模式

进入 Cloudflare 后台「SSL/TLS」页面，确认加密模式。源站没有安装证书时选「Flexible（灵活）」比较稳妥，此时 Cloudflare 用 HTTP 连源站；源站已装有效证书可选「Full」或「Full (strict)」。如果选了 Full 但源站没有可用证书，Cloudflare 连 443 会失败，出现 521。同时确认源站确实监听了 80 和 443。

第四步：应对 524 超时

524 说明连接成功但源站响应超过了 Cloudflare 的等待时间（免费版约 100 秒，无法自定义）。处理方向有两个：

减少单次请求耗时：给 WordPress 装上页面缓存插件、对象缓存，优化数据库，减少慢查询；批量任务改用 WP-CLI 在命令行跑，不走 HTTP。
对确实需要长时间运行的操作，把它拆成小批次执行。
企业版可以在 Cloudflare 里调整超时时间，免费版只能靠优化源站。

第五步：检查服务器负载与主机商

用 top 查看 CPU 和内存占用，确认不是某进程把服务器拖垮。如果服务器资源一直吃紧，联系主机商升级配置或排查网络问题。也可以在 Cloudflare 「Speed」里开启一些优化，减轻源站压力。

常见踩坑点

只放行自己 IP 就开防火墙。套了 Cloudflare 后访客 IP 都是 Cloudflare 的，必须放行它的网段，否则等于把正常流量全挡了。

Cloudflare IP 段写死一次就不更新。官方偶尔会新增网段，建议定期核对，或直接使用主机面板/插件自动同步的规则。

以为 522 一定是 Cloudflare 的锅。绝大多数 522 问题都出在源站被拦、宕机或响应过慢上。

SSL 模式乱选导致重定向循环。源站装了证书又强制 HTTPS，同时 Cloudflare 用 Flexible，可能出现「重定向次数过多」，要统一加密策略。

524 一直加超时而不优化。免费版根本改不了等待时间，一味找「超时设置」是白费功夫，应该从缓存和性能入手。

总结

Cloudflare 的 521、522、524 本质是同一件事的三个阶段：521 是源站拒绝连接，522 是连接源站超时，524 是连上了但源站回应太慢。排查顺序建议是：先确认源站 Web 服务是否正常，再重点检查防火墙有没有放行 Cloudflare 的 IP 段，接着核对端口和 SSL 加密模式，最后针对 524 做缓存和性能优化、减少单次请求耗时。多数站长遇到的 521/522 都是防火墙把 Cloudflare 挡了，放行官方 IP 段就能解决；524 则要回到站点本身找耗时大户。把这几个错误的含义分清，下次看到 Cloudflare 522 报错页，你就能第一时间判断问题在源站而不是别人家的网络。

Cloudflare 报错 521/522/524 是什么意思？排查与解决方法

引言

故障原因分析