Cloudflare 521 怎么解决？先别清缓存，按这条链路排查

网站突然弹出 Web server is down — Error code 521，第一反应常常是清 Cloudflare 缓存、改 DNS。但 521 通常和这些设置无关。

它表示：Cloudflare 能接到用户请求，但源站拒绝了 Cloudflare 的连接。 问题往往落在源站 Web 服务、防火墙、云安全组、WAF，或源站前面的负载均衡器上。

因此，处理 521 时最该先看的不是浏览器，也不是缓存，而是两件事：Web 服务有没有正常监听端口；服务器有没有把 Cloudflare 的 IP 拒绝掉。 Cloudflare 把「源站 Web 服务离线」和「Cloudflare 请求被拦截」列为最常见原因，详见 Error 521 文档。

如果你只是网站访客，没有服务器或 Cloudflare 控制台权限，本地修不了 521。请保存报错页面的 URL、发生时间和 Ray ID，发给网站管理员或主机商。Cloudflare 支持也只协助域名所有者排障。

先确认错误码：521 和其他 5xx 不一样

Cloudflare 的 5xx 页面外观很接近，排查方向却差很多。521 的关键词是拒绝连接。如果实际是连接超时或应用响应慢，应该按 522、524 的思路查，而不是一味添加 IP 白名单。各错误码的官方说明见 Cloudflare 5xx errors。

错误码	实际含义	先查哪里
521	源站拒绝 Cloudflare 的连接	Web 服务、80/443 监听、防火墙、WAF、封禁规则
522	连接或初始响应超时	网络路径、服务器负载、连接队列、超时设置
523	Cloudflare 到不了源站	DNS、路由、源站 IP 可达性
524	已连上源站，但处理时间过长	PHP、数据库、接口、长任务
525 / 526	TLS 握手或严格证书校验失败	443、TLS、证书链、证书域名和有效期

521 最常见的 5 类原因

Web 服务没起来，或根本没在监听端口

Nginx、Apache 或 Caddy 停止后，Cloudflare 连不上源站，就会返回 521。服务停止不一定是有人手动关掉：发布时配置写错、磁盘占满、内存耗尽、证书文件权限不对，或系统杀掉了进程，都可能让 80 或 443 不再提供服务。

有 SSH 权限时，先在服务器上跑下面几条命令。它们只查看状态，不会改配置。

# 服务是否仍在运行；按实际环境选择
sudo systemctl status nginx --no-pager
sudo systemctl status apache2 --no-pager

# 80 和 443 是否真的被进程监听
sudo ss -ltnp '( sport = :80 or sport = :443 )'

# 看最近的报错，以及磁盘 / 内存是否耗尽
sudo tail -n 100 /var/log/nginx/error.log
free -h
df -h

Debian / Ubuntu 上 Apache 服务名通常是 apache2；RHEL / CentOS 上可能是 httpd。

如果服务状态异常，先看日志再修复。Nginx 改完配置要先跑 sudo nginx -t，通过后再 reload；Apache 则先执行 sudo apache2ctl configtest。不建议一出问题就反复重启。重启有时会让页面暂时恢复，但也会把 OOM、端口冲突和错误发布这些线索盖住。

防火墙、云安全组或主机 WAF 拦了 Cloudflare

开启 Cloudflare 代理后，源站看到的不是每个访客的真实 IP，而是 Cloudflare 的出口 IP。对防火墙来说，这些 IP 可能在短时间内产生大量连接。如果 UFW、iptables、云安全组、主机商 WAF 或 Fail2ban 因此触发封禁，Cloudflare 的请求会被拒绝，最终就会看到 521。

这里容易走两个极端：要么只白名单一个 Cloudflare IP，要么直接把源站 80/443 对全网开放。两种都不合适。正确做法是：仅在需要的 Web 端口上，允许 Cloudflare 官方公布的完整 IPv4 和 IPv6 网段。 IP 清单应以 Cloudflare 官方 IP 页面为准，不要抄旧教程里的静态列表。

如果使用 UFW，规则形式如下。示例 CIDR 只是写法示范，不是完整白名单：

# 示例：允许一个 Cloudflare IPv4 网段访问 80 和 443
sudo ufw allow from 173.245.48.0/20 to any port 80 proto tcp
sudo ufw allow from 173.245.48.0/20 to any port 443 proto tcp
sudo ufw status numbered

