开头先讲一个我印象特别深的场景有天半夜值勤业务方说上不了网我远程登进去第一件事就是ping网关通了再ping一个公网IP也通但浏览器打不开任何页面。当时一起值班的新人很困惑——不是说ping通了网络就没问题吗结果问题出在DNS解析那一层跟链路一点关系都没有。反过来另一个项目组网页打开一切正常但持续ping的时候丢包率能到20%一查是出口设备的单臂路由配置有误。这种矛盾见多了你就会明白ping和tracert能告诉你的远远不止通不通三个字。这篇内容我想把这两个命令从底层报文交互到实战排查的完整思路捋一遍适合刚入行的网络运维、做系统和应用开发的同事也适合被网络总是不通折磨过的朋友。看完之后你应该能自己回答ping通了为什么还不能上网tracert在哪一跳断的问题就一定在哪一跳吗这类问题。1. 先搞懂 ping 在底层到底做了什么1.1 ICMP协议那个常被当成底层小帮手的协议很多人以为ping是直接发了几个数据包出去试探对方但严格来说ping依赖的是ICMPInternet Control Message Protocol互联网控制报文协议。ICMP和TCP、UDP不一样它没有端口号的概念也几乎不承载业务数据它的本职工作是传递网络控制信息和差错报告——比如目标不可达、超时、源抑制、重定向这些。ICMP报文本身封装在IP报文里IP头部的协议字段为1通常格式是IP头 ICMP头 数据。ICMP头里有三个关键字段类型Type、代码Code、校验和。ping对应的就是类型8回显请求Echo Request和类型0回显应答Echo Reply。Windows下的ping默认还能带一个Identifier和Sequence Number用来匹配请求和应答。这里需要纠正一个常见误区ICMP不是一个可以被绕过的辅助工具很多防火墙策略专门处理它因为它既能帮你探测网络也能被别人用来探测你。所以你在tracert或ping时看不到某些设备响应原因往往不是网络断了而是对方压根就不回ICMP。1.2 TTL的数字游戏与系统识别陷阱IP头里有一个字段叫TTLTime To Live生存时间它的真实含义不是存活了多少秒而是还能经过多少跳hop。每经过一个路由器TTL减1如果减到0路由器就会把包丢弃并回送一个ICMP超时消息给源地址。ping输出里有一项TTLxx就是响应包到达本机时剩下的数值。正因为每经过一跳TTL都会递减很多文章教你用TTL猜对方操作系统Windows默认TTL通常是128Linux默认通常是64网络设备常见255。但如果你真的在生产环境里靠这个猜系统早晚要翻车。原因有三点有些操作系统或设备允许自定义默认TTL管理员可能把Linux默认改成64或128之外的值中间设备可能修改TTL或者运营商在NAT网关处做特殊处理防火墙、负载均衡设备可能直接改写IP头字段。我之前见过一个例子目标主机实际是Linux但ping返回的TTL一直是120怎么都到不了64。查到最后发现客户网络里一台老式安全设备对所有出向流量统一重写了TTL从那以后我再也不敢拿TTL当识别系统的铁证。正确的用法是TTL只能作为参考而且务必结合多包观察别看到一个数值就下结论。1.3 一个ping包往返的完整经历如果你在电脑上执行 ping 203.0.113.1底层大致会经历这些过程应用程序调用系统Socket接口构造一个ICMP回显请求报文IP头目的IP设为203.0.113.1TTL设默认值。操作系统查询路由表判断去往203.0.113.1的下一跳是哪。如果是同一网段就直接查ARP拿到目标MAC如果是跨网段就把包交给默认网关。数据包到达网关路由器后路由器查它的路由表决定从哪个接口转发出去TTL减1。中间每一跳都执行同样的查表减TTL转发动作直到到达目标主机。目标主机收到回显请求后构造回显应答TTL同样被初始化为自身默认值再原路或按自己的路由表返回。源主机收到应答后记录往返时间然后输出 rtt 统计。这个流程里最有价值的一点是ping的往返时间并不是单纯的链路速度它包含了源端到目的端的单程延迟乘以2还包含沿途所有设备的处理延迟、排队延迟和可能的重传时间。所以当rtt很不稳定时问题可能出在链路拥塞、设备CPU忙、无线空口抖动等各种位置上不能一口咬定是光纤问题。2. 从 ping 结果定位故障的第一套打法2.1 三个目标分段测试法网关、外网IP、域名实操中我一般不会只ping一个目标而是固定做三连测先ping本机网关再ping一个外网IP最后ping一个域名。这三步分别对应链路层、路由/NAT层、DNS解析层。下面这个表是我自己排查时常用的判断矩阵测试目标命令示例正常时看到什么异常时可能的原因本机回环ping 127.0.0.1几乎不丢包0.x ms本机TCP/IP协议栈异常极少见网关ping 192.168.1.1低延迟、稳定网线、Wi-Fi、交换机端口、VLAN配置问题外网IPping 203.0.113.1看跨网段路由是否可达出口路由、NAT、运营商链路问题域名ping www.example.com先解析后连通DNS服务器问题、域名解析策略问题如果你ping网关很稳但ping外网IP丢包或者不通那问题基本不在局域网内而在出口设备或者运营商链路。反过来如果ping外网IP一切正常但ping域名超时重点就要转到DNS上——域名解析失败时ping会直接提示找不到主机而很多时候浏览器会一直转圈和断网表现一模一样。2.2 看懂丢包与延迟数据数字背后的瓶颈ping命令输出里的数据不是摆设。以Linux为例ping -c 20 203.0.113.1会给出min/avg/max/mdev四项。min是最好一次avg是平均值max是最差一次mdev代表均方差也就是抖动。如果你的mdev长期超过avg的一半说明这条路径的延迟非常不均匀可能存在拥塞或无线空口竞争。丢包率更要看趋势。偶尔丢一个包可以理解但如果累计丢包率超过5%对语音、视频这类实时业务已经很难受了。持续丢包和突发丢包的原因通常不一样持续丢包多为链路误码、光模块光功率异常、接口CRC错误累积、带宽跑满突发丢包多为突发流量超过接口队列、路由器CPU短暂繁忙、无线信号波动。还有一类特殊的情况ping丢包50%左右但业务访问相对正常。这有可能是多链路负载分担一个会话走好路径另一个会话走差路径也可能是两台设备做了主备但心跳失效导致一半流量被丢弃。这时候要看ping里丢包的序列号是否有规律是否集中在某个时间段再决定是查光路还是查设备。2.3 一个局域网内ping不通的排查示例拿一个实际遇到的小案例说明。某办公室新搬来的工位电脑能联网但网络一会通一会断。我上去ping网关192.168.50.1结果直接请求超时再ping旁边一台电脑的IP也是超时但是其他工位一切正常。这个现象基本可以把问题锁定在这台电脑到接入交换机之间。我先检查了网口指示灯发现是亮着的于是又看了一眼交换机端口统计发现有大量的CRC错误和runts。这种错误通常暗示物理层信号质量差比如网线老化、水晶头虚接、线序不对。我换了一根机制六类跳线问题立刻消失。这不算什么高深操作但复盘起来最关键的一步是我没有一上来就认为是交换机坏了也没有去重装系统而是通过邻居电脑通、这台不通这个事实迅速缩小了排查范围。ping的验证价值就在这里——它不能告诉你水晶头哪一根线断了但它能帮你确定该往哪个方向找。3. tracert 的工艺TTL递增探测与ICMP超时3.1 逐跳探测的具体过程tracert的底层思路非常巧妙它故意发送TTL很小的包让它在离你最近的路由器上被丢弃然后利用路由器丢弃时返回的ICMP超时消息反推每一跳是谁。以Windows为例流程是这样的发出TTL1的ICMP回显请求第一跳路由器收到后TTL减为0丢弃并回复ICMP Time Exceeded源地址就是这台路由器的接口地址接着发出TTL2的包第二跳路由回复不断递增TTL直到目标主机回复回显应答或达到最大跳数上限默认30。Linux和macOS下的traceroute默认使用UDP报文探测目标端口从33434开始递增原理一样区别是UDP包到达目标主机后由于目标端口上通常没有服务监听会返回ICMP端口不可达类型3/代码3于是traceroute把这种应答视为已到达终点。这个细节你在做跨平台对比时一定要知道Windows tracert和Linux traceroute的结果可能有差异不一定是谁的路由变了也可能只是探测报文类型不同中间设备对ICMP和UDP的过滤策略不一致。3.2 三列时间戳的真实含义tracert默认对每一跳发3个探测包显示的三列就是这3个包的往返时间。这三列能提供不少信息如果三列数值都很小且接近说明该跳路由稳定如果三列差异很大说明这一跳的路径或设备处理存在波动如果某一列是星号则说明该探测包没有收到回应。但我要提醒一句第三列和前两列之间的对比别过度解读。tracert每发一个探测包都是独立处理前一个包没丢不代表后一个包正常三列数字更像抽样快照而不是统计意义上的平均延迟。判断路径质量还是应该用连续ping或MTR做更长时间的数据采集。3.3 为什么经常看到跳点不响应星号不等于断路新手看到tracert结果里有一两跳显示* * *通常第一反应是链路断了。实际上中间跳点不响应ICMP非常常见原因包括路由器配置了不再回应TTL超时报文这很普遍尤其运营商骨干设备设备用硬件转发不产生ICMP差错等于它根本懒得告诉你它转发过防火墙策略把入站的ICMP超时报文丢了探测包发出去后返回路径和去程路径不同回程路由上某个设备丢弃了返回的报文。我曾经tracert一个目标地址第5跳开始连续5跳都是星号但目标主机却能正常ping通、业务也正常。后来验证发现那个区域用的是MPLS和运营商设备联动中间的PE设备不回应TTL超时包照常转发只是不产生报告。所以结论是不能因为出现了星号就判定断连关键要看最终目标是否可达、整体丢包率是多少。4. 读懂 tracert 里的隐藏信息黑洞、环路和不对称路由4.1 路径黑洞的诊断思路黑洞这个词指的是数据包有去无回ping和tracert都得不到任何反馈。排查黑洞我一般按以下顺序验证在源端ping目标IP如果全超时先换一个目标IP测试排除目标端本身的问题本地tracert目标确认黑洞点大致出现在哪一跳在黑洞可能的位置附近找一台已知能访问目标且网络路径相似的主机再ping一次如果它也通不了进一步缩小到该路径上某一段路由丢失如果条件允许让目标端反向ping源端看是否存在单向路由问题。很多黑洞问题的根源是某个网段没有路由条目比如交换机里少了核心VLAN的路由或者静态路由下一跳写错了。黑洞点的典型tracert表现是前面若干跳都正常从某一跳开始全部超时且之后一直超时到终点。对比两个源头做tracert可以帮助判断黑洞是位于某个路由器的出接口还是位于更远端。4.2 环路识别TTL一直递增的案发现场环路是个非常有意思的问题。数据包在路由器之间转来转去始终到不了目标TTL一直减到0才算完。用tracert看会有几个特征跳数一直涨到最大上限比如30后停止但目标始终不可达跳点IP在几个地址之间不断循环出现比如A-B-A-B延迟通常不是固定的尤其是上千毫秒的大延迟经常出现因为每个环路转发都会增加处理时延。有一次排查一个跨机房的业务不通tracert结果就出现了典型的10.10.3.1和10.10.4.1交替重复。查了两台路由器的路由表发现彼此都把对方当作去往目标网段的下一跳形成了一个你推我、我推你的环路。解决办法也很直接把错误的静态路由删掉换成指向正确核心路由的条目。判断环路的技巧其实不难只要看到跳点IP出现重复就要优先怀疑路由表配错。4.3 不对称路由tracert结果并不可全信很多人没意识到tracert显示的路径其实就是探测报文从源到目标的去程路径加上回程路径的综合结果。如果你收到的TTL超时消息是从回程设备发回来的那么你看到的路径可能混合了来回两个方向并不完全等于业务流量实际的去程方向。这种情况一旦出现tracert的每一跳就未必是从近到远线性排列了。例如你的业务出口走运营商A的网络但从运营商B的链路回来的ICMP差错报文中间跳点顺序可能会奇怪地跳跃。这种不对称路由在双线出口、多运营商互联的场景下非常常见。碰到tracert结果看起来不合常理比如第5跳跳到第8跳的IP后又回到第6跳的网络不要急着判断设备乱转发先想想是不是存在回程分流。验证方法是在多个源头同时tracert同一个目标看路径是否一致有条件的话在目标侧抓包检查流量的来源接口能更快确认。5. 综合实战一套完整的链路与路由排查动作清单5.1 我常用的分段检查顺序每次排查网络故障我基本会按下面这套动作走这套顺序能覆盖绝大多数场景ping 127.0.0.1确认本机协议栈正常ping 网关IP确认二层链路和网关可达性ping 一个外网IP比如203.0.113.1这样的文档地址确认三层路由和NAT正常ping 一个域名确认DNS解析链路正常tracert 外网IP确认路径逐跳可达性观察黑洞、环路的蛛丝马迹如果丢包或延迟可疑用持续ping或MTR连续观察几分钟抓趋势。每一步都有预期结果只要结果不符合预期就把排查范围收敛到对应层级。这套逻辑的道理在于step 2负责局域网step 3负责出口和运营商step 4负责DNSstep 5负责路径细节分工明确不会东一下西一下瞎查。5.2 参数速查与跨平台差异为了防止切换系统时忘参数我把最常用的命令参数整理成了一张速查表作用WindowsLinux / macOS持续pingping -tping默认持续或写-c指定次数ping -n 20ping -c 20指定包大小ping -l 1400ping -s 1400指定间隔ping -w 1000毫秒ping -i 0.2秒最多跳数tracert -h 30traceroute -m 30每跳探测次数tracert默认3次traceroute -q 3超时时间tracert -w 1000traceroute -w 3补充一点ping的包大小会影响结果判断。小包都通、大包不通大概率是MTU问题大包延迟明显升高可能涉及分片重组和队列处理。做MTU测试时可以从1400字节开始逐步增加找到临界值。5.3 常见误诊场景与避坑经验最后聊几个我踩过或帮别人擦过屁股的典型场景。第一个是ping通但网页打不开。这种情况很大概率是DNS解析失败其次是HTTP层问题或者MTU导致TCP握手包进不来。不要因为ping通就完全排除链路层也不要一味怀疑运营商。我处理过一个案例ping网关和外网都正常但网页就是打不开最后发现是MTU设成了1500而运营商那边实际承载MTU只有1492导致部分大包被丢弃网页长内容加载不了小包却没问题。第二个是客户端ping服务器不通但服务器ping客户端通。这类单向连通问题多半是防火墙策略或路由不对称。如果两边都在同一个局域网但互ping不同先看系统防火墙是不是把ICMP入站禁了很多Windows机器默认是不回ICMP的这是最容易被忽略的原因。第三个是无线网络丢包严重。无线空口本身就是共享介质干扰、信号弱、漫游切换都会造成丢包和延迟抖动。排查时不要一上来就怪带宽先把终端挪到信号强的地方看丢包是否改善再用有线做对照。这个经验不是命令层面的技巧但能帮你省下大量时间。第四个是别用ping的延迟代表带宽质量。ping延迟低只能说明链路响应快不能说明带宽够用。一根满载的百兆线可能延迟并不高但实际业务吞吐只有几十k。带宽问题需要看吞吐测试而不是ping几千个包就下结论。我的个人体会是网络排查很少靠某个神奇命令一招见效更多是把底层原理和合理步骤结合起来做推理。tracert告诉你路径ping告诉你可达性和延迟两者结合能覆盖从链路到路由的大多数故障场景。如果你能熟练掌握背后的ICMP交互、TTL递减、差错报告机制再配合分段测试的排查顺序就算面对完全陌生的网络心里也不会慌。