Windows
macOS
Linux用路由追踪观察连接路径
连接频繁超时或两条网络表现不同，可以用 NextTrace 比较逐跳回复。输出的地址、RTT 与 ASN 有助于找路线线索，再与实际请求一起判断。
它适合回答“探测走了哪些回复路径”“异常从哪里开始出现”。它不是下载测速，也不会自动判断代理服务质量。域名解析问题先用 doggo；要确认具体应用握手，则可以继续用 Wireshark。
下载与命令检查
进入 NextTrace 官方发行页，选择与你的系统和处理器匹配的可执行文件。Linux 与 macOS 是不同系统；amd64 与 arm64 也不能互换。普通用户先选稳定发行，开发分支的说明可能包含尚未发布参数。
- macOS 已有 Homebrew 时可以执行
brew install nexttrace；软件包版本可能晚于官方发行。 - 直接下载 Linux/macOS 文件时，按发行说明保存为
nexttrace，在所在目录执行chmod +x ./nexttrace。 - Windows 下载匹配架构的 exe，在 PowerShell 中用
.\nexttrace.exe --help查看用法。
下文假设 nexttrace 已在 PATH；若只放在当前目录，Linux/macOS 把命令开头改为 ./nexttrace，Windows 改为 .\nexttrace.exe。先执行 nexttrace --version 与 nexttrace --help，核对本机实际支持的参数。
权限和 Windows 支持限制
官方将 Windows 支持标为实验阶段。不同探测模式依赖不同系统能力；不要看到有 exe 就推断所有模式与 Linux 完全一致。Windows 的 TCP/UDP 模式涉及 WinDivert 与管理员权限，ICMP 也可能受防火墙设置影响，应按所用版本的官方说明操作。
Linux 的原始套接字探测通常需要相应权限；macOS 的 TCP/UDP 模式也可能需要提升权限。遇到明确权限错误时，先检查可信下载来源与当前模式，再针对这一次命令使用所需权限。不要为了跑追踪关闭整个防火墙。
容器、虚拟机和受管理网络可能没有相关能力。权限错误与探测目标不回应不同：前者应先修复本机执行条件，后者才进入路径与网络分析。
开始一次 ICMP 追踪
以下使用文档示例域名，限制为 IPv4、每跳三个样本、最多二十跳。默认模式是 ICMP：
nexttrace -4 -q 3 -m 20 example.com-4 固定 IPv4，方便比较同一地址族；-q 设置逐跳样本数；-m 限制最大跳数。目标未在二十跳内出现时，先检查最终停止原因，不要立即认定目标不可达。
域名可能解析到多个地址，线路也会随负载均衡改变。比较两次结果时记录最终选中的目标 IP、运行时间和使用网络。示例不承诺出现固定跳数、运营商或响应时间，输出应以你当时的测量为准。
用 TCP、UDP 对照
ICMP 无回复时，可对同一目标做少量其他协议对照。TCP 例子使用网页常见端口 443；UDP 使用路由追踪端口 33494。一次执行一条命令：
nexttrace -4 -T -p 443 -q 3 -m 20 example.com
nexttrace -4 -U -p 33494 -q 3 -m 20 example.com-T 选择 TCP，-U 选择 UDP，-p 指定目标端口。端口与协议可能影响防火墙响应和负载均衡，因此结果有差异不必然是工具错误。UDP 目标不提供该端口服务，也可能影响终点反馈。
TCP 443 探测不能替代 TLS 与网页请求验证；追踪有回复也不代表页面加载成功。对业务连接仍应另外做实际请求，首页的 验证命令工具可辅助检查。
星号、延迟与 ASN 标注
| 现象 | 解释与下一步 |
|---|---|
| 中间某跳显示星号，后续仍有回复 | 该跳没有在期限内回应探测，可能限速或过滤控制消息；不代表它不能转发业务包。 |
| 中间跳延迟高，后续又降低 | 可能是该路由器回复探测较慢，不应把单跳响应时间直接当作线路转发延迟。 |
| 从某跳起后续都异常，终点也异常 | 值得继续核查，结合重复测量、实际请求与另一网络对照，仍不能单次归责。 |
| 显示意外城市或 ASN | 查看 IP 与路由关系；地理与归属数据库可能不准确，不等于设备真实位置。 |
显示的延迟是探测到相应回复者的往返时间，不是单向耗时，也不是相邻两跳之间的纯链路延迟。若使用连续探测统计丢包，同样要关注终点与后续是否延续异常：中间跳丢包比例不能直接当作终点业务丢包比例。
保存结果并比较路线
- 固定同一目标 IP、协议与端口，先做一次短追踪。
- 异常时稍后再测，记录是否可重复；不要只挑一张最差截图。
- 再用另一网络做相同参数对照，确认目标与地址族没有变化。
- 同时记录一次真实应用请求是否成功，把路径线索与用户体验对应起来。
开启本机系统代理通常不会自动让原始 ICMP/TCP/UDP 探测走代理；TUN、系统路由与远端测量也有各自的路径。要分析代理链路，必须先确认探测从哪里发出、实际路由指向哪里，不能把本机直连追踪当作远端服务器回程。
分享结果时提供版本、时间、目标、参数与现象，遮盖自己的公网或内网信息。带地理标注的输出依赖外部数据服务，标注失败与核心探测失败要分开记录。更多思路可见 网络故障排查。
升级后核对参数
保留原输出、目标 IP 和版本。沿官方发行页或原包管理器更新后，先运行 nexttrace --help，再做一次相同参数的短追踪；路线变化要结合当时网络判断。
常见问题
中间一跳不回应，是不是网络断了？
不一定。若后续跳与终点仍有回复，中间设备可能只是不回应或限速探测消息。需要结合后续表现与真实请求判断。
为什么 Windows 某些模式不能用？
Windows 仍为实验支持，模式可能依赖管理员权限、WinDivert 或特定防火墙设置。先核对当前发行说明与本机帮助，不应关闭全部防护来排查。
显示的城市能证明发生了路由绕行吗？
不能仅靠城市标签证明。地理数据库可能有误，应结合 IP、ASN、相邻跳变化与重复追踪分析，并保留原始地址供复核。
参考资料
下载、系统要求和配置字段以对应版本的官方说明为准。文中的流程图由 AFQKit 绘制。