改完 UFW 还不够。云服务器通常至少有两层规则：操作系统防火墙和云厂商安全组。若站点前面还有 WAF、DDoS 防护、负载均衡器或宝塔等控制面板，也要检查这些层面是否记录了 DROP、REJECT、ban 或速率限制。

Fail2ban、WordPress 安全插件或限速规则误伤了 Cloudflare

这是 521 里比较难发现的一种。没有正确恢复真实访客 IP 时，Nginx、Apache、WordPress 安全插件和 WAF 可能把所有用户都看成 Cloudflare 的几个出口 IP。某个用户触发登录保护或限速后，安全规则封掉的是 Cloudflare，而不是那个用户；结果就是同一出口上的其他访问也一起受影响。

不要因此关闭全部安全功能。正确顺序是：只信任来自 Cloudflare 网段的代理请求，再把 CF-Connecting-IP 作为真实客户端地址，用真实 IP 做限速、审计和封禁。 如果对所有来源无条件信任这个请求头，攻击者可以绕过 Cloudflare 后伪造 IP。配置说明见 Restoring original visitor IPs。

Nginx 常见配置如下。正式环境需要补全 Cloudflare 官方公布的所有 IPv4 和 IPv6 网段；只配置一个示例网段，会留下间歇性 521 的隐患。

# 例如：/etc/nginx/conf.d/cloudflare-realip.conf
set_real_ip_from 173.245.48.0/20;
# 继续填入 Cloudflare 官方公布的其余 IPv4 / IPv6 CIDR

real_ip_header CF-Connecting-IP;
real_ip_recursive on;

保存后，先执行 sudo nginx -t，确认语法正确后再 reload。Apache 站点应使用 mod_remoteip 和 RemoteIPTrustedProxy。Cloudflare 已不再维护旧的 mod_cloudflare，并建议改用 mod_remoteip。

SSL/TLS 模式和源站端口对不上

如果 Cloudflare 的 SSL/TLS 模式是 Full 或 Full (Strict)，源站应在 443 上接受 HTTPS 连接；使用 Flexible 时，源站通常要能通过 80 提供 HTTP。Cloudflare 在 521 排障文档中明确要求，源站应用应监听与 SSL/TLS 模式相匹配的端口。

Cloudflare SSL/TLS 模式	源站要求	实际建议
Flexible	HTTP/80 可用	适合临时兼容，不适合作为长期生产配置
Full	HTTPS/443 可用，源站有证书	允许自签名或 Origin CA，但不验证证书身份。见 Full encryption mode。
Full (Strict)	HTTPS/443 可用，证书有效、可信并匹配域名	生产环境优先选择。

443 没有监听或被防火墙拒绝时，仍可能表现为 521。反过来，如果 443 已经通了，但 TLS 协商或严格证书校验失败，报错往往会转成 525 或 526。把两类问题分开，能少走很多弯路。

负载均衡、容器或端口配置出了问题

在云上，源站并不总是一台虚拟机。连接链路可能是 Cloudflare → 负载均衡器 → Ingress → 容器。负载均衡器把后端全部摘除、Ingress 没有可用 Pod、后端安全组拒绝流量，或健康检查持续失败，都可能让 Cloudflare 最后拿到 521。

这类问题要顺着链路查：先看负载均衡器监听器和目标健康状态，再看安全组和 Ingress Controller，最后检查 Pod 和应用日志。Cloudflare 也特别提示，根因不一定写在 Web 服务器日志里，还可能存在于中间的负载均衡器、缓存、代理或防火墙。

另外，Cloudflare 代理不是所有端口都支持。普通网站最好使用 80/443；如果 URL 写了其他端口，先到官方端口清单确认是否受支持。Cloudflare 支持多组 HTTP/HTTPS 端口，但部分非标准端口默认不缓存。

一套按成本从低到高的排查顺序

521 经常拖很久，不是因为问题复杂，而是排查顺序错了。下面按成本从低到高检查，通常能较快缩小范围。

顺序	要检查的内容	正常状态
1	Nginx、Apache、Caddy 与应用进程	服务运行中，80/443 处于 `LISTEN`
2	服务日志、内存、磁盘、OOM 记录	没有持续重启、磁盘满或进程被系统杀掉
3	UFW/iptables、云安全组、WAF、Fail2ban	Cloudflare 完整 IP 网段没有被拒绝、封禁或限速
4	Cloudflare SSL/TLS 模式和源站监听	Flexible 对应可用的 80；Full / Strict 对应可用的 443
5	真实访客 IP 配置	只信任 Cloudflare 代理，再基于真实 IP 执行安全规则
6	Cloudflare 侧的错误数据	521 不再增加，Ray ID 能和源站日志对应

在 Cloudflare 控制台打开 Analytics → HTTP Traffic（部分账户显示为 Analytics & Logs），按 Edge status code 或 Origin status code 过滤 5xx。它可以帮助你看到异常 URL、来源和 Cloudflare 数据中心等线索。Error Analytics 基于约 1% 的流量样本；若账户可用 Log Explorer，还可以用错误页中的 Ray ID 查单个请求。

没有服务器权限时，怎样找主机商处理

共享主机、托管 WordPress 或 SaaS 建站用户通常无法看防火墙。工单只写「网站打不开」很难让对方快速定位。Cloudflare 建议提供错误码、发生时间与时区、完整 URL；Ray ID 也应一并附上。

可以直接使用下面这段：

自 YYYY-MM-DD HH:MM UTC 起，访问 https://example.com/path 出现 Cloudflare Error 521 — Web server is down。请检查源站 Web 服务、主机防火墙 / WAF / Fail2ban、负载均衡器及上游代理，确认它们没有拒绝或限速 Cloudflare 官方 IPv4/IPv6 网段。相关 Ray ID：填写 Ray ID。Cloudflare SSL/TLS 模式为 填写模式；请同时确认源站 80/443 的监听状态和后端健康状态。

这段话没有预设根因，但给足了技术支持需要的定位信息。

修完以后，别只看首页能不能打开

间歇性 521 最容易被误判为「已经好了」。一次刷新成功，可能只是请求刚好走到了没出问题的节点，或者自动封禁规则暂时没有命中。建议从三层完成验证：

验证位置	检查方式	通过标准
源站本机	查看服务、端口和健康检查	服务稳定，预期端口正常监听
网络边界	查看安全组、防火墙、WAF 和规则日志	Cloudflare 网段可访问，源站没有被不必要地暴露
用户请求	通过已开启 Cloudflare 代理的域名访问，观察 Cloudflare 错误趋势	没有新增 521，必要时能用 Ray ID 关联日志

后续运维中，把 Cloudflare 官方 IP 清单纳入配置管理，正确恢复真实访客 IP，并为服务状态、证书到期、磁盘、内存、负载均衡健康度和 521 错误率建立告警。若你的源站不适合对公网开放入站端口，还可以评估 Cloudflare Tunnel：它让源站主动建立仅出站连接，减少公开 IP 和入站监听的需求。

常见问题

清 Cloudflare 缓存能解决 521 吗？

通常不能。缓存不会让已经停止的 Web 服务重新监听 80/443，也不会解除防火墙对 Cloudflare 的封禁。

关闭 Cloudflare 代理（橙云变灰云）能解决吗？

把该记录的代理状态从「已代理」（橙色云朵）改成「DNS only」（灰色云朵）可以作为短时间诊断，帮助判断问题是否出在 Cloudflare 到源站这一段。但它会绕过 Cloudflare 的代理和防护，不应作为长期方案。问题仍应回到源站服务和允许规则上解决。

为什么只有部分地区、或偶尔才出现 521？

常见原因包括：只放行了部分 Cloudflare 网段、WAF 或 Fail2ban 间歇性封禁、负载均衡器只有部分后端异常，或者某些出口 IP 被安全设备拒绝。用发生时间和 Ray ID 对照防火墙、负载均衡器、系统与应用日志，通常能看到规律。

521 就是服务器宕机吗？

不一定。Web 服务停止会造成 521，但服务器在线时，防火墙、云安全组、WAF 或速率限制主动拒绝 Cloudflare，同样会返回 521。

总结

521 的关键不是「Cloudflare 坏了」，而是源站拒绝了 Cloudflare。从服务状态、端口监听、防火墙与 Cloudflare IP 放行开始查，再核对 TLS 模式和真实访客 IP，通常比清缓存、反复切换代理有效得多。

问题一时找不到时，不要只凭刷新结果判断。把发生时间、URL、Ray ID、SSL/TLS 模式以及同一时段的源站、防火墙和负载均衡日志放在一起，才能判断究竟是服务崩溃、规则误封还是中间链路异常。