网站打不开怎么排查？从 DNS、端口、证书到服务器的完整故障定位流程

网站突然打不开时，最常见的错误做法是立即重启服务器、修改 DNS、关闭防火墙，或者反复刷新浏览器。

这些操作可能暂时改变现象，却会破坏原有证据，甚至制造新的故障。

网站访问需要依次经过多个环节：

域名解析
   ↓
网络路由
   ↓
TCP 端口
   ↓
TLS 证书
   ↓
HTTP / CDN / WAF
   ↓
Web 服务与应用

任何一层失败，用户看到的都可能只是“网站打不开”。正确方法是先判断影响范围，再按照协议层逐步缩小问题。

正在处理网站故障？

先打开 DNSPup 网站测速，立即检查不同地区的状态码、响应 IP 和访问耗时，确认是全局故障、地区性故障还是本地网络问题。

一、第一步不是修复，而是确认影响范围

先用手机流量、家庭宽带和远端拨测节点进行交叉验证。

应该记录哪些信息？

故障发生时间：
访问的完整 URL：
用户地区与运营商：
浏览器错误信息：
HTTP 状态码：
实际解析 IP：
IPv4 / IPv6：
宽带与手机流量是否一致：
近期是否修改 DNS、CDN、证书或服务器：

故障时间尤其重要。没有准确时间，就很难在服务器、CDN 和防火墙日志中找到对应记录。

二、先看错误类型，不要把所有失败都叫“打不开”

不同错误对应完全不同的排查方向。

如果已经收到 HTTP 状态码，通常说明 DNS、TCP 和 TLS 已经至少完成了大部分流程。此时不应继续只做 Ping，而要检查 HTTP、网关和应用。

三、检查 DNS：用户到底被带到了哪台服务器？

打开 DNSPup DNS 查询，核对不同节点解析到的地址，重点查看：

1. A 记录是否指向当前 IPv4 地址；
2. AAAA 记录对应的 IPv6 服务是否可用；
3. CNAME 是否指向正确的 CDN 或业务域名；
4. 不同地区是否仍然出现旧 IP；
5. TTL 是否符合最近的变更计划；
6. 权威 DNS 是否能够稳定响应。

常见 DNS 故障

• 服务器已经迁移，解析仍然指向旧 IP；
• CDN 接入后 CNAME 填写错误；
• 修改记录后，部分递归 DNS 仍有旧缓存；
• 根域名和 www 使用了不同配置；
• 配置了 AAAA，但 IPv6 服务器没有监听业务端口；
• 删除源站后，仍有地区被调度到旧节点。

不要用本地一次查询代表所有用户

本地 nslookup 或 dig 只能反映当前递归 DNS 的结果。地区性故障需要比较多个地区和运营商，判断异常是否集中在特定解析地址。

四、检查网络和端口：Ping 通不代表网站正常

网站通常使用 TCP 80 或 443 端口，而 Ping 使用 ICMP。两者不是同一种协议。

Ping 失败 + Tcping 成功
可能只是服务器禁止 ICMP，不影响网站

Ping 成功 + Tcping 失败
可能是端口、防火墙、安全组或服务监听异常

使用 DNSPup Tcping，立即检查网站 80/443 端口，对比域名和实际 IP 的结果。

服务器侧检查

Linux 可以检查监听端口：

sudo ss -lntp | grep -E ':80|:443'

还需要依次核对：

• 云平台安全组；
• 云防火墙或负载均衡；
• Linux 防火墙；
• Docker 或 Kubernetes 端口映射；
• Nginx、Apache、Caddy 或其他服务监听；
• CDN 回源端口和源站白名单。

不要为了测试直接关闭全部防火墙。应只检查和修改与业务端口相关的规则。

五、端口正常后，检查 TLS 和证书

Tcping 成功只表示 TCP 连接可以建立，不代表 HTTPS 一定正常。

可以使用：

openssl s_client -connect example.com:443 -servername example.com

将 example.com 替换成自己的域名，重点检查：

• 证书是否过期；
• 证书是否包含当前域名；
• 完整证书链是否正确返回；
• SNI 是否匹配到正确站点；
• TLS 协议和密码套件是否兼容；
• CDN 节点证书与源站证书是否分别正常。

常见证书问题

