借助路由跟踪结果判断链路走向

借助路由跟踪结果判断链路走向，核心是逐跳解析每一行数据的IP归属、延迟变化与丢包情况，再结合路由节点类型（运营商骨干网、IXP互联网交换中心、IDC机房）还原数据包的完整“旅行路线”。

链路问题排查是网络工程师和站长日常绕不开的活儿,当你发现网站访问慢、视频卡顿、游戏掉线，第一反应往往是测ping，ping只能告诉你“链路好不好”，但说不清“问题出在哪个环节”，路由跟踪（tracert/traceroute）才是顺着电信号一站一站往后看的显微镜，这篇文章直接教你盯哪几列数据，怎么解读节点类型，以及如何把延迟突增点精准定位到某一个运营商机房。

tracert和traceroute命令怎么用结果逐行解读

Windows系统用tracert 目标域名或IP，Linux和macOS用traceroute -n 目标IP，macOS有时需要先通过brew install traceroute安装，命令本身不难，难的是输出结果里那些带星号的行、三层延迟数据、以及看起来“堵得慌”的中间节点到底意味着什么。

路由跟踪结果里每一列代表什么

Windows版tracert输出一般是四五列结构,第一列是跳数编号（1、2、3……最多30跳），后面跟着三个以“毫秒”为单位的延迟探测值，这三个值表示数据包从你本机出发，到达这一跳路由设备分别消耗的时间。延迟值是有参考系才有意义的，不能孤立看数字大小。

第三列（或者第四列）是这一跳的IP地址，Linux下traceroute默认会有“三列延迟+主机名/IP”的布局，加-n参数可以直接禁掉反向解析，输出纯IP，排查速度会快不少，这里有个实操小技巧：如果主机名里带着“beijing”“guangzhou”之类的地名缩写，或者“ct”“cu”“cm”的运营商标识，这一跳的物理位置和归属基本就能猜个大概了。

为什么结果里会出现星号星号星号

路由跟踪每一跳会发三个探测包,如果某个包超时未返回，那一列就显示，三个全是星号不代表链路不通，常见原因有三种，第一是中间路由设备开启了ICMP限速策略，不回应探测请求这种情况在运营商骨干网设备上相当普遍，后续跳数依然正常输出就说明链路本身没问题，第二是防火墙规则直接丢弃了TTL超时通知报文，多见于企业防护设备和云厂商负载均衡，第三才是真正的链路黑洞，比如路由环路导致数据包一直转圈。

判断方法很简单：如果连着好几跳全是星号，但最终一跳（目标IP）返回正常，说明中间节点只是“沉默”，不影响数据流转；如果连着五跳以上全是星号，且最终跳也超时，那才是真断了。

延迟数值里的三个隐藏信号

同一跳的三个延迟值相差不大,说明这条链路路径相对稳定，负载均衡没有剧烈变化，三个值忽高忽低跳变幅度超过30毫秒，提示这一跳设备的转发平面压力较大，或者物理链路存在无线干扰（多见于跨海光缆和微波中继段），三个值整体稳定但数值偏高，比如每一跳都稳定在30到40毫秒，那瓶颈更可能出在传播距离上光在光纤里跑一公里大约5微秒，跨省链路有50毫秒延迟是物理合理值。

tracert怎么看网络延迟高三步定位慢在哪一跳

tracert输出的延迟是逐跳累进的，第5跳显示30毫秒，第6跳显示45毫秒，这两者相减得到15毫秒，这多出来的部分才是第6跳到第7跳之间真正增加的中转耗时，当你打开路由跟踪结果图，不要把眼睛钉在绝对数值上，要盯“增量”。

第一步：先把每一跳延迟换算成“增量”

手动心算太累,可以直接用表格辅助，假设某次tracert结果如下：

这个表里第8跳的增量突然飙到72毫秒,节点间的“额外耗时”就出在这一段，正常的同城机房跳间增量在5毫秒以内，跨省骨干网跳间增量在10到20毫秒之间，一旦出现40毫秒以上的跳间增量，基本可以判定这一跳的转发路径做了绕行，比如从华东绕道华北再进华南。

第二步：结合IP归属地和AS号判断是不是绕了远路

延迟高的下一步是搞清楚“这条路走得值不值”，把异常跳数的IP丢进IP138或者一些开源IP库查询归属，如果本机在北京、目标服务器在上海，跟踪结果里却出现了广州的节点，那么绕路实锤了，物理距离变长，延迟自然下不来。

还可以用whois命令或者网上的AS Lookup工具查这一跳的AS号，国内三大运营商的骨干网AS号相对稳定，比如电信骨干网常见AS4134（ChinaNet），联通是AS9929和AS4837，移动是AS9808，教育网是AS4538。如果第10跳是AS4134的广州节点，第12跳突然变成AS9808的北京节点，说明运营商之间的互联点位置可能选得比较远，或者存在非最优路由策略。

第三步：分清楚是“最后一公里”慢还是“骨干网”慢

在跟踪结果里看看目标IP（最后一跳）和倒数第二跳的延迟差，如果最后一跳是从路由器转发到目标服务器的过程，数值暴增几十毫秒，要去查服务器的带宽资源是否被打满，或者服务器近端防火墙转发性能是否足够，如果延迟瓶颈在中间某段骨干网节点上，你能做的选择不多，要么联系当前运营商申请优化路由，要么考虑更换接入线路，比如从单线改成BGP多线，或者上CDN把内容分发到离用户更近的边缘节点。

路由跟踪结果判断链路故障丢包集中在哪一段

丢包率和延迟一样,要分开看，某一段节点显示3%丢包是正常现象，当某一条链路的丢包率持续高于10%且延迟同步抬升，这条链路大概率已经出现拥塞或线路质量劣化。

