网络图上的一条线为什么不是固定路由：traceroute、负载均衡与回程边界

同一台设备连续运行两次traceroute，第一次第六跳出现一个地址，第二次同一位置出现两个地址；中间还有一行星号，但目标网页照常打开，终点往返也接近。若把每次输出都画成唯一线路，三种现象会互相冲突。实际上，traceroute展示的是一组探测怎样得到回应，不是网络签发的固定路径证书。

理解这张图，要把探测出去的方向、回应回来的方向、探测参数和发生时间放在一起。单列地址只能说明某台设备为某个到期报文返回了信息。没有回应、地址变化或RTT升高，都需要结合后续跳与终点判断。

每一跳怎样出现在屏幕上

IETF RFC 7276说明，传统traceroute以逐步增加的TTL发送探测。IPv4使用TTL，IPv6对应Hop Limit。第一个探测在第一台转发设备处到期，设备若返回ICMP Time Exceeded，工具便得到第一跳；下一组TTL增加，报文走得更远，再由下一台设备回应。

这个过程持续到目标回应或达到最大跳数。常见实现可以使用UDP、ICMP或TCP探测。traceroute是应用，不是一种单独网络协议，所以看到同一个工具名称，不能假定每台设备发出的报文类型和端口都相同。

屏幕上的地址来自ICMP回应的来源。它没有要求每台转发设备公布名称、物理位置、内部接口关系或完整路由策略。网络图因此是探测视角下的可见序列，而不是对全网拓扑的直接读取。

星号只说明这次没有等到回应

RIPE Atlas结果格式把每次探测分成reply、error和timeout。星号对应timeout：在设定等待时间内没有拿到可记录的回应。它没有附带“业务流量已被丢弃”这层结论。

路由器可能正常转发目标数据，却限制或不生成ICMP回应。回应也可能在超时后才到达。若第六跳是星号，第七跳和终点仍稳定返回，至少说明探测报文可以继续到更远的位置；不能把第六跳单独宣布为线路中断。

另一种情形是从某一跳开始直到终点都没有回应。此时结果仍可能来自目标不接受当前探测协议、路径上的过滤、地址族不通或真实可达性问题。要对照同一目标的实际服务、其他协议与重复时点，不能由星号数量直接选定原因。

Atlas格式还把ICMP错误码与timeout分开。目标不可达、管理策略禁止和端口不可达是不同结果。把所有非RTT数字都抄成“丢包”，会丢掉原始测量已经提供的区别。

单跳RTT不是两台路由器之间的线速

RFC 5388把traceroute描述为从测量源到每个可见跳取得往返时间。某一行的20毫秒，表示探测从源到该回应设备，再由回应沿某条路径回到源所经历的总时间。

它不是上一跳到这一跳的单向耗时。第二跳10毫秒、第三跳30毫秒，不能稳定推出两台设备之间正好花20毫秒。两次回应的回程可能不同，设备处理ICMP的优先级也不同，排队状态更会随瞬间变化。

中间跳RTT比终点大，也不必自相矛盾。中间设备可能低优先级处理回应，而真实转发继续在高速路径上进行；终点对探测回应更快，便会出现后续数值下降。判断业务表现应看终点和真实请求，不用中间最大值替代它们。

RTT仍有用途。固定参数并跨多个时点后，某一段持续出现的整体变化可以提示继续调查。它支持的是“探测往返发生变化”，不是精确的单向传播时间，也不是用户页面完成时间。

一列地址可能混入多条等价路径

网络可以在多条成本相近的路径之间分配流量。RFC 7276指出，从A到B常经过等价多路径，普通traceroute的探测字段变化可能让不同报文被分到不同路径。于是同一跳位出现多个地址，或前后组合看起来像一条不存在的折线路径。

负载均衡常依据源地址、目标地址、协议、端口等流字段做选择。传统UDP traceroute可能逐个改变目标端口；这个变化本身就可能改变选中的路径。用它连续探测时，输出不一定来自同一条流。

