网络卡顿别靠猜：Trippy 帮你缩小排查范围
用三组对照判断卡顿更可能出在本地、运营商还是目标侧，附安装命令和读图避坑。
家里网络一卡，常见动作是重启路由器。运气好，暂时恢复；运气不好，折腾半天，仍然说不清是 Wi-Fi 、运营商，还是对方服务器出了问题。
Trippy 适合做这一步判断。它把持续 ping 的统计、 traceroute 的逐跳路径和终端图形界面放在一起，能看到每一跳的延迟、丢包、抖动和路径变化。它给出的结论应当是“问题更可能落在哪一段”，单看某个红色数字还不够。
截至 2026 年 7 月 21 日，最新稳定版是 0.13.0，支持 Linux 、 macOS 、 Windows 以及多种 BSD，采用 Apache-2.0 许可证。开发分支已经进入 0.14.0-dev，下面的命令以稳定版能力为准。
先把它装上
macOS：
brew install trippy
Windows 可选一种包管理器，安装后用管理员终端运行：
winget install trippy
# 或
scoop install trippy
# 或
choco install trippy
Debian 13 及以后：
sudo apt install trippy
装有 Rust 的系统也可以直接编译安装：
cargo install trippy --locked
运行文件名是 trip。 Linux 通常需要 raw socket 权限。比每次用 root 更克制的做法，是只授予 CAP_NET_RAW：
sudo setcap CAP_NET_RAW+p "$(command -v trip)"
trip example.com
macOS 可以使用无特权模式：
trip example.com --unprivileged
Windows 需要管理员权限。如果界面长期停在 Awaiting data...，再检查入站 ICMP 防火墙规则和单位的安全策略，不要为了跑通工具直接关闭整套防火墙。
它把网络拆成一串“跳点”
Trippy 会逐步增加数据包的 TTL 。数据包每经过一台路由设备，TTL 减一；减到零时，中间设备通常会回一个超时响应。工具借此还原从当前电脑到目标服务器的路径，并持续统计每一跳的表现。
Trippy 项目仓库中的官方界面示例：Loss% 、 Last 、 Avg 、 Best 、 Worst 、 StdDev 等指标会持续更新。
默认使用 ICMP，路径通常比较容易读：
trip example.com
排查网页或 HTTPS 服务时，可以再跑一次 TCP/443 。它更接近真实网页连接所走的协议和端口：
trip example.com --tcp --target-port 443
这里的 TCP/443 只让探针更贴近业务使用的协议和端口。它不会发送 HTTP 请求，也不验证 TLS 、页面加载或服务器处理能力。
UDP 也受支持。家庭网络经过 NAT 时，Dublin 策略通常比 Paris 更合适：
trip example.com --udp --multipath-strategy dublin --source-port 5000 --target-port 33434
macOS 的 --unprivileged 模式不能使用 UDP Paris/Dublin；上面的 Dublin 命令需要相应的 raw socket 权限。 Dublin 可以帮助一组 UDP 探针尽量保持在同一条正向 flow 上，无法控制回程路径。
协议不同，路径也可能不同。 ICMP 正常、 TCP/443 异常，或者 IPv4 正常、 IPv6 异常，都值得分开留证。
一次排障，跑三组对照
假设实际卡顿的是 service.example，请替换成对应的业务域名。
第一组先测默认网关。不同系统可这样查询：
# Linux
ip route show default
# macOS
route -n get default
# Windows 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 也不能单独证明路由器故障。它需要与公网最终目标在同一故障时段一起退化，并通过另一设备或有线连接复现，才应把本地链路列为高优先级候选。
第二组测真实业务，尽量贴近实际协议：
trip service.example -4 --tcp -P 443 -m pretty -C 60 > service-tcp443.txt
第三组测两个相对独立的公网目标：
trip 1.1.1.1 -4 -m pretty -C 60 > control-1.txt
trip 8.8.8.8 -4 -m pretty -C 60 > control-2.txt
这样比只盯一张图可靠得多：
- 在同一故障时段内，网关测试和多个公网最终目标都出现 RTT 尖峰或丢响应，并且另一设备也能复现，问题优先往本地链路查。只有 Wi-Fi 异常时，再排查无线干扰、 AP 和终端。
- 网关稳定，多个相对独立的公网目标从同一上游区段开始恶化，异常一路延续到最终目标，并能在有线或另一设备上复现，运营商路径的嫌疑更大。
- 公网对照正常，只有业务域名的 TCP/443 异常，问题更可能落在通往该业务的特定路径、 CDN 选点或目标网络一侧。仅凭 Trippy 仍无法区分链路、服务器负载和应用层故障。
GiMi 怪诞手绘流程生成的读图示意：单个跳点异常，和异常持续到最终目标，含义完全不同。
最容易看错的是 Loss%
某个中间跳显示 50% 甚至 100% 丢包，后面的跳点和最终目标却完全正常，更常见的解释是该设备少回了探测响应。路由器可能对 ICMP 做限速或低优先级处理，但业务数据仍被正常转发。
更有价值的信号，是异常从某一段开始，并持续出现在后续跳点和最终目标；同时还要看它是否与卡顿发生在同一时间，能否在另一设备、有线连接或另一协议上复现。
一跳显示 ???，后面又恢复，也不等于网络在那里断了。那一跳只是没有回复当前探针。路径地址反复变化，常见原因之一是 ECMP 多路径。 Trippy 支持 flow 查看和 Dublin 等策略，可以帮助复核，但回程仍可能不同。
留证前先处理隐私
需要把结果发给运营商或同事时，可以输出文本或 JSON：
trip --version
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 。公开问题 #1532 记录了报告模式没有同步遵守该设置，因此 JSON 、 CSV 、 Markdown 和文本报告外发前仍需人工检查内网 IP 、主机名、接口或其他环境信息。建议复制一份再脱敏，保留原始证据。
三件事别让它背锅
Trippy 不测上下行带宽，测速仍要用 Speedtest 或 iperf3。它也不捕获任意业务流量，抓包仍要用 Wireshark 或 tcpdump。
它也无法靠单次结果证明“某一跳的路由器坏了”。比较可靠的做法是采集 60 到 300 轮，或让测试覆盖约 1 到 5 分钟及卡顿前后；再比较 Wi-Fi 与有线、 IPv4 与 IPv6 、 ICMP 与实际 TCP 端口。能从对端反向测试时，再补一份回程证据。
下次网络卡顿时，先别急着重启。保留现场，跑完网关、业务目标和两个公网对照，再决定该去调 Wi-Fi 、找运营商，还是检查目标服务。你更常遇到的是 Wi-Fi 抖动、运营商路径异常，还是只有某个服务卡顿？