网站打不开但别人能访问？5 分钟定位 DNS、端口、路由和本地出口问题

网站故障最让人头疼的情况，往往不是“所有人都打不开”，而是下面这些看似矛盾的现象：

• 自己打不开，朋友却能正常访问；
• 部分省份访问正常，部分地区持续超时；
• 手机流量可以打开，家里宽带却很慢；
• 域名能够 Ping 通，但浏览器一直加载失败；
• 更换 DNS 后短暂恢复，过一会儿又出现异常；
• IPv4 正常，IPv6 用户却无法访问。

这类问题通常不是简单刷新页面就能解决的。它可能发生在 DNS 解析、TCP 端口、TLS、HTTP、CDN 节点、跨网路由或用户本地出口 中的任何一层。

正在排查自己的网站？

直接点击打开 DNSPup 网站测速，立即检查不同地区的状态码和访问耗时，输入域名即可开始检测，无需安装客户端。

本文不堆砌工具名，而是提供一套可以直接执行的排查顺序。按照顺序完成检测，通常可以快速判断问题究竟在网站端、运营商链路，还是自己的本地网络。

一、先判断：这是网站故障，还是局部网络故障？

遇到网站打不开时，不要立即修改服务器、DNS 或 CDN 配置。第一步应该从多个地区观察同一个网站。

为什么先做网站测速？

因为浏览器里的“打不开”只能描述结果，无法告诉你故障发生在哪个阶段。一次完整的 HTTPS 请求至少包括：

DNS 解析
↓
TCP 建立连接
↓
TLS 握手
↓
服务器返回首字节（TTFB）
↓
页面内容下载

只要其中一个阶段异常，用户感受到的都可能是“网站很慢”或“完全打不开”。

使用 DNSPup 网站测速，查看 DNS、连接、TLS、首包与下载耗时 后，先关注以下信息：

如果所有节点都失败，优先检查网站端；如果只有少数节点异常，继续检查 DNS、CDN 和跨网链路。

二、第二步：检查 DNS 是否把用户带到了正确地址

DNS 的作用是把域名转换成 IP 地址。网站服务器完全正常，并不代表所有用户都一定能解析到正确地址。

常见 DNS 问题包括：

• 修改解析后，部分递归 DNS 仍在使用旧缓存；
• CDN 的 CNAME 配置错误或链路过长；
• 个别地区解析到了已经下线的节点；
• 同一域名的 A、AAAA 记录状态不一致；
• 权威 DNS 响应异常；
• 本地路由器或运营商 DNS 返回了过期结果。

打开 DNSPup DNS 查询，立即核对域名在不同节点的解析结果，重点比较：

一个容易忽略的 IPv6 问题

如果域名配置了 AAAA 记录，支持 IPv6 的系统可能会优先尝试 IPv6。此时即使 IPv4 完全正常，只要 IPv6 路由、防火墙或 Web 服务没有配置完整，部分用户仍可能打不开网站。

因此，不要只确认“有 AAAA 记录”，还要确认该 IPv6 地址确实可以提供业务服务。

三、第三步：域名能解析，不代表业务端口能连接

很多排障过程停留在 Ping：

Ping 成功 → 误认为网站一定正常
Ping 失败 → 误认为服务器已经宕机

这两种判断都不准确。

Ping 使用 ICMP，而网站访问通常使用 TCP 80 或 443 端口。服务器可以禁止 ICMP，同时继续正常提供 HTTPS；也可能能够响应 Ping，但 443 端口被防火墙拦截。

打开 DNSPup Tcping，立即检查网站 80/443 端口能否建立连接，根据结果继续判断：

如果只有某个地区的 443 端口连接失败，通常应优先检查该地区到目标 IP 的路由、CDN 节点状态以及防火墙策略，而不是立即重装 Web 服务。

四、第四步：部分地区慢，重点看路由和丢包位置

当不同地区已经解析到正确 IP，端口也能够连接，但访问速度差异仍然很大，就需要继续观察网络路径。

典型表现包括：