• 证书只包含根域名，不包含 www；
• 证书已经续期，但 Web 服务没有重新加载；
• 多站点服务器返回了默认站点证书；
• CDN 使用旧证书，源站证书却已经更新；
• HTTPS 回源时，源站证书域名和回源 Host 不一致。

六、检查 HTTP、CDN、WAF 和回源链路

如果 TCP 和 TLS 正常，就要关注 HTTP 状态码与分阶段耗时。

用户
  ↓
CDN / WAF
  ↓
负载均衡或反向代理
  ↓
Web 服务
  ↓
应用、缓存和数据库

常见状态码如何判断？

经过 CDN 时分别检查两段链路

用户 → CDN 节点
CDN 节点 → 源站

CDN 页面显示正常不代表回源正常，源站可以直接访问也不代表 CDN 的回源协议、Host、SNI 和端口设置正确。

重点查看：

• CDN 是否回源到正确 IP；
• 回源使用 HTTP 还是 HTTPS；
• 回源端口是否正确；
• 源站是否允许 CDN 地址访问；
• 回源 Host 和 SNI 是否匹配；
• CDN 健康检查是否失败；
• WAF 是否误拦截正常请求。

七、只有部分地区打不开：检查 DNS 调度和路由

如果故障集中在某个省份或运营商，应比较失败节点和正常节点的：

• 解析 IP；
• CDN 节点；
• Tcping 结果；
• HTTP 状态码；
• 路由路径；
• IPv4 与 IPv6。

打开 DNSPup MTR，查看延迟或丢包从哪一跳开始持续出现。

MTR 不能只看某一跳

部分路由设备会降低 ICMP 响应优先级。中间某一跳显示丢包，但后续节点和最终目标正常，通常不能直接认定该设备导致业务故障。

更值得关注的是：异常从某一跳开始，并持续影响后续所有节点和最终目标，而且能够在重复检测中稳定复现。

八、远端都正常，只有自己打不开怎么办？

如果多个远端节点都能正常访问，问题很可能在本地：

• 本地 DNS 缓存没有更新；
• 路由器下发了异常 DNS；
• 系统代理没有接管全部流量；
• IPv4 与 IPv6 走了不同出口；
• 浏览器扩展、安全软件或 hosts 文件影响访问；
• 当前公网 IP 被网站或 WAF 限制；
• DNS、HTTP 和 WebRTC 出口不一致。

打开 DNSPup 网络出口检测，核对当前 IPv4、IPv6、DNS 和代理出口，再执行交叉验证：

1. 使用手机流量访问；
2. 更换浏览器或无痕窗口；
3. 暂停代理和相关扩展；
4. 分别测试 IPv4 和 IPv6；
5. 检查 hosts 文件和本地 DNS 缓存；
6. 比较宽带与手机流量的解析 IP。

如果换成手机流量立即恢复，优先检查本地网络和宽带出口；如果多个独立网络都失败，再回到网站端继续排查。

九、网站打不开快速决策表

十、10 分钟标准排查清单

1. 记录故障时间、地区、运营商和错误信息
2. 用多地区 HTTP 检测确认影响范围
3. 检查 A、AAAA、CNAME 和响应 IP
4. 使用 Tcping 验证 80/443 端口
5. 检查服务器监听、安全组和防火墙
6. 端口正常后检查 TLS 和证书
7. 分析 HTTP 状态码和首包耗时
8. 分别验证 CDN 节点与回源链路
9. 地区性问题运行 MTR
10. 远端正常时检查本地网络出口

排障时坚持两个原则：

先保存证据，再修改配置。一次只改变一个因素，修改后立即重新验证。

同时修改 DNS、CDN、防火墙、证书和服务器，会让故障原因变得更难确认。

结语

网站打不开并不是一个具体故障，而是多个协议层共同表现出来的结果。最有效的排查顺序是：

确认影响范围
   ↓
检查 DNS 和响应 IP
   ↓
验证 TCP 端口
   ↓
检查 TLS 与 HTTP
   ↓
分析 CDN、源站和路由
   ↓
远端正常时核对本地出口

现在开始检测：

打开 DNSPup 网站测速，从多个地区检查你的网站

建议保存检测时间、响应 IP、状态码和失败地区，再进行线上配置变更。