Cloudflare 522 报错：连接超时，先找到哪一层出了问题

Cloudflare 522 是什么意思

522 是 Cloudflare 生成的 Connection Timed Out 响应，不是源站直接返回的。

关键区别：用户请求已经成功到达 Cloudflare，但 Cloudflare 在尝试与源站建立 TCP 连接时超时，或在规定时间窗口内未收到预期的握手确认。

翻成人话：

• 用户 → Cloudflare：正常
• Cloudflare → 源站：连接超时

大多数情况下，问题出在 Cloudflare 和源站之间：源站服务本身、防火墙或安全策略、DNS 配置、资源耗尽，或者网络路径。

少数情况下，区域性网络波动或 Cloudflare 自身的事故也可能造成 522。

所以看到 522，不要马上重启服务器，也不要假设是 Cloudflare 挂了。先判断是哪一层出了问题。

第一步：先缩小故障范围

在修改任何配置之前，先对症状分类：

• 直接访问源站也失败 → 先排查源站服务、监听端口、防火墙和上游网络
• 受控源站测试成功，但经 Cloudflare 代理的流量失败 → 排查源 IP 策略、Cloudflare IP 处理方式和路径差异。直接测试源站时，注意保留正确的 Host header 和 TLS SNI，否则可能因 Host/SNI 不匹配而掩盖真实故障
• 只有部分区域失败 → 调查区域路由、ISP 路径或边缘路径差异
• 高峰期间歇性出现 522 → 排查 CPU、连接队列、文件描述符、worker 和流量峰值
• 迁移或网络变更之后出现 522 → 检查 A/AAAA 记录、安全组、ACL 和最近的防火墙变更

这不能直接给出根因，但能快速缩小排查范围。

五种常见原因

1. 源站服务没有正确监听

"服务器在线"和"Web 服务可达"是两回事。这是成本最低的验证项——在动防火墙规则或 DNS 之前，先跑一条命令。

常见情况：

• Nginx 停了
• 服务只监听在 127.0.0.1
• 容器端口没有正确发布
• 443 端口没有监听
• 重启后应用没有自动启动

如何验证：

ss -tlnp
# 或者
netstat -tlnp

确认 80 / 443 是否在监听，绑定地址是 0.0.0.0 / :: 还是只有 127.0.0.1，以及对应进程是否持有该 socket。

Docker 或 Kubernetes 环境还需要继续检查端口映射、Service、Ingress 和 host 网络配置。

2. 防火墙或安全策略拦截了 Cloudflare 流量

Cloudflare 代理流量时，到达源站的连接通常来自 Cloudflare 基础设施的 IP，而不是访客的公网 IP。如果源站通过源 IP 白名单控制入站流量，而 Cloudflare 公布的 IP 段没有加进来或不完整，连接就会在到达 Nginx 或应用之前被丢弃。

不要只检查云服务商的安全组，以下层面都需要排查：

• iptables / nftables
• ufw / firewalld
• fail2ban
• 云安全组和网络 ACL
• 上游防火墙
• 第三方 WAF 或主机安全软件

如何验证：如果源站通过源 IP 限制入站流量，确认当前 Cloudflare IPv4 和 IPv6 的完整 IP 段已在服务实际使用的端口上放行。

注意：如果 80 和 443 已经对公网完全开放、且没有使用源 IP 限制，则不强制要求单独配置 Cloudflare 白名单。这种情况下，应排查意外拦截、速率限制、自动封禁或上游过滤。

3. 源站资源或连接耗尽

进程还在运行，不等于服务器还能接受新连接。

常见失效模式：

• CPU 持续饱和
• 内存压力
• TCP 监听队列满
• 文件描述符耗尽
• Nginx worker 容量不足
• 应用线程池耗尽
• 突发流量峰值

明显信号：平时运行正常，但高峰期出现间歇性 522。

如何验证：把 522 发生的时间窗口和以下指标对照：CPU 和负载均值、内存和 swap、TCP 连接状态、监听队列压力、文件描述符用量、Nginx 错误日志和应用日志。

