文章目录
- 为什么网络故障要按层排查
- 第一步：先确认故障范围
- 第二步：检查 DNS 解析是否正常
- 第三步：用 Ping 判断基础连通性
- 第四步：检查目标端口是否可达
- 第五步：检查 HTTP/HTTPS 应用层
- 第六步：用 curl 拆解请求全过程
- 第七步：路由与中间链路怎么查
- 常见故障现象与判断思路
- 服务器端还要检查什么
- 一套可直接照着执行的排查流程
- FAQ：网络调试常见问题
- 总结
为什么网络故障要按层排查
“网站打不开”只是最终表现，真正的问题可能发生在域名解析、网络连通、端口、防火墙、TLS、反向代理或 Web 应用中的任何一层。没有顺序地反复重启服务、修改 DNS 或更换配置，往往会让问题越来越难定位。
更高效的做法是从最基础的条件开始，一层一层确认：域名是否解析正确 → IP 是否可达 → 端口是否开放 → TLS 是否正常 → HTTP 是否返回预期结果 → 应用本身是否健康。
这种方法的核心不是记住多少命令，而是每执行一步都回答一个明确的问题，并根据结果决定下一步查哪里。
第一步：先确认故障范围
开始调试前，先判断故障是“只有自己访问不了”，还是“所有地区都访问不了”。这一步可以快速区分本地网络问题与服务器端问题。
建议至少确认：本机是否正常联网、手机流量和 Wi‑Fi 是否表现一致、不同设备是否都失败、IPv4 与 IPv6 是否一致、目标网站是否只有某个页面异常。
如果只有一台设备失败，优先检查本地 DNS、代理、VPN、浏览器缓存和系统网络；如果多地同时失败，则更应该检查服务器、DNS、CDN、防火墙和应用服务。
第二步：检查 DNS 解析是否正常
域名访问的第一步通常是 DNS。DNS 错误时，服务器即使完全正常，用户也可能无法访问。
nslookup example.com
dig example.com A
dig example.com AAAA
重点检查返回的 IPv4/IPv6 地址是否与当前服务器或 CDN 配置一致。如果刚修改过 DNS，还要考虑 TTL 和递归 DNS 缓存带来的传播时间。
如果域名解析到了旧服务器、错误 IP 或已经失效的 IPv6 地址，应先修复 DNS，再继续排查后面的网络层。
第三步：用 Ping 判断基础连通性
Ping 常用于快速观察 ICMP 连通性和延迟，例如：
ping example.com
如果能够解析出正确 IP 且 Ping 正常，说明至少部分基础网络路径可用。但 Ping 不通并不能直接证明网站宕机，因为很多服务器或云防火墙会主动禁用 ICMP。
因此，Ping 更适合做辅助判断，不能替代端口和 HTTP 检查。
第四步：检查目标端口是否可达
网站常见端口是 HTTP 的 80 和 HTTPS 的 443。服务器能 Ping 通，不代表这些端口一定可以建立 TCP 连接。
nc -vz example.com 80
nc -vz example.com 443
如果端口连接失败，可以重点检查云安全组、系统防火墙、Nginx/Apache 是否监听对应端口，以及服务是否只监听了 127.0.0.1。
ss -lntp
服务器端执行 ss 后，可以确认服务实际监听在哪个 IP 和端口。如果 443 没有监听，那么继续调整浏览器或 DNS 通常没有意义。
第五步：检查 HTTP/HTTPS 应用层
端口可达后，下一步检查 Web 服务实际返回了什么。
curl -I https://example.com/
重点观察状态码和响应头。200 通常表示请求成功；301/302 表示发生重定向；403 表示服务器理解请求但拒绝访问；404 表示目标资源不存在；502/504 往往意味着反向代理无法正常连接上游服务或上游响应超时。
如果 HTTP 正常而 HTTPS 异常，应进一步检查证书、TLS 配置、SNI 和 443 端口。
第六步：用 curl 拆解请求全过程
curl 不只是查看状态码，它还能帮助判断 DNS、TCP、TLS 和服务器响应分别花了多少时间。
curl -o /dev/null -s -w ‘DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nTTFB: %{time_starttransfer}\nTotal: %{time_total}\n’ https://example.com/
如果 DNS 时间明显异常，应优先检查解析器或 DNS 服务；连接时间过长可能与网络路径、防火墙或服务器负载有关；TLS 时间异常可以检查证书链和 TLS 握手；TTFB 很高则更值得关注后端应用、数据库或上游接口。
把“网站很慢”拆成多个阶段，比只看总耗时更容易找到真正瓶颈。
第七步：路由与中间链路怎么查
当某个地区无法访问、跨运营商延迟异常或连接在途中丢失时，可以使用 traceroute、tracert 或 MTR 观察网络路径。
traceroute example.com
# Windows 可使用：
tracert example.com
需要注意，中间某一跳不响应并不一定代表故障。有些路由设备会限制或忽略探测报文，但仍然正常转发业务流量。真正有价值的是结合后续节点、最终目标和持续测试一起判断。
MTR 可以连续观察延迟和丢包趋势，更适合分析偶发性网络质量问题，但同样不能只凭某个中间节点的“丢包率”直接下结论。
常见故障现象与判断思路
域名无法解析
优先检查 DNS 记录、域名状态、权威 DNS、DNSSEC 配置以及本地递归 DNS。
Ping 不通，但网站可以打开
通常可能是服务器禁用了 ICMP。这种情况下应以 TCP 端口和实际 HTTP/HTTPS 请求结果为主要判断依据。
80 正常，443 失败
重点检查 443 是否监听、云安全组是否放行、TLS 证书与 Nginx/Apache HTTPS 配置是否正确。
返回 502 Bad Gateway
通常应检查反向代理的上游服务是否启动、上游端口是否正确、Unix Socket 是否存在，以及 Nginx 到应用服务之间是否能够正常连接。
只有部分地区打不开
可以从 DNS 线路、CDN 节点、IPv6、运营商路由、防火墙策略和跨网链路等方向继续定位。
浏览器打不开，但 curl 正常
可以进一步检查浏览器代理、缓存、扩展、HSTS、证书信任、HTTP/3 或本机安全软件等因素。
服务器端还要检查什么
如果已经确定问题发生在服务器侧，可以继续检查服务状态、日志、资源占用和防火墙。
systemctl status nginx
journalctl -u nginx –since ’30 minutes ago’
ss -lntp
free -h
df -h
对于 Node.js 或使用 PM2 管理的服务，还可以检查进程是否在线以及最近日志。
pm2 status
pm2 logs –lines 100
排查时尽量先看日志再重启。直接重启可能暂时恢复服务，却同时丢失最有价值的故障现场。
一套可直接照着执行的排查流程
遇到网站无法访问时，可以按照下面的顺序执行：
- 确认故障范围：单设备、单网络、单地区还是全局异常。
- 查询 DNS：确认 A、AAAA 等记录是否指向正确地址。
- 检查基础连通：使用 Ping 作为辅助判断。
- 检查 TCP 端口：确认 80、443 或业务端口是否可连接。
- 检查 HTTP/HTTPS：查看状态码、重定向和响应头。
- 检查 TLS：如果只有 HTTPS 异常，重点排查证书与握手。
- 检查路由：存在地区性问题时使用 traceroute/MTR 辅助分析。
- 登录服务器：检查监听端口、服务状态、日志、CPU、内存和磁盘。
- 修复后重新从外部网络验证，而不是只在服务器本机测试。
这套流程最大的价值是避免跳跃式排查。只要能够明确“问题从哪一层开始出现”，后面的范围通常会迅速缩小。
FAQ：网络调试常见问题
1. Ping 不通是不是服务器一定宕机？
不是。ICMP 可能被服务器或防火墙禁止，应继续检查目标 TCP 端口和 HTTP/HTTPS。
2. DNS 修改后为什么自己还是访问旧 IP？
可能与 TTL、本地缓存、运营商递归 DNS 缓存或浏览器缓存有关。可以分别从不同网络和 DNS 解析器验证。
3. 端口开放为什么网站仍然打不开？
端口开放只说明 TCP 层能够建立连接，Web 服务仍可能返回错误状态码、TLS 失败、反向代理异常或应用程序报错。
4. 502 和 504 有什么区别？
两者通常都与网关或反向代理有关。502 常见于上游返回无效响应或连接失败；504 更常见于等待上游响应超时。具体原因仍应结合代理和应用日志确认。
5. 网络排查最重要的原则是什么？
先确定故障范围，再按 DNS、网络、端口、TLS、HTTP、应用的顺序逐层验证。每一步都用结果缩小范围，而不是同时修改多个配置。
总结
网络故障排查并不是不断尝试命令，而是建立清晰的诊断路径。DNS 决定域名指向哪里，Ping 可以辅助观察基础连通，端口检测确认 TCP 服务是否可达，HTTP/HTTPS 检查应用层结果，curl 可以进一步拆解请求耗时，而 traceroute 与 MTR 则适合分析路径和地区性网络问题。
当这些结果与服务器日志、监听端口和资源状态结合起来时，大多数“网站打不开”“访问很慢”“部分地区异常”等问题都能被逐步缩小到具体环节。
建立固定的排查顺序，比记住大量零散命令更重要。
2 条评论