Traceroute shows you a path. Ping shows you latency. The trippy command gives you both at once, in a live terminal UI that keeps probing every hop and updating loss, latency, and jitter statistics in real time. It is written in Rust, sits at over 7,000 stars on GitHub, and has quietly become my first stop whenever a connection feels slow and I need to know which hop is to blame.
The tool ships as a single binary called trip. That trips people up on day one, pun intended. You install trippy, then you run trip.
Why the Trippy Command Beats Plain traceroute
Classic traceroute fires a few probes per hop and prints a static result. If hop 7 drops 30% of packets only under load, a single traceroute run will probably miss it. Trippy keeps tracing in rounds, so intermittent loss shows up as a percentage that climbs over time instead of a lucky or unlucky snapshot.
You also get per-hop statistics that traceroute never had: average, best, and worst round trip time, standard deviation, jitter, and a status column. It is the same idea as mtr, but with more protocols, better output formats, and a nicer TUI. If you already use gping for latency graphs, this covers the hop-by-hop side of the same problem. I wrote about that tool in my gping latency monitoring guide.
Installing the Trippy Command
Debian 13 and Ubuntu 24.04 carry it in the standard repositories:
sudo apt install trippyOn other distributions, cargo works everywhere Rust does:
cargo install trippy --lockedThere are also Homebrew, Snap, and Docker options listed on the Trippy GitHub repository. After installing, deal with privileges. Raw sockets need root, so either run it with sudo or grant the capability once and forget about it:
sudo setcap cap_net_raw+p $(which trip)I prefer the setcap route on my own machines. Typing sudo before every trace gets old fast.
1. Run Your First Trace with the Trippy Command
trip example.comThe TUI opens immediately and starts round after round of ICMP probes. Each row is a hop. Watch the Loss% and Sts columns first. Loss at an intermediate hop that disappears at later hops is usually just a router deprioritizing ICMP replies, which is harmless. Loss that persists all the way to the destination is the real signal.
Press h inside the TUI for the help screen and q to quit. The arrow keys move between hops, and Enter shows per-hop detail including a latency chart.
2. Trace over TCP and UDP
Firewalls often drop ICMP while letting real traffic through. When an ICMP trace dies halfway but the website loads fine, tell the trippy command to switch protocols:
sudo trip example.com --tcp --target-port 443
sudo trip example.com --udpThe TCP mode is the one I reach for most. Tracing to port 443 follows roughly the same path your HTTPS traffic takes, so the numbers reflect what users actually experience instead of how routers treat ICMP.
3. Pin Down Multipath Routes
Modern networks balance traffic across equal-cost paths, which makes naive traceroutes show phantom hops from mixed routes. The trippy command supports the Paris and Dublin tracing strategies to keep probes on a consistent path:
sudo trip example.com --udp --multipath-strategy parisIf you have ever stared at a traceroute where hop 5 flips between three different routers every run, this flag is the fix. Dublin mode works the same way with a different encoding, useful when Paris mode still shows flapping.
4. Resolve ASNs and Hostnames in the Trippy Command TUI
Knowing that hop 9 is 72.14.204.1 tells you little. Knowing it belongs to AS15169 tells you the packet just entered Google’s network. Enable AS lookups and show both hostname and IP per hop:
trip example.com -z --tui-address-mode bothThe -z flag (long form --dns-lookup-as-info) queries AS information for every hop. This is how you answer the classic blame question: is the slowdown inside my ISP, at the peering point, or inside the destination network? The AS boundaries make the handoff points obvious.
5. Generate Reports Instead of a TUI
The interactive view is great for live debugging, but for tickets and monitoring you want files. Trippy has report modes that run a fixed number of rounds and print structured output:
sudo trip example.com --mode json --report-cycles 10 > trace.json
sudo trip example.com --mode csv --report-cycles 10 > trace.csvThe trippy command also offers --mode pretty for human-readable tables and --mode markdown for pasting straight into a wiki or GitHub issue. Ten cycles of JSON attached to a ticket carries far more weight with an ISP than “the internet feels slow.”
6. Trace Multiple Targets at Once
trip example.com cloudflare.com google.comThe trippy command traces all of them in one session and lets you flip between targets inside the TUI. I use this to separate a general uplink problem from a single-destination problem in about thirty seconds. If every target shows loss at hop 2, the problem is close to home. If only one target suffers, the problem lives further out.
7. Tune Timing for Slow Links
The defaults probe fast. On congested or high-latency links you can slow the rounds down and extend the timeout so slow hops are not misreported as lost:
trip example.com --min-round-duration 2s --grace-duration 500msThe full flag list is long, and the official documentation covers every option, including TUI themes and custom column layouts.
When Not to Use the Trippy Command
A hop-level tracer tells you where latency and loss appear on a path. It does not tell you what your machine is sending or why. When the question is about traffic content rather than path quality, packet capture is the right tool, and I covered that in the tcpdump troubleshooting guide. For a live overview of which applications are talking to which hosts, Sniffnet fits better.
One more caveat: interpret intermediate hop loss carefully. Routers rate-limit ICMP replies as a matter of policy. Loss only matters when it continues to the final hop.
Wrapping Up
Traceroute and mtr had a long run, but the trippy command replaces both for me: continuous per-hop statistics, TCP and Paris tracing for modern networks, ASN lookups for assigning blame, and JSON reports for making the case to an ISP. Install it, run trip against a host you care about, and let it sit for a few minutes. The path will tell you things a one-shot traceroute never could.