15827631206
行业动态 更多+
联系我们 / CONTACT
网工必备：端到端连通性排查 Check List（Ping/Traceroute/抓包/日志）
作为网络工程师，最常遇到的场景莫过于：“网慢”、“网断了”、“连不上服务器”。面对这些模糊的抱怨，如果排查思路不清晰，很容易像无头苍蝇一样乱撞。
端到端连通性排查是网工的基本功。为了让大家在故障面前临危不乱，我整理了一份“网工必备排查 Check List”，涵盖 Ping、Traceroute、抓包、日志四大核心环节。建议收藏，关键时刻逐项核对。
✅ Check List 总览
在深入细节前，请先快速过一遍核心步骤：
【基础连通性】：Ping 测试（通不通？丢包吗？延时大吗？）
【路径追踪】：Traceroute 测试（路走对了吗？哪里卡住了？）
【深度分析】：抓包分析（包发出去了吗？包回来没？谁丢弃了？）
【线索溯源】：日志审计（设备报错了吗？策略拦截了吗？）
第一步：Ping —— 基础连通性的试金石
Ping 是最直接的手段，但很多网工只看“通”或“不通”。其实，Ping 的输出信息富含深意。
🔴 排查要点：
连通性测试
Reply from ...：通了。Request timeout：不通（可能是丢包，也可能是被拦截）。Destination Host Unreachable：本地没有路由，根本不知道怎么走（查路由表）。ping <目标IP>结果解读：
MTU/分片问题排查（高级技巧）
很多“能Ping通但应用跑不起来”的问题，都是 MTU 不匹配导致的。
命令：
ping(Windows) 或-l -f ping(Linux)。-s -M do 动作：从大包（如 1472 字节）开始测试，逐步减小，找到临界点。如果加上
-f（禁止分片）后不通，说明路径上有设备 MTU 设置过小。延时与抖动
观察
time=xx ms。如果延时波动巨大（如从 10ms 跳到 500ms），通常意味着链路拥塞或 QoS 策略问题。
📝 Check List：
[ ] 能 Ping 通网关吗？
[ ] 能 Ping 通同网段其他主机吗？
[ ] 能 Ping 通目标 IP 吗？
[ ] 是否存在丢包现象？
[ ] 大包（MTU）测试是否正常？
第二步：Traceroute —— 路径追踪的导航仪
当 Ping 发现路径有问题（如延时大或不可达）时，Traceroute 能帮你定位具体是哪一跳出了问题。
🔴 排查要点：
定位故障点
如果在第 N 跳开始出现
* * *（星号），且后续所有跳数都是星号，故障点极大概率在第 N 跳设备或其下一跳链路上。如果在第 N 跳延时突然暴增，说明该节点拥塞或 CPU 过载。
tracert(Windows) 或traceroute(Linux)。判断逻辑：
路由环路检测
如果发现 IP 地址在两个或多个节点之间反复跳跃（如 A -> B -> A -> B），这就是经典的路由环路，需要检查路由协议配置。
注意 ICMP 限速
很多核心路由器对 Control Plane 的 ICMP 报文限速，导致 Traceroute 显示中间某跳超时，但后续跳数正常。这通常是假象，只要后端能通，中间超时往往可以忽略。
📝 Check List：
[ ] 路径是否完整？
[ ] 是否存在路由环路？
[ ] 哪一跳开始出现故障标志（超时/不可达）？
[ ] 实际路径是否符合预期（有没有绕路）？
第三步：抓包分析 —— 看不见真相的显微镜
当 Ping 和 Traceroute 都看不出问题，或者出现“能 Ping 通但业务不通”的灵异事件时，必须上抓包工具。
🔴 排查要点：
TCP 三次握手分析
原因：防火墙主动拒绝，或服务器进程崩溃。
原因：客户端问题（防火墙拦截了回包？）。
原因：包丢了（查网络），或者服务器没开（查服务状态）。
场景：客户端连不上服务器。
现象 A：发了 SYN，没收到 SYN-ACK。
现象 B：发了 SYN，收到 SYN-ACK，但没发 ACK。
现象 C：收到 RST（重置）包。
定位丢包位置
方法：在客户端和服务器端同时抓包。
对比：客户端发出去 100 个包，服务器只收到 98 个？那问题在中间网络。如果服务器收到了 100 个但只回了 98 个？那是服务器问题。
常用工具
Linux：
tcpdump -i eth0 host（保存文件下来用 Wireshark 分析）。-w capture.pcap Windows：Wireshark 图形化界面。
📝 Check List：
[ ] 包发出去了吗？
[ ] 包收到回复了吗？
[ ] 是否存在重传？
[ ] 是否收到 RST 复位信号？
[ ] 应用层交互是否有报错（如 HTTP 500, DNS RCODE）？
第四步：日志审计 —— 被忽略的证据库
如果你排查了半天网络没问题，别忘了看看设备自己“说”了什么。
🔴 排查要点：
网络设备日志
重点关注：
Interface down/up（端口震荡）、CPU high（资源耗尽）、ACL deny（访问控制拦截）。很多次“网络不通”其实是防火墙策略调整后拦截了流量，日志里会有明确的 Deny 记录。
服务器系统日志
dmesg或/var/log/messages：查看网卡驱动报错、TCP 申请内存失败等底层错误。应用程序日志
有时候网络没通，是因为数据库连接池满了、证书过期了、域名解析错了。这些只能在应用日志里看到。
📝 Check List：
[ ] 防火墙/交换机 Log 有无报错？
[ ] 是否有 ACL 或安全策略拦截记录？
[ ] 服务器系统日志有无异常？
[ ] 应用服务启动状态如何？
总结：排查思维导图
遇到故障，请按此顺序思考：
Ping：先确认物理层和网络层是否存活。
Traceroute：确认路径是否正确，定位故障节点。
抓包：确认数据包是否真的发出/接收，分析协议交互细节。
日志：确认设备或系统是否产生了错误告警或策略拦截。
记住：网络排查不是玄学，而是逻辑推理。 希望这份 Check List 能成为你手边的得力助手，助你快速定位，秒解故障！