中间某一跳显示，是否说明路径断在该跳？

不一定，很多路由器对 TTL 超时消息限速或不回复；要看后续跳和目标是否可达，以及多次探测是否稳定。

UDP 探测没有结果时，可以怎样换协议继续排查？

用 -P icmp 或 sudo traceroute -P tcp -p 443 换协议和端口，绕开只封锁 UDP 的过滤规则。

macOS 上为什么 sudo traceroute -P tcp 常常需要提权？

TCP 探测需要 pcap/BPF 抓取回复包，普通用户没有相应权限时会报 pcapactivate() failed。

系统学习 macOS 学习路径：从 BSD 文件命令到系统、网络与开发维护

traceroute

逐跳显示数据包到目标经过的路由器，定位在哪一段开始变慢或不通。

补充说明

traceroute 利用 TTL 递增和中间路由器的 ICMP 超时回复，把路径一跳一跳打印出来。macOS 自带的是 Apple 版 1.4a12，默认发 UDP 探测，支持 -P icmp、-P tcp、-P gre。排“能 ping 通但某些站点很慢”“在哪一跳开始丢包”时用它；只想测 MTU 或单向延迟则用别的工具。

和 Linux 不同，macOS 没有 tracepath，也没有预装 mtr；需要持续观测可以 brew install mtr。默认 UDP 和 ICMP 探测普通用户就能运行，TCP 探测会走 pcap 抓包，未授权时常见 pcap_activate() failed，需要 sudo。-n 关闭反向解析，-m 限制跳数，-q 1 每跳只发一个包，能明显加快排障。

中间的 * * * 不一定是故障：路由器常对 TTL 超时消息限速或直接丢弃。判断要看后续跳是否恢复、目标是否可达，以及同一路径的多次结果是否稳定。

常用示例

# 基本路径，关闭反解避免 DNS 拖慢
% traceroute -n example.com

# 最多 16 跳，每跳一个探测，等待 2 秒
% traceroute -n -m 16 -q 1 -w 2 example.com

# 用 ICMP 探测，绕开封锁 UDP 的网络
% traceroute -P icmp -n example.com

# 用 TCP 443 探测，模拟 HTTPS 流量；通常需要 sudo
% sudo traceroute -P tcp -p 443 -n example.com

# 设置不分片，观察大包路径是否中断
% traceroute -F -n example.com

# 固定目标端口，测试防火墙对特定端口的放行
% sudo traceroute -P tcp -p 8443 -e -n example.com

# 指定源接口，多网卡或 VPN 环境常用
% traceroute -i en0 -n example.com

# 查看每跳未响应探测的汇总
% traceroute -S -n example.com

易错点与排错

某一跳全是 * * * 但后面跳正常：该路由器只是不回复 TTL 超时，不代表路径断了；看目标是否最终可达。
目标一直 * * * 且 ping 也不通：可能是 UDP 被过滤，换 -P icmp 或 sudo traceroute -P tcp -p 443 再试。
TCP 探测报 pcap_activate() failed：普通用户没有 BPF 权限，加 sudo；不要误判成网络错误。
路径和预期不符、绕远：先确认 VPN、代理和 -i 指定的接口；多网卡时源地址选错会走另一张路由表。
反向解析让命令看起来很慢：始终加 -n；需要主机名时再单独查。
输出里的 !H 表示主机不可达，!N 表示网络不可达，!X 表示管理过滤；这些是目标侧返回的错误，不是 traceroute 自身故障。
macOS 没有 tracepath，不能用它测路径 MTU；用 ping -D -s 1472 逐步缩小包长代替。

参考链接

读完自测

合上页面，先回答，再展开对照。

中间某一跳显示 * * *，是否说明路径断在该跳？
UDP 探测没有结果时，可以怎样换协议继续排查？
macOS 上为什么 sudo traceroute -P tcp 常常需要提权？

答案

不一定，很多路由器对 TTL 超时消息限速或不回复；要看后续跳和目标是否可达，以及多次探测是否稳定。
用 -P icmp 或 sudo traceroute -P tcp -p 443 换协议和端口，绕开只封锁 UDP 的过滤规则。
TCP 探测需要 pcap/BPF 抓取回复包，普通用户没有相应权限时会报 pcap_activate() failed。