内容摘要：打开网页，屏幕上跳出“522”这仨数字，后面跟着一句“Connection timed out”。你刷新了五次，没用。换浏览器，没用。手机流量也试了，还是没用。这时候你大概能确定一件事：问题不在你这边

打开网页，网站屏幕上跳出“522”这仨数字，错误后面跟着一句“Connection timed out”。解决你刷新了五次，网站没用。错误换浏览器，解决没用。网站手机流量也试了，错误还是解决没用。这时候你大概能确定一件事：问题不在你这边。网站

522是错误Cloudflare专属的错误码。Cloudflare你知道吧，解决全球最大的网站CDN和网络安全服务商之一，很多网站都挂在它后面。错误当你的解决浏览器请求到达Cloudflare的边缘节点，节点再去回源站取数据，结果TCP握手阶段就超时了——源站压根没回应。注意，是连不上，不是返回了错误内容。源站服务器要么挂了，要么防火墙把Cloudflare的IP挡了，要么网络链路出了问题。

我去年帮一个做跨境电商的朋友排查过这事。他的独立站突然522，急得不行，以为被攻击了。我先让他登录Cloudflare后台，看了一眼源站IP，然后直接在他服务器上ping了一下Cloudflare的节点地址——通的。反过来从外部ping源站IP，不通。问题就很清楚了：服务器本身没死，但外部访问被阻断了。最后查出来是他前几天改了iptables规则，把Cloudflare的IP段给误封了。

所以遇到522，先别慌。按这个顺序查：

第一步，确认源站是否存活。登录你的服务器，或者用另一台机器SSH上去，看看Web服务（Nginx/Apache）还在不在跑。命令很简单，systemctl status nginx 或者 ps aux | grep httpd，一眼就能看出来。如果服务停了，启动它，522大概率就消失了。

第二步，检查防火墙。这是最常见的坑。很多人服务器上装了防火墙或者安全组，只放行了80和443端口对“所有人”开放，但Cloudflare回源用的IP段是固定的，你得把这些IP段加进白名单。Cloudflare官方提供了IPv4和IPv6的IP列表，直接拉下来批量添加就行。iptables、ufw、云服务商的安全组，挨个检查一遍。我见过有人只加了IPv4忘了IPv6，结果部分用户522部分正常，排查了半天。

第三步，看源站是否在监听正确的端口。Cloudflare默认回源到80或443，但如果你在Cloudflare后台设置了自定义回源端口，服务器上也得对应开放。有一次一个开发者把Nginx监听改到了8080，忘了在Cloudflare那边同步修改，结果全站522。这种低级错误，偏偏最容易犯。

第四步，检查服务器负载。如果服务器CPU跑满、内存耗尽，TCP握手也会超时。用 top 或 htop 看一下负载。我有次遇到一台小鸡（低配VPS）被爬虫打满，SSH都卡得进不去，重启后加了Cloudflare的速率限制规则才稳住。

第五步，联系主机商。如果上面几步都没问题，那可能是机房网络故障或者上游路由问题。直接开工单问。别自己瞎折腾，有些事你控制不了。

顺便说一句，522和521、520不一样。521是源站拒绝连接，520是源站返回了未知错误。522纯粹就是连不上。区分清楚，能省不少时间。

还有个小技巧：如果你用的是Cloudflare的代理模式（小黄云），临时把记录改成“DNS only”（灰色云），让请求直连源站。如果直连能打开，那问题就锁定在Cloudflare回源链路上；如果直连也打不开，那就是源站自己的问题。这一招能快速缩小排查范围。

最后提醒一句，改完防火墙或服务配置后，别忘了在Cloudflare后台清一下缓存，有时候边缘节点还拿着旧的连接状态，清完再试更准。