Traceroute and MTR on a Mac (2026): Reading the Path Correctly
Short version. macOS ships traceroute, and brew install mtr gets you the continuous version. The tools are the easy part. The hard part is reading the output, and one specific misreading, treating loss at a middle hop as a fault, is why most self-collected evidence gets dismissed.
Unlike iOS, a Mac gives you these natively. Open Terminal and you already have traceroute.
Full disclosure: I build PingKit Agent, so weigh the recommendation accordingly. The limits section is not padding, and there is a whole category of Mac network tool below that PingKit deliberately is not.
Running Them
traceroute, built in:
traceroute 1.1.1.1
One snapshot of the path. Useful for seeing that traffic is taking an absurd route, less useful for intermittent problems.
mtr, via Homebrew:
brew install mtr
then
sudo mtr 1.1.1.1
It needs sudo because it uses raw sockets. MTR maps the path and then keeps probing every hop, giving per-hop latency and loss over hundreds of samples. That is what makes intermittent faults visible.
The Misreading That Ruins Evidence
This is the whole reason to read a page about MTR rather than just running it.
Loss at a middle hop that does not appear at later hops is not a fault. Routers deprioritise generating replies to probes, because forwarding traffic is their actual job. A hop showing 40% loss while every hop after it shows 0% is rate limiting its own replies and working correctly.
The pattern that matters is loss beginning at a hop and continuing through every subsequent hop including the destination. Anything else is noise. Sending an ISP a screenshot of the first kind is a reliable way to have a ticket closed, and they will be right to close it.
The same applies to latency. A single hop with high latency that does not raise the latency of later hops is harmless. Read the trend across the whole path to the destination, never a single row.
Reading the Path
| What you see | What it means |
|---|---|
| Loss at one hop, clean after it | Rate limiting. Ignore |
| Loss starting at a hop, continuing to the end | Real problem at or before that hop |
| First hop slow | Your local network or WiFi |
| Latency jumps and stays high | Usually a long physical link, often expected |
| Path changes between runs | Normal. Routing is dynamic |
| Stars all the way to the end | Probes blocked, or the destination is unreachable |
When a GUI Is Worth It
Command line MTR is excellent for a live look. It is less good at leaving running for days and summarising what happened, which is what you need for an intermittent fault.
PingKit Agent runs traceroute and continuous connectivity checks as part of ongoing monitoring, and records latency spikes and internet up and down events with timestamps, so the history exists without you remembering to start a capture.
Honest Limits
- PingKit shows hop IP addresses and latency, not reverse-DNS hostnames. Command line traceroute does resolve names, so if you want hop names, use Terminal.
- Monitoring pauses when the Mac sleeps.
- MTR at the command line needs sudo, which is a raw socket requirement rather than something an app can work around.
- macOS 15 or later for the Agent.
Frequently Asked Questions
Does macOS have traceroute built in?
Yes. Open Terminal and run traceroute followed by a hostname or IP address. There is no need to install anything for a single path snapshot.
How do I install mtr on a Mac?
brew install mtr using Homebrew, then run it with sudo, for example sudo mtr 1.1.1.1. It needs elevated privileges because it uses raw sockets.
Why does traceroute show packet loss at one hop but not the destination?
That router is rate limiting its replies to probes rather than dropping traffic. Routers prioritise forwarding over answering diagnostics. Only loss that begins at a hop and continues through to the final destination indicates a real fault.
What is the difference between traceroute and MTR?
traceroute maps the path once. MTR maps it and then keeps probing every hop continuously, reporting latency and packet loss per hop over many samples, which makes intermittent problems visible where a single traceroute run would miss them.
Why do stars appear in traceroute output?
A hop did not reply within the timeout. Usually the router is configured not to respond to probes, which is common and harmless. Stars all the way to the destination mean probes are being blocked or the destination is unreachable.
History without remembering to start a capture
Continuous connectivity checks with timestamped latency spike and internet down events, plus traceroute. macOS 15 or later.
Get PingKit Agent for Mac