默认路由跟踪丢包率太高：用fping和mtr补数据

crt命令默认发三个探测包,丢包率的样本量太小，偶尔一个超时包没有统计意义，更可靠的工具是mtr（My Traceroute），它结合了ping和tracert的特点，持续发送探测包并统计每一跳的丢包率和延迟抖动，安装命令分别是

yum install mtr -y（CentOS）和apt-get install mtr-tiny -y（Ubuntu），运行mtr -rwz 目标IP输出的最后一列会显示每一跳的丢包百分比，跑个一两分钟，数据比tracert的三次随机探测可靠得多。

路由跟踪的“最后一跳丢包”未必是真丢包

目标服务器很多会配置只进不出的ICMP策略,也就是说你的探测包到达了服务器，但服务器的回程ICMP包被防火墙拦掉了，tracert就会显示最后一跳丢包率高，此时登录服务器或让服务器侧人员主动发起一次反向tracert，就能佐证问题到底在不在这一台设备上。存在高丢包的跳数和实际访问卡顿的跳数不一定重合，回程路径拥堵也会导致页面加载慢，但系统不会在你发出的这个数据包上直接体现。

跨省链路延迟高怎么排查典型场景实战演练

以一个常见场景为例：你在上海的公司办公网络，访问一台部署在深圳机房的轻量应用服务器，路由跟踪结果回显如下：

整体延迟从上海的8毫秒跳到广州的38毫秒,增量30毫秒，这一段是上海到广州的物理骨干传输，符合长途传输的合理范围，接着广州到深圳只有20毫秒左右，链路路径合理，结论就是：链路本身没有明显瓶颈，55毫秒的总延迟是沪广深物理距离的正常表现，访问慢的根因大概率是应用层或服务器带宽，而不是链路走向。

再看另一个案例,同样从上海到深圳，结果却是：

这就尴尬了,上海访问深圳，数据包先北上到北京又西进西安，再到广州绕个大弯，总延迟80毫秒比正常路径多了25毫秒左右，这类跨运营商绕行在非BGP线路中经常出现。行业共识认为，跨运营商访问场景中约有三成左右的延迟问题源自路由绕行而非带宽不足，你以为的“带宽不够”其实多半是路由的锅，解决办法是更换托管服务商的线路类型，直接从单IP改成BGP多线接入，让路由自动选择最近出口；私有场景下也可以考虑专线或SD-WAN方案。

路由跟踪结果怎么看是哪个运营商识别非对称路径问题

你访问的是电信机房,但路由跟踪结果显示有一部分路径经过了联通的节点，这就是俗称的“跨网出省”，数据包发送路径是电信→联通→目标接入，回程可能走联通→电信→你本机。

只要出方向或回方向任意一段跨网，整体的稳定性和时延就会明显劣化，tracert只能看到出方向路径，回程路径通常需要通过目标服务器侧的traceroute -n 你的公网IP来反向确认。

在路由跟踪环节识别运营商切换的核心依据还是IP归属和AS号,如果第3跳是电信的IP段（AS4134），第5跳突然出现AS4837（联通骨干网），那说明你的流量在某一个互联网交换中心（IXP）被“倒手”给了联通，判断切换的核心指标是延迟突变，同一跳延迟从10毫秒级别直接跳到30到50毫秒级别，如果出现在晚上高峰段，大概率是互联互通拥塞在作祟。

远程服务器和本地网络的路由跟踪差异

本地网络里的tracert执行,从你的电脑到运营商网关，再到上行BAS设备，前三跳都在城域网内绕，远程服务器上执行tracert则完全相反，它测的是服务器到某个目标地址的出方向链路质量。当你的网站访问很慢，建议同时从本地和服务端各发一次路由跟踪，本地负责看用户边缘侧，服务端负责看服务托管侧，中间骨干网重叠的部分才是真正的公共路径。

如果你长期在服务器上排查链路质量,可以顺手写个简单的Shell定时任务，把mtr -rwz 目标IP > 日志文件加进crontab，每小时跑一次，一周下来就能摸清哪一段链路在哪个时段容易劣化，有一种比较常见的情况是，白天延迟正常，晚高峰7到11点延迟飙升50毫秒以上，这类定时测试数据就是申请带宽升级或推动运营商路由优化时最硬核的凭证。

Q&A：路由跟踪常见疑问

路由跟踪能测出网站具体慢在哪个页面元素吗？

不能,tracert只覆盖网络层路径，从你的设备到服务器IP这一段数据通路，页面加载慢涉及DNS解析、TCP握手、TLS协商、后端业务处理时间、数据库查询等多个环节，这些在应用层才能观测到，慢在哪一段得用浏览器开发者工具的Network面板配合服务器侧的性能监控日志来交叉判断。

本机tracert没问题，但朋友反馈访问慢，该怎么继续排查？

请那位朋友把路由跟踪结果和访问页面的截图发给你,重点看他的最后一跳延迟和最终响应的HTTP状态码，如果最后一跳延迟高且伴随TCP重传，优先检查你服务器的带宽出口和防火墙的并发连接数限制，如果最后一跳正常但页面转圈，那问题大概率在应用服务或数据库响应上，与链路走向无关。

路由跟踪里每一跳的IP经常变化，正常吗？

正常,核心路由器通常运行OSPF或BGP协议做动态选路，设备重启、链路割接、流量调度都会引起路径变更，本地DNS的负载均衡策略也会让不同时段的探测包被转发到不同机房出口，连续多次tracert结果不同，只要延迟分布相差不大且无新增丢包，就不必担心，若路径频繁在两条延迟差异显著的线路间横跳，那就观察一下是否与运营商优化策略有关。