traceroute本身不直接测试负载均衡，但通过多次运行观察路径跳变、同一跳IP交替出现、星号抖动及TCP模式下路径稳定性差异等现象，可间接识别后端是否存在负载均衡策略。
traceroute 本身不直接“测试”负载均衡器，但它能提供关键路径线索，帮助你判断后端是否存在负载均衡策略。核心思路是：负载均衡器会把请求分发到不同节点，而 traceroute 的路径结果若出现不一致或重复 IP 模式，就是重要信号。
多次运行看路径是否跳变
负载均衡器（尤其是四层 SLB）常将不同连接导向不同后端服务器或出口网关。这意味着连续执行几次 traceroute，可能得到明显不同的中间路径。
- 运行
traceroute -n example.com三次，保存每次输出 - 对比 hop 数相同的层级：比如第5跳，第一次是
203.100.20.5，第二次变成203.100.20.6，第三次又回到203.100.20.5，这种交替出现就是典型分发迹象 - 注意排除 DNS 解析影响——加
-n参数避免主机名缓存干扰
观察同一跳出现多个 IP 或星号抖动
某些负载均衡设备（如 VIP 后接多台 LVS 转发节点）会在同一 hop 层级返回多个不同 IP，或因部分节点不响应 ICMP 导致该跳显示为 * 但相邻跳次稳定变化。
- 例如第4跳输出：
4 * * 203.100.20.10，而第5跳在不同执行中分别显示203.100.30.1、203.100.30.2、203.100.30.3——说明第4跳之后存在横向分发 - 若某 hop 始终显示
*，但后续 hop 正常且 IP 变化频繁，也可能是该层负载设备禁用了 ICMP 响应，但仍参与路径选择
用 TCP 模式贴近真实业务流量
默认 UDP 模式可能被防火墙拦截或绕过负载逻辑；改用 TCP（如 HTTPS 端口 443）更接近实际访问行为，提升识别准确率。
- Linux 下执行：
sudo traceroute -T -p 443 example.com - Windows 下需用第三方工具（如
mtr或 PowerShell 的Test-NetConnection -Port 443辅助），因原生 tracert 不支持 TCP - 若 TCP 模式下路径稳定性远高于 UDP 模式，说明负载策略可能基于四层连接特征（如源端口、五元组哈希）生效
结合时延与丢包模式交叉验证
单纯看 IP 变化不够可靠，要同步关注延迟和丢包规律：
- 同一 hop 多次探测中，若三个时间值差异极大（如
12ms / 87ms / 3ms），可能对应不同物理路径或后端节点性能不均 - 连续几跳都出现间歇性
*，但目标仍可达，大概率是某段链路中存在多出口的负载设备，部分路径未开放 ICMP 回复 - 若从某 hop 开始，后续所有跳延迟突然升高且波动剧烈，可能是负载器后端节点资源紧张或健康检查异常