• 电信访问正常，移动或联通延迟很高；
• 同省访问正常，跨省访问明显变慢；
• 国内访问正常，境外连接频繁超时；
• 延迟突然升高，并伴随间歇性丢包；
• CDN 节点距离用户很近，但实际路由发生绕行。

打开 DNSPup MTR，立即查看延迟和丢包从哪一跳开始出现。

阅读 MTR 时不要只看某一跳

部分路由设备会降低 ICMP 响应优先级，因此中间某一跳显示丢包，并不一定代表真实业务流量也在该位置丢失。

正确判断方法是：

如果中间某一跳丢包很高，但后续节点和最终目标正常，通常不能直接认定该路由设备故障。

五、第五步：别人都正常，只有自己打不开怎么办？

如果远端节点检测均正常，但自己的电脑或手机仍然打不开，问题大概率已经从网站端转移到本地网络。

常见原因包括：

• 本地 DNS 缓存没有更新；
• 路由器下发了异常 DNS；
• 系统代理只接管了部分流量；
• IPv4 和 IPv6 走了不同出口；
• 浏览器扩展、代理软件或安全软件拦截请求；
• DNS、HTTP 和 WebRTC 暴露的出口不一致；
• 当前公网 IP 被目标网站或安全策略限制。

打开 DNSPup 网络出口检测，立即核对当前浏览器和网络出口，然后依次进行以下对比：

当前 IPv4 / IPv6
↓
HTTP 请求出口
↓
DNS 解析出口
↓
WebRTC 候选地址
↓
代理和系统网络设置

最简单的交叉验证方法

在不修改网站配置的前提下，分别测试：

如果手机流量正常、宽带异常，优先检查本地 DNS、路由器和宽带出口；如果多个独立网络都异常，再回到网站端检查。

六、一张表快速确定下一步

排查时要坚持一个原则：

先收集证据，再修改配置；一次只验证一个层级。

同时修改 DNS、CDN、防火墙和服务器配置，会让故障原因变得更难确认，还可能制造新的问题。

七、站长可以保存的 5 分钟检查清单

下次遇到网站打不开或访问慢，可以直接按照下面的顺序执行：

• 使用多地区网站测速，确认异常范围；
• 对比 HTTP 状态码、响应 IP 和各阶段耗时；
• 检查 A、AAAA、CNAME 与 TTL；
• 检测 80、443 或实际业务端口；
• 对异常地区执行 MTR；
• 远端正常时检查自己的 DNS、代理和出口；
• 保存发生时间、地区、运营商、目标 IP 和检测结果；
• 根据证据修改单项配置，然后重新验证。

建议故障记录至少包含：

故障时间：
用户地区与运营商：
访问网址：
解析到的 IP：
HTTP 状态码：
Tcping 结果：
MTR 结果：
IPv4 / IPv6：
本地网络与手机流量对比：

这份信息无论交给服务器运维、DNS 服务商、CDN 厂商还是运营商，都比一句“网站打不开”更容易定位问题。

八、为什么适合用 DNSPup 完成这套排查？

DNSPup 的价值不在于提供某一个单独的测速页面，而在于把排查网站故障需要的多个步骤放在同一个工具体系中：

DNS → Ping → Tcping → HTTP → MTR → 本地出口

这样可以从“哪些地区访问异常”继续追查到“解析到了什么地址”“业务端口是否可达”“延迟从哪一跳开始升高”，最后再验证问题是否只存在于自己的网络。

需要注意：在线检测适合即时诊断、交叉验证和故障取证，但不能替代服务器日志、应用监控、调用链和持续告警。最可靠的结论，始终来自外部拨测与内部监控的相互印证。

结语：不要再用刷新页面代替故障定位

网站出现地区性打不开、访问慢或偶发超时时，正确的处理方式不是反复刷新，也不是凭感觉修改配置，而是按照协议层逐步缩小范围：

先确认影响范围
↓
再检查 DNS
↓
验证业务端口
↓
分析 HTTP 与路由
↓
最后核对本地出口

现在就检查你的网站：

打开 DNSPup 网站测速，输入域名开始多地区检测

建议先保存检测结果，再修改 DNS、CDN、服务器或防火墙配置。