Paris Traceroute的目的，是控制影响负载均衡的字段，或有计划地使用不同变化观察路径。RIPE Atlas也把Paris值列为traceroute参数。开启某种Paris模式不会把互联网压缩成唯一线路，它只是让测量者更清楚地区分流内路径与流间多路径。

两次结果地址不同，可能是真实路由变化，也可能是不同流被合法分流。只有固定协议、端口、地址族、探测方式和时间条件，才有资格进一步比较。参数不同的两张图不能先合并，再把差异全部称为改路由。

回程不在正向地址列里

探测报文从源走向某一跳，ICMP回应还要从该跳回到源。屏幕按TTL排列的是正向探测到期的位置，RTT却同时包含回应的回程。若互联网的去程与回程不对称，输出不会自动把回程设备追加在同一列。

所以，一次traceroute不能证明双向都经过同样的城市、运营商或自治系统。要观察反方向，需要在对端或另一个合适测量点向源方向执行独立测量；即使如此，两次测量的时间与流条件也要对应。

这项边界对地理解释尤其重要。主机名带城市缩写，只能当作命名线索；IP注册地和实际转发设备位置也不是同一概念。单跳RTT更不能换算成准确经纬度，因为处理、排队和回程都混在数值中。

参数决定两张图能否比较

RIPE Atlas允许设置IPv4或IPv6、timeout、interval、协议、报文数、大小、first hop。maximum hops、TCP端口和Paris变化。目标若写域名，还可以由平台后端解析，或由各探针自己解析。

这些选项不是装饰。IPv4与IPv6可能拥有不同路由；UDP、ICMP和TCP可能受到不同策略；端口能影响负载均衡；timeout决定多少迟到回应会显示为星号；解析位置不同还可能得到不同目标地址。

比较前应保存完整配置。只有目标地址、源探针或设备、地址族、协议、端口、报文数、大小、超时和解析方式相同，差异才更接近时间变化。只截取地址列，会让读者无法判断两次测量是否可比。

RFC 5388也将测量配置与测量结果分开建模，再把两者合称测量信息。这个设计提醒我们：没有条件的结果不是完整证据。发生时间、工具版本和网络接入环境同样要保留。

路径变化要放在时间线上

RIPE Atlas Path Analysis不是保存一张静态图，而是跨时间比较traceroute。它分别标示跳的增删、ASN或IXP转换和RTT变化，并提供前后时窗对照。路径是会演变的对象，单次输出只是其中一帧。

工具对RTT变化设有可视化阈值：同时超过10毫秒和20%才触发对应高亮。这个门槛用来筛选值得查看的差异，并非通用故障标准。超过门槛不代表网页一定变慢，低于门槛也不能保证每项业务正常。

较稳妥的记录是在普通时段与问题时段各保留多次结果。终点回应情况排在第一项，同一跳位是否持续变化排在第二项；随后区分地址变化、ASN变化和RTT变化。只出现一次的地址抖动与多个时点都存在的路径转移，应使用不同措辞。

若变化恰好发生在维护窗口，也只能说时间上重合。要主张因果，还需要运营方公告、多个测量点或其他独立证据。网络图能帮助缩小问题范围，不能单独指定责任方。

把真实服务与探测结果并排记录

traceroute回答路径回应问题，网页或客户端任务回答服务可用问题。两者应在同一时段并排保存，却不能互相替代。中间跳星号但终点请求正常，结论是中间回应不可见而服务当次可达；终点探测回应但网页失败，则还要查看DNS、TLS、HTTP或应用层。

一次记录可包含：日期时间、设备与接入网络、目标地址、地址族、探测协议与端口、超时、每跳原始结果、终点是否回应。以及同一时刻一个低风险真实请求的状态。敏感查询参数、账号、家庭公网地址和内部设备名称应遮蔽。

不要只保留颜色化路线图。原始地址、星号、错误码和参数才允许日后复查。若工具把多个探测汇总成一条线，也要注明它采用普通模式还是Paris模式，避免把可视化当成原始数据。

结论写成观测而不是判决

