最近线上一个站点频繁出现 Cloudflare 522，刚开始以为是服务器资源不够，结果一路排查下来发现根本不是这么回事。 这篇记录把整个排查过程、判断逻辑、容易误判的点、以及最终原因梳理一下，给遇到类似问题的朋友一个参考。
一、522 到底是什么？ Cloudflare 官方解释：
522 = 连接源站超时（ Connection timed out ）
本质是：
Cloudflare 节点已经接收到用户请求 Cloudflare 尝试连接你的源站服务器 在规定时间内没有完成 TCP 建立
也就是说： 不是 Cloudflare 问题，是 Cloudflare 到你服务器之间的链路出问题。 重点是：
不是页面慢，是“连不上”
二、常见误区 很多人第一反应是：
服务器挂了？ CPU 100%？ 内存爆了？ Nginx 崩了？
但实际上 522 更多时候和以下有关：
源站防火墙拦截了 Cloudflare IP 源站带宽跑满 TCP backlog 满 丢包严重 线路回程异常 云厂商侧网络抖动
服务器本身未必有问题。
三、第一步：确认服务器是否“真的挂了” 先从最简单的开始。 在服务器上执行： top
看：
CPU 是否打满 load average 是否异常 是否有异常进程
然后： free -m
确认内存没有被打爆。 接着看 Nginx： systemctl status nginx
如果 nginx 正常，CPU 正常，内存正常，说明：
服务器没挂
四、第二步：是否防火墙拦了 Cloudflare Cloudflare 有固定 IP 段。 可以用： iptables -L -n
或者 ufw status
确认没有限制 CF IP 。 有时候 fail2ban 会误封。
五、第三步：是否 TCP 队列满 这一步很多人忽略。 查看： netstat -an | grep SYN_RECV | wc -l
如果大量 SYN_RECV ，说明半连接队列爆了。 再看： sysctl net.core.somaxconn
如果值太小（默认 128 ），在高并发下可能不够。 可以调整： net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 65535
六、第四步：是否带宽跑满 执行： iftop
如果带宽已经满载，比如 100M 打满。 Cloudflare 连过来就会超时。 很多人忽略：
100M 带宽在高峰时段其实很容易满。
尤其是：
视频站 下载站 被扫站
七、第五步：用 mtr 看丢包 这是关键。 在本地执行： mtr -rw 你的服务器 IP
看：
是否某一跳开始丢包 是否晚高峰严重 是否回程绕路
有一次排查发现：
回程绕美西
延迟从 20ms 变成 180ms 。 Cloudflare 到源站那一段开始丢包。 服务器本身完全正常。
八、真实案例：问题不在服务器 那次问题最终定位：
CPU 20% 内存正常 nginx 正常 带宽没满 TCP 队列正常
但 mtr 显示： 某骨干节点开始 20% 丢包。 而且：
晚上 8 点之后必出 522
典型线路拥堵。
九、Cloudflare 522 和 524 的区别 很多人混淆。
522：TCP 连不上 524：连上了，但响应超时
524 更像后端慢。 522 更像网络层问题。
十、如何系统判断 522 原因？ 我后来总结一个判断流程： 1️⃣ 本机资源正常？ 2️⃣ nginx 是否监听？ 3️⃣ 防火墙是否拦 CF ？ 4️⃣ TCP 队列是否满？ 5️⃣ 带宽是否满？ 6️⃣ mtr 是否丢包？ 7️⃣ 是否固定时间段出现？ 只要按顺序走，不会乱。
十一、一个关键点：线路稳定性比延迟更重要 很多人只看 ping 延迟。 其实：
稳定性 > 低延迟
20ms 但偶尔丢包，比 40ms 稳定更糟。 尤其是被 Cloudflare 代理后，回程异常更容易触发 522 。
十二、几个实用优化建议 ① 开启 keepalive keepalive_timeout 65;
② 调整 worker_connections worker_connections 65535;
③ 调整系统文件数 ulimit -n 100000
④ 合理选择线路 这个真的比堆配置重要。
十三、结论 522 不等于服务器不行。 大多数时候是：
网络层问题 带宽瓶颈 回程异常 丢包
真正需要学会的是：
用数据判断，而不是凭感觉。
十四、我的教训 那次我第一反应是：
加配置
结果完全没用。 真正解决问题的是：
换了一条更稳定的线路
服务器规格没变。 问题消失。
如果有人最近也在被 522 折磨，可以按上面的顺序排查。 别一上来就重装系统，也别盲目升级配置。 大概率不是你想的那个问题。