家里或办公网络一卡，很多人第一反应是重启路由器。但真正的问题可能不在路由器，而在 Wi-Fi、运营商链路、目标服务器，甚至某个特定协议或端口。Trippy 的价值，就是把这类问题从“猜”变成“看”。
它把持续 ping 的统计能力和 traceroute 的路径追踪能力结合在一起，用终端图形界面展示每一跳的延迟、丢包、抖动和路径变化。它不能直接告诉你“一定是哪里坏了”，但可以帮你快速缩小范围：
- 是本地 Wi-Fi 或路由器问题？
- 是运营商路径问题？
- 还是目标服务、CDN 或特定网络路径的问题？
项目地址：
https://github.com/fujiapple852/trippyTrippy 是开源工具，采用 Apache-2.0 许可证，支持 Linux、macOS、Windows 和多种 BSD。本文以当前稳定版 0.13.0 的能力为准。
Trippy 是什么？
Trippy 是一个终端网络诊断工具，可以理解为：持续 ping + traceroute + 实时 TUI 界面。
它会持续向目标发送探测包，并记录从本机到目标服务器之间每一跳的表现，包括：
- Loss%：丢包率；
- Last：最近一次延迟；
- Avg：平均延迟；
- Best：最低延迟；
- Worst：最高延迟；
- StdDev：延迟波动；
- 路径变化；
- 每跳地址和响应情况。
默认情况下，Trippy 使用 ICMP 探测：
trip example.com这类结果通常比较容易读，适合先做基础判断。
安装 Trippy
macOS
brew install trippyWindows
可以任选一种包管理器安装。安装后建议使用管理员终端运行。
winget install trippy或：
scoop install trippy或：
choco install trippyDebian 13 及更新版本
sudo apt install trippy使用 Rust 编译安装
如果系统已经有 Rust 环境，也可以直接安装：
cargo install trippy --locked安装后的可执行文件名是：
trip运行权限说明
Linux
Linux 通常需要 raw socket 权限。不建议每次都使用 root，可以只给 trip 授予 CAP_NET_RAW 权限：
sudo setcap CAP_NET_RAW+p "$(command -v trip)"然后直接运行：
trip example.commacOS
macOS 可以使用无特权模式：
trip example.com --unprivilegedWindows
Windows 需要管理员权限运行终端。如果界面长期停在：
Awaiting data...应检查入站 ICMP 防火墙规则或公司安全策略，不建议为了运行工具直接关闭整套防火墙。
Trippy 是如何工作的？
Trippy 会逐步增加数据包的 TTL。数据包每经过一台路由设备，TTL 会减一；当 TTL 减到 0 时，中间设备通常会返回一个超时响应。
Trippy 利用这个机制，还原出从当前电脑到目标服务器的路径，并持续统计每一跳的延迟、丢包和波动。
所以它看到的不是单点结果，而是一条路径上的连续表现。
这也是它比单次 ping 或单次 traceroute 更适合排障的原因。
基础用法
最简单的用法：
trip example.com这会使用 ICMP 探测目标域名。
如果你要排查网页、HTTPS 服务或 API 接口，建议再测试 TCP/443：
trip example.com --tcp --target-port 443这个测试更接近真实网页连接所使用的协议和端口。
需要注意的是：
- 它不会发送 HTTP 请求；
- 它不会验证 TLS 证书；
- 它不会测试页面加载速度；
- 它也不会判断服务器应用层处理能力。
它只是让探测更接近业务实际使用的协议和端口。
UDP 测试
Trippy 也支持 UDP。
家庭网络经过 NAT 时，通常更适合使用 Dublin 策略：
trip example.com --udp --multipath-strategy dublin --source-port 5000 --target-port 33434注意：
- macOS 的
--unprivileged模式不能使用 UDP Paris/Dublin； - Dublin 可以帮助一组 UDP 探针尽量保持在同一条正向 flow 上；
- 回程路径仍然可能不同；
- 不同协议可能走不同路径。
所以如果出现以下情况，值得分别留证：
- ICMP 正常，但 TCP/443 异常；
- IPv4 正常，但 IPv6 异常；
- 网页正常，但某个业务接口异常；
- 某个端口正常，但另一个端口异常。
一次有效排障：建议跑三组对照
假设你真正卡顿的业务是：
service.example请替换成你的实际域名。
建议按下面三组进行测试。
第一组：测试默认网关
先确认本地链路是否稳定。
查询默认网关：
Linux
ip route show defaultmacOS
route -n get defaultWindows PowerShell
Get-NetRoute -DestinationPrefix '0.0.0.0/0' |
Sort-Object RouteMetric如果系统里有 VPN 或虚拟网卡，可能会出现多条默认路由。
需要结合当前正在使用的网络接口和较低的 RouteMetric 判断。
假设默认网关是：
192.168.1.1连续采集 60 轮：
trip 192.168.1.1 -4 -m pretty -C 60注意：
-C 60表示采集 60 轮，不是精确运行 60 秒。实际耗时会受超时时间和轮次设置影响。
即使目标就是网关，也不能只凭高 Loss% 判断路由器故障。
有些设备会限速或不回复 ICMP，但业务数据仍可能正常转发。
更可靠的判断方式是：
- 网关测试是否异常；
- 公网目标是否同时异常；
- 是否与卡顿发生在同一时间段；
- 是否能在另一台设备或有线连接上复现。
第二组：测试真实业务目标
尽量贴近实际业务协议。
如果目标是 HTTPS 服务：
trip service.example -4 --tcp -P 443 -m pretty -C 60 > service-tcp443.txt这条命令会采集 60 轮，并将结果保存到文本文件，方便后续留证。
第三组：测试两个公网对照目标
可以选择两个相对独立的公网地址，例如：
trip 1.1.1.1 -4 -m pretty -C 60 > control-1.txttrip 8.8.8.8 -4 -m pretty -C 60 > control-2.txt这样比只盯着一个目标可靠得多。
如何判断问题在哪一段？
可以按下面逻辑判断。
| 现象 | 更可能的问题位置 |
|---|---|
| 网关、多个公网目标同时异常，且其他设备也能复现 | 本地链路优先，重点查 Wi-Fi、路由器、光猫、网线 |
| 只有 Wi-Fi 异常，有线正常 | Wi-Fi 干扰、AP、无线信道、终端网卡 |
| 网关正常，多个公网目标从同一上游区段开始恶化，并持续到最终目标 | 运营商路径或上游链路 |
| 公网对照正常，只有某个业务域名的 TCP/443 异常 | 目标服务、CDN 节点、特定路径或对方网络 |
需要注意：即使 Trippy 显示某一段异常，也不能直接等同于应用层故障。服务器负载、接口超时、TLS 握手失败、HTTP 错误，仍需要结合业务日志和其他工具判断。
最容易看错的指标：Loss%
很多人看到某个中间跳出现 50% 或 100% 丢包，就认为那里断网了。
但如果后面的跳点和最终目标完全正常，更常见的解释是：
该中间设备没有认真回复探测包。
很多路由器会对 ICMP 做限速、过滤或低优先级处理，但真实业务流量仍然可以正常转发。
因此，更有价值的信号是：
- 异常是否从某跳开始；
- 是否持续出现在后续跳点；
- 是否一直延续到最终目标；
- 是否与卡顿发生在同一时间；
- 是否能用另一设备、有线连接或不同协议复现。
如果某一跳显示：
???但后面跳点恢复正常，也不代表网络在那里断了。
它只是没有回复当前探针。
如果路径地址反复变化，常见原因之一是 ECMP 多路径。
Trippy 支持 flow 查看和 Dublin 等策略，可以帮助复核，但回程路径仍然可能不同。
如何保留证据？
如果要把结果发给运营商、同事或技术支持，可以导出文本或 JSON。
查看版本：
trip --version导出 JSON 结果：
trip service.example --tcp -P 443 -m json -C 120 > service-$(date +%Y%m%d-%H%M%S).json如果只需要截图 TUI 界面，可以隐藏源地址和前几跳：
trip service.example --tcp -P 443 --tui-privacy-max-ttl 2需要注意：0.13.0 的隐私设置主要作用于 TUI。项目公开 issue #1532 记录了报告模式没有完全同步遵守该设置。
因此，JSON、CSV、Markdown 和文本报告在对外发送前，仍然需要人工检查是否包含：
- 内网 IP；
- 主机名；
- 网络接口；
- 公司域名；
- 其他环境信息。
建议先复制一份再脱敏，保留原始证据。
Trippy 不能做什么？
Trippy 是排障工具，不是万能工具。
它不测上下行带宽。如果要测速，使用：
Speedtest
iperf3它也不捕获业务流量。
如果需要抓包分析，使用：
Wireshark
tcpdump它也不能靠一次结果证明“某个路由器坏了”。更可靠的做法是：
- 采集 60 到 300 轮；
- 覆盖卡顿发生前后；
- 对比 Wi-Fi 和有线；
- 对比 IPv4 和 IPv6；
- 对比 ICMP 和实际 TCP 端口；
- 如果可能，从对端反向测试回程路径。
总结
下次网络卡顿时，先别急着重启路由器。
更合理的顺序是：
- 测试默认网关；
- 测试真实业务目标；
- 测试两个公网对照目标；
- 对比异常是否同时出现；
- 再决定是调 Wi-Fi、找运营商，还是检查目标服务。
Trippy 的价值不是给你一个绝对结论，而是帮你把问题从“玄学”变成可观察、可对比、可留证的网络证据。
常见问题
Trippy 和 ping 有什么区别？
ping 通常只测试到目标的连通性和延迟。Trippy 会持续统计路径中每一跳的表现，更适合判断问题发生在哪一段。
Trippy 和 traceroute 有什么区别？
traceroute 主要展示路径。Trippy 在路径基础上增加了持续统计、丢包率、延迟波动和实时界面。
中间跳显示 100% 丢包，是不是网络断了？
不一定。如果后续跳点和最终目标正常，可能只是中间设备不回复 ICMP 探测。
网络卡顿时应该先测什么？
建议先测默认网关，再测业务目标，最后测公网对照目标。通过三组结果对比，可以更快判断问题是在本地、运营商，还是目标服务。
文章评论