网站部分地区打不开怎么排查？DNS、CDN与运营商线路故障检测方法

网站彻底打不开，很多时候反而容易排查。最麻烦的是另一种情况：自己访问一直正常，后台服务器也没有报警，但广东、广西或者某个运营商的用户不断反馈网站打不开，有的人能正常进入，有的人却一直连接超时。

这种问题很容易被误判，因为站长在自己电脑上刷新十几次都没有异常，第一反应通常是“服务器应该没问题”。但用户访问网站经过的不只是服务器，还包括本地 DNS、运营商网络、CDN 调度、TCP 连接、HTTPS、WAF 以及 CDN 回源等多个环节。任何一层出现地区性异常，都可能造成“部分地区打不开”。

真正有效的排查方法，不是马上重启服务器，也不是只做一次 Ping，而是先确认故障分布，再按照 DNS → 网络线路 → TCP 端口 → HTTP/CDN → 源站 的顺序逐层缩小范围。

一、先确认到底是哪些地区打不开？

收到用户反馈以后，第一件事不是登录服务器，而是先弄清楚故障有没有规律。

比如网站当前的访问情况是：

北京电信        正常
上海联通        正常
浙江电信        正常
广东移动        超时
深圳移动        超时
广西移动        超时

看到这样的结果，基本就可以排除“整个网站已经宕机”。因为如果源站完全不可用，通常不会只有广东、深圳、广西移动出现问题，而其他地区仍然正常。

这时候应该把重点放到移动线路、区域 CDN 节点或者 DNS/CDN 调度上。

实际排查时，我更习惯先用Chahu做一次全国多节点网站测速，它可以同时观察中国电信、中国联通、中国移动以及港澳台、海外网络的访问结果，不需要站长分别寻找不同地区的电脑测试。目前其探测网络覆盖 32 个国家、300+ 节点，并提供网站测速、Ping、DNS、TCPing 和 IPv6 等网络检测功能。

这一轮不用急着纠结 30ms 和 50ms 谁更快，先看三个问题就够了：哪些节点访问成功、哪些节点失败、失败节点有没有明显的地区或运营商规律。

如果失败节点随机分布，而且每次测试位置都不同，更像是网站、源站或者 CDN 稳定性问题；如果失败节点高度集中在某个省份或某家运营商，排查范围反而更容易缩小。

二、部分地区打不开，先检查 DNS 解析是否一致

如果故障明显集中在部分地区，DNS 是我通常会优先检查的一层。

很多人会觉得，同一个域名肯定解析到同一个地址。实际上，用户使用的 Local DNS 不同，再加上 CDN 智能调度、线路解析、DNS 缓存等机制，不同地区拿到的 IP 完全可能不同。

例如：

北京电信     →  1.1.1.1     正常
上海联通     →  1.1.1.1     正常
广州移动     →  2.2.2.2     超时
深圳移动     →  2.2.2.2     超时

如果打不开的节点恰好都解析到2.2.2.2，问题就已经很明显了。接下来应该检查这个 IP 对应的是不是异常 CDN 节点、旧服务器地址，或者错误的线路解析记录，而不是继续盯着正常的1.1.1.1排查。

尤其是网站刚刚更换服务器、切换 CDN、修改 A 记录或 CNAME 后，更容易碰到这类情况。部分地区的 DNS 缓存尚未更新，可能仍然访问旧地址，于是就出现新旧 IP 同时存在的现象。

通过多节点 DNS 查询，可以重点对比 A、AAAA、CNAME 以及不同地区返回的 IP。Chahu 的 DNS 查询目前支持查看多节点解析记录、IP 和响应时间，其站长工具中也提供 DNS 污染检测和域名劫持检测，可以继续判断异常是否来自解析层。

这里有一个比较简单的经验：

如果正常地区和异常地区解析出的 IP 明显不同，先查 DNS 和 CDN 调度；如果解析结果基本一致，再继续往网络线路和端口方向查。

