一、网络排障的思路：先分层，再定位
网络问题是最让人头疼的运维故障之一：网站打不开、SSH连不上、接口超时，表象千奇百怪。但万变不离其宗，TCP/IP模型就是最好的排障地图。按 链路层→网络层→传输层→应用层 逐层排查，能快速把问题圈定在一个小范围内，避免瞎猜瞎试。
二、第一层：连通性基础检查
# 1. 本机网卡与IP是否正常ip addr showip link show# 2. 网关是否可达ping -c 4 网关IP# 3. 路由表是否正确ip route show# 默认路由缺失会导致所有外网不通
这层检查解决的是"网络根本没通"的问题。如果ping网关都丢包，问题出在物理链路或本机网卡配置；如果网关通而外网不通，多半是路由或DNS的问题。
三、第二层：DNS解析排查
# 解析是否正常nslookup www.example.comdig www.example.com# 查看系统实际使用的DNScat /etc/resolv.conf# 测试解析耗时（延迟过高会拖慢所有访问）dig www.example.com | grep "Query time"
很多"网络慢"其实是DNS慢。域名解析失败或解析到错误IP，表现就是网页打不开但IP直连正常。排查时先确认：ping 域名不通但 ping IP 通，那基本就是DNS问题。
四、第三层：路由与丢包追踪
# 追踪数据包路径，看卡在哪一跳traceroute -n -T -p 443 www.example.com# -T 用TCP探测更接近真实业务，-n 不做反向解析更快# 检查丢包率ping -c 100 -i 0.2 目标IP | tail -1# 丢包率超过1%就需要关注，超过5%基本可判定链路质量差# 查看网卡错误计数（软硬件层面问题）ip -s link show eth0
traceroute 输出里 * * * 的节点可能是防火墙屏蔽ICMP，不一定是故障；关键看最终到达目标节点的延迟和丢包。中间一跳延迟飙升，往往是运营商链路拥塞或绕路。
五、第四层：端口与服务连通性
# 测试TCP端口是否开放nc -zv 目标IP 80nc -zv 目标IP 443# -z 只扫描不发送数据，-v 显示详细信息# 测试UDP端口（如DNS）nc -zuv 目标IP 53# 查看本机监听端口ss -tlnp# LISTEN状态的端口才是对外开放的
端口不通时，要么服务没起来，要么被防火墙拦了。本机用 ss -tlnp 看监听，外网用 nc 测连通，配合防火墙规则检查（iptables/firewalld）基本能定位。
六、应用层：延迟与HTTP状态检查
# 查看HTTP响应头和状态码curl -I -m 5 http://example.com# 详细计时：DNS解析、TCP连接、TLS握手、首字节各耗时多少curl -w "DNS: %{time_namelookup}s\nTCP连接: %{time_connect}s\nTLS握手: %{time_appconnect}s\n首字节: %{time_starttransfer}s\n总耗时: %{time_total}s\n" -o /dev/null -s https://example.com# 追踪TCP连接内核队列（连接数爆满时的关键指标）ss -scurl计时能精确到每个阶段：如果DNS耗时高查解析，TCP连接耗时高查路由/防火墙，TLS握手慢查证书链和加密套件，首字节慢则要怀疑后端应用或数据库。
七、实战案例：网站间歇性卡顿的定位过程
一次典型排障：用户反馈网站时好时坏。按上面思路分层排查：
# 1. ping网关和本机IP，正常，链路层没问题# 2. ping 域名 vs ping IP，发现ping IP稳定，域名偶尔超时 → DNS有嫌疑# 3. dig 查看，发现解析到了两个IP，其中一个是已下线的机房IP# 4. 运营商DNS缓存了旧记录，TTL到期后逐步恢复# 结论：DNS记录变更后未等TTL过期，且未提前降低TTL，导致部分用户访问旧IP
整个排查不到10分钟。这就是分层排障的价值——每层有明确工具和判断标准，顺着链路走一遍，问题自然浮出水面。
八、总结
网络排障没有玄学，只有方法论。记住四层口诀：链路不通查网卡，路由不通查网关，端口不通查服务，延迟不稳查DNS和链路质量。把 ping、traceroute、nc、ss、curl 这几个工具练熟，再复杂的网络故障也能有条不紊地拆解。建议把这套排查流程写成自己的Checklist，遇到问题照着走，效率翻倍。
评论