“第五跳在三次探测中两次超时，但第六跳与终点均回应”是可复查的观测。“第五跳坏了”则超出证据。“同一固定参数下，晚间多次出现两个不同回应地址”可以成立；“线路每天自动跳到另一个城市”还缺少位置与路由依据。

网络图最有价值的地方，是把复杂路径变成可比较记录。它最容易误导的地方，也是让一串地址看起来像永远不变的物理电缆。

traceroute利用TTL到期与回应逐步探测，负载均衡会让流走向不同路径，单跳RTT还混入回程。星号、地址变化和高亮都只是进一步调查的入口。固定测量条件、跨时点重复、先看终点与真实服务，并明确不可见的回程和设备策略，才能让这张图支持判断而不越过边界。

用一组反例检查读图结论

假设第一轮第四跳为星号，第五跳与终点都有回应。可支持的事实是第四跳没有在等待窗口内返回；不支持“第四跳丢弃全部流量”，因为后续报文已到达更远设备。若把timeout调长后第四跳出现，只能补充回应晚于原窗口，仍不能推断业务转发速度。

再看另一组：同一跳的三个探测分别由地址甲、乙、甲回应，而终点三次RTT相近。这与等价多路径机制相容。普通traceroute可能因端口变化让探测进入不同流；Paris模式用于控制或有计划地改变这些流字段。它不是把两台设备合并成一台，也不是证明真实客户端必定选甲或乙。

第三组中，中间跳RTT从15毫秒升到80毫秒，下一跳与终点仍约20毫秒。由于每行RTT都包含各自回程与回应处理，中间80毫秒不能作为相邻链路至少增加65毫秒的证据。若真实服务同时正常，更准确的文字是“该设备的探测回应变慢，未观察到终点同步增加”。

这些反例共同说明，星号、地址变化和单跳RTT属于不同字段。星号是超时类别，地址是回应来源，RTT是源与回应者之间的往返。把三者压成红色或绿色状态，会抹掉结果格式中最重要的区别。

正向变化与业务影响怎样连接

路径比较工具可标出跳增删、ASN或IXP变化。它告诉观察者前后路径记录不同，却没有自动证明新路径更差。要建立业务关联，需要相同时间窗的终点RTT、真实请求状态和多个重复样本。

如果跳位变化后终点RTT、网页与下载均无同步变化，结论停在“路由观测发生变化”。若多个测量点同时出现相同ASN转换，并伴随终点长尾上升，才形成更强的共同证据；仍应等待运营方信息后再讨论原因。

回程边界始终存在。正向图中新增一个自治系统，不代表回应必经相同系统。没有反向测量时，应把“回程未知”写进记录，而不是用正向地址倒序填充。

一份可复查记录应保留什么

每次运行保留源位置的非敏感描述、目标、解析后的地址、IPv4或IPv6、UDP／ICMP／TCP、端口、报文大小、每跳探测数。timeout、最大跳与Paris设置。结果部分保存每个reply、error和timeout，不删除看起来凌乱的地址。

比较表把“终点是否回应”放在最前，再列跳变化、ASN变化和RTT变化。真实页面或客户端状态另设一栏，不从探测图自动填写。这样即使日后工具换了可视化方式，原始条件仍允许重新判断。

家庭公网地址、内网网关名称和精确位置不必公开。分享时可将源地址遮蔽，只保留测量编号或概括地区；目标若包含私人服务也应匿名。网络测量需要足够上下文，但不以暴露身份换取完整性。

资料来源

• Internet Engineering Task Force (IETF)：《RFC 7276: An Overview of Operations, Administration, and Maintenance Tools》，发布或更新于 2014-06-01
• Internet Engineering Task Force (IETF)：《RFC 5388: Information Model and XML Data Model for Traceroute Measurements》，发布或更新于 2008-12-01
• RIPE NCC：《RIPE Atlas User-defined Measurements》，发布或更新于 2026-07-26
• RIPE NCC：《RIPE Atlas Measurement Result Format Version 5000》，发布或更新于 2026-07-26
• RIPE NCC：《RIPE Atlas Path Analysis》，发布或更新于 2026-07-26