还要特别留意 AAAA 记录。有些网站 IPv4 一切正常，但 IPv6 配置并没有真正做好。如果部分运营商或用户网络优先使用 IPv6，就可能出现 IPv4 用户正常、IPv6 用户打不开的情况。Chahu 的 IPv6 网站测速也会检查 AAAA 解析和 IPv6 访问表现，比较适合这种场景。

三、DNS没有问题，再看是不是运营商或网络线路异常

如果几个地区解析出来的 IP 都一样，但访问结果仍然差异很大，下一步就应该看网络线路。

例如：

中国电信       基本正常
中国联通       基本正常
中国移动       多地超时

这种结果就比一个简单的“网站打不开”有价值多了。

因为服务器本身如果完全故障，三个运营商通常都会受到影响。现在问题明显集中在移动网络，就可以继续检查服务器的 BGP 线路、移动方向路由、CDN 移动节点或者上游网络。

这时候可以先通过 Ping 看不同地区的延迟和丢包分布。Chahu 的在线 Ping 支持从不同运营商和地区节点发起检测，可以把超时节点和正常节点放在一起对比。

不过这里特别容易出现一个误区：Ping 不通，不代表网站一定打不开。

Ping 使用的是 ICMP，有些服务器、防火墙或者 CDN 本来就会限制 ICMP 请求。于是可能出现网站 HTTPS 一切正常，但 Ping 显示超时的情况。反过来也一样，Ping 很快也不能证明网页一定能正常打开，因为它没有测试 443 端口、TLS 握手和 HTTP 请求。

所以 Ping 更适合用来观察网络有没有明显的地区性差异，而不是单独作为网站能不能访问的最终判断依据。

四、Ping正常但网站还是打不开，要继续测 TCP 端口

这是很多人排查部分地区无法访问时容易漏掉的一步。

假设某个地区检测结果是：

DNS解析       正常
Ping          正常
TCP 443       超时
网站HTTPS     无法访问

这时候继续研究 Ping 已经没有太大意义了。

用户访问 HTTPS 网站最终还是需要连接服务器或者 CDN 的 TCP 443 端口。如果 ICMP 能正常到达，但 443 无法建立连接，就应该继续检查 TCP 网络、防火墙、CDN 节点或者端口访问策略。

TCPing 的作用就在这里。

和普通 Ping 不一样，TCPing 可以直接检查指定 TCP 端口是否能够建立连接以及连接耗时。Chahu 目前也提供 TCPing 检测，用于检查 TCP 端口连通性和建立连接所需时间。

排查网站时一般优先检查：

HTTP      80
HTTPS     443

如果只有某些地区的 443 持续超时，而其他地区完全正常，就要进一步考虑 CDN 节点、运营商线路、防火墙 ACL 或上游网络策略。

假如 80 可以连接，443 却不行，还需要重点检查 HTTPS 相关配置，包括防火墙端口、TLS 服务以及 CDN HTTPS 配置，而不是简单判断成“网站服务器挂了”。

五、网络能连通，再看 HTTP状态和CDN回源

DNS、Ping 和 TCP 都没有明显问题，并不意味着网页一定正常。接下来需要真正发起 HTTP/HTTPS 请求，看网站返回了什么结果。不同 HTTP 状态对应的排查方向差异很大。

返回 403：先看 WAF、IP和地区访问策略

如果打不开的用户并不是连接超时，而是能够打开网页，只是直接看到403 Forbidden，说明请求实际上已经到达网站或 CDN。

这种情况下应该重点检查 WAF、安全规则、IP 黑名单、Bot 防护、地区限制和访问频率策略。

尤其是使用 CDN 或 WAF 的网站，有时候一个运营商的大量用户会共享某些 NAT 出口 IP。如果安全规则设置过严，可能把整批正常用户一起识别成异常流量，于是就会出现“某些地区大量用户打不开”的情况。

返回 502、503、504：重点检查CDN回源和源站

如果异常地区大量返回：

502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

问题往往已经不只是用户到 CDN 这一段。

比如一个网站使用多个 CDN 节点：

广州用户
   ↓
广州 CDN 节点
   ↓
回源连接异常
   ↓
504

而北京用户可能被调度到另外一个 CDN 节点：

北京用户
   ↓