不要只看服务器"现在"是否健康，要看 522 发生时 是什么状态。

4. A 或 AAAA 记录指向了错误的源站

如果 Cloudflare DNS 还指向错误的目标，源站本身再健康也没用。

需要检查的情况：

• 指向了旧服务器或已释放的公网 IP
• 指向了已下线的实例
• 指向了错误的负载均衡器
• 存在过期或配置错误的 IPv6 记录

一个常见的迁移失误：A 记录已更新到新源站，但 AAAA 记录仍指向旧的 IPv6 地址。这在双栈环境中会导致难以复现的间歇性故障。

如何验证：检查所有相关记录——A、AAAA、CNAME 以及历史遗留记录，确认每条有效记录都指向预期的目标。

5. 源站网络或中间路径问题

你本地到源站的路径，和 Cloudflare 到源站的路径不同。这意味着这种情况完全可能出现：本地访问正常，外部监控正常，但 Cloudflare 的某些路径仍然失败。

可能的原因：

• 云服务商区域性网络事件
• ISP 路由问题
• 上游 ACL 变更
• DDoS 防护行为干扰
• 最近的安全组或网络策略变更
• 跨区域连接不稳定

如何验证：使用 Cloudflare Trace 确认当前处理请求的边缘节点（colo），然后对比多个区域的结果，判断故障是否集中在某个地理区域。

注意这个限制：同区域的普通云主机并不能还原 Cloudflare 到你源站的实际网络路径。区域探测是有价值的参考，但不能证明 Cloudflare 到源站的路径是否健康。

推荐排查顺序

看到 522，在大范围修改配置之前，按这个顺序走：

1. 检查源站端口 — 80 / 443 是否真的在监听？服务是否绑定到了预期的网络接口？
2. 检查防火墙和安全策略 — 安全组、ACL、iptables、fail2ban、上游 WAF，是否意外拦截了 Cloudflare 流量？
3. 检查源站容量 — CPU、内存、活跃连接数、backlog、文件描述符、Nginx / 应用 worker
4. 检查 DNS — A、AAAA、CNAME、历史遗留记录、最近是否有迁移变更
5. 看日志 — Nginx access log、Nginx error log、应用日志、系统日志
6. 看区域分布规律 — 只有部分用户受影响吗？故障是否集中在某个地区？

一个有用的判断依据：如果故障时间窗口内 Web 服务器 access log 里没有对应请求记录，说明故障可能发生在 HTTP 请求到达 Web 服务器之前——优先排查端口、防火墙和网络。如果 access log 里有对应记录，则继续往上层排查。

522 与其他 Cloudflare 5xx 错误的区别

| 错误码 | 含义 | | ------- | ----------------------------------- | | 521 | 源站拒绝或无法接受连接 | | 522 | Cloudflare 与源站之间的连接超时 | | 523 | Cloudflare 无法到达源站 | | 524 | 连接建立成功，但 HTTP 响应耗时过长 | | 525 | Cloudflare 与源站之间 SSL 握手失败 | | 526 | Cloudflare 无法验证源站 SSL 证书 |

简单记法：

• 521 → 连接被拒
• 522 → 连接超时
• 523 → 源站不可达
• 524 → 已连接，但响应太慢
• 525 / 526 → TLS 或证书问题

不同错误码指向不同的故障层，尽早区分可以避免走弯路。

用 Website Check 快速拿到第一手数据

手动逐项排查对真实故障仍然必要，但 Website Check 可以帮你完成第一轮快速诊断。

它能一次返回：DNS 解析、HTTP 状态、SSL / TLS 信息、CDN 特征，以及结构化的检查结果。

这些数据不能替代源站日志、防火墙规则或云监控。但它能帮你快速回答第一个问题：应该先查 DNS、HTTP、TLS，还是继续深入源站和网络路径？

好的故障响应，很少靠一个按钮解决。它从找到真正出问题的那一层开始。