北京 CDN 节点
   ↓
正常回源
   ↓
200

于是最终表现就是北京访问完全正常，广州却一直打不开。

这种情况应该继续检查异常 CDN 节点到源站之间的网络、回源 IP、回源 Host、HTTPS 回源、源站防火墙以及服务器是否限制了 CDN 节点 IP。

如果大量地区同时出现 5xx，还要进一步检查 Nginx、反向代理、PHP、Java、Node 服务、数据库连接和服务器负载，而不能一直把问题归因于运营商线路。

HTTP 状态检测最大的价值就在这里：它可以帮助区分“请求根本没有连到网站”和“已经连接网站，但网站主动返回错误”。

六、根据故障现象，快速判断应该查哪里

实际处理这类问题时，我一般不会一项项把所有工具全部跑一遍，而是先看现象，再决定下一步查什么。

把这些结果串起来以后，网站部分地区打不开的排查思路其实并不复杂：先确认哪些地区异常，再比较 DNS，然后检查 Ping 和 TCP 端口，接着观察 HTTP 状态，最后才进入 CDN 回源和源站。

网站出现“部分地区打不开”，真正麻烦的地方从来不是工具不够，而是容易把不同层的问题混在一起。站长自己可以访问，只能证明当前所在地区、当前运营商到网站的链路正常，并不能代表全国用户都正常。

遇到这类故障，先通过 Chahu 这类多节点检测工具把不同地区、电信、联通、移动的访问结果放在一起比较，再根据异常节点继续做 DNS、Ping、TCPing、IPv6 和 HTTP 检测，通常很快就能判断问题究竟更接近解析、运营商线路、CDN 还是源站。与其反复刷新网页或者盲目重启服务器，先把故障范围缩小，往往才是处理区域性访问异常最快的方法。

常见问题

Q1：区域性访问异常会对网站的谷歌 SEO 排名产生什么影响？

A： 如果抓取频次较高的地区（如谷歌蜘蛛节点集中分布的北美或欧洲节点）刚好遇到网络超时或返回 5xx 错误，搜索引擎会认为网站服务不稳定，进而降低抓取预算。若异常持续超过 24-48 小时，相关页面的关键词排名可能下滑甚至暂时被索引移除。不过，如果是偶发的短时间节点波动，对整体 SEO 的影响非常有限。

Q2：如果确定是某个运营商线路丢包严重，站长可以在服务端做什么？

A： 运营商跨网或单干线故障通常难以由单台源站服务器直接解决。最有效的做法是在 CDN 或 DNS 智能解析层配置“线路分组”（按运营商分流），将移动线路的流量调度到移动优化节点、BGP 多线节点或高防边缘节点上，避开拥堵的骨干网互联节点。

Q3：为什么有些地区 Ping 延迟很低，但打开网页时依然频繁超时？

A： Ping 使用 ICMP 协议，仅代表基础网络层的响应速度；而加载网页需要建立 TCP 连接并完成 TLS/SSL 握手（HTTPS）。如果服务器的 TCP 全连接队列溢出、防火墙策略误杀特定 IP 的 443 端口，或者 SSL 证书 OCSP 验证在国内响应超时，就会出现“Ping 正常但 HTTP(S) 请求被拒”的情况。

Q4：出现 IPv6 优先导致部分地区打不开时，应该如何紧急处理？

A： 如果确诊是 IPv6 解析或环境配置问题，最快的紧急恢复手段是在域名 DNS 后台暂时暂停或删除 AAAA 记录，强制所有地区的终端降级使用 IPv4 访问。随后再排查源站 Nginx/Apache 的 IPv6 监听配置（例如是否漏写listen [::]:443 ssl）或安全组规则。

Q5：WAF 规则引发的区域性 403 拦截，通常有哪些隐藏原因？

A： 常见的原因是某些省份的运营商在高峰期会使用大方数的 NAT（网络地址转换）出口。当数千名不同用户共享同一个公网 IP 访问网站时，极其容易触发 WAF 的 Rate Limiting（频率限制）或 Bot 识别规则，导致该地区所有使用该运营商网络的用户被“误杀”拦截。