Your internet is slow, but the connection is technically working. Pages load eventually. Video calls stutter. Something is wrong somewhere between your Mac and the server. Traceroute tells you exactly where.

A macOS traceroute shows every router your data passes through on the way to a destination, with response times for each. If there’s congestion, a misconfigured route, or a dead link, it shows up in the output. This guide covers the traceroute command, how to read what it returns, what the common patterns mean, and how to run a traceroute on Mac without Terminal if you prefer a visual interface.

What traceroute does

Data doesn’t travel directly from your Mac to a server. It hops through a chain of routers: your home router, your ISP’s equipment, regional backbone networks, and finally the destination’s network. Each step is called a hop.

Traceroute maps that chain by exploiting a field in every network packet called TTL (time to live). TTL is a counter. Every router that forwards a packet decrements it by one. When TTL reaches zero, the router drops the packet and sends back an error message identifying itself.

Traceroute sends a packet with TTL=1. The first router drops it and replies. Traceroute records that router’s address and response time, then sends a TTL=2 packet. The second router replies. This continues hop by hop until packets reach the destination.

The result is a complete map of the path, with latency measurements at each step.

Each hop is a router along the path. The timing at each step reveals where slowdowns occur.

Running traceroute on macOS

Open Terminal (Applications > Utilities > Terminal) and run:

traceroute google.com

Results appear line by line as each hop responds. You don’t have to wait for the whole run to finish reading the early hops.

What the output looks like

traceroute to google.com (142.250.80.46), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)          2.849 ms   2.103 ms   1.987 ms
 2  96.120.68.69 (96.120.68.69)        12.445 ms  11.203 ms  10.987 ms
 3  68.87.167.117 (68.87.167.117)      14.221 ms  13.008 ms  12.445 ms
 4  * * *
 5  72.14.215.171 (72.14.215.171)      18.334 ms  17.112 ms  16.889 ms
 6  108.170.246.33 (108.170.246.33)    19.441 ms  18.902 ms  18.776 ms
 7  lga34s32-in-f14.1e100.net (142.250.80.46)    20.112 ms  19.887 ms  19.654 ms

The columns are:

Hop number (leftmost): the position in the chain. Hop 1 is your home router.
Hostname and IP: the router’s identity. Reverse DNS gives the hostname when available; otherwise you just see the IP.
Three time readings in ms: traceroute sends three probes per hop. These are the round-trip times for each. Three readings let you spot inconsistency: if two are 12ms and one is 80ms, that hop has occasional spikes.

Useful flags

Flag	What it does
`-n`	Skip DNS lookups. Shows IP addresses only, runs faster.
`-m 30`	Set max hops (default is 64). Useful if you know the destination is nearby.
`-q 1`	Send only one probe per hop instead of three. Faster, less data.
`-w 2`	Wait only 2 seconds per hop instead of 5. Speeds up runs to unresponsive hops.

A common combination for faster results:

traceroute -n -q 1 -w 2 google.com

How to read traceroute results

Latency progression

Latency generally increases as hops get further from you. Your home router responds in 1-5ms. Your ISP’s equipment might be 10-20ms. International destinations can be 100-200ms or more. That progression is normal.

What you’re looking for is a sudden jump: several consecutive hops in a similar range, then one hop where latency spikes sharply and stays high for all subsequent hops. That spike points to where the slowdown is occurring.

If latency spikes at one hop but then drops back down at the next, the spike was in how that router handles traceroute probes, not in the actual data path. Some routers deprioritize responding to diagnostic packets while passing regular traffic through normally.

Asterisks: `* * *`

A line of asterisks means the router at that hop didn’t send back a reply within the timeout. Three causes:

Firewall blocking ICMP: many routers, especially on corporate and carrier networks, are configured to drop traceroute probes silently. This is the most common reason.
Rate limiting: the router responded to some probes but not all. You might see * 14ms * for a partial response.
Actual packet loss: the link between hops has real problems.

The key test is what happens after the asterisks. If the route continues and reaches the destination, the asterisks are almost certainly a firewall configuration, not a real problem. If the route stops at the asterisks and never reaches the destination, there’s a real break at that point.

Reading a complete example

 1  192.168.1.1          2 ms    2 ms    1 ms    ← your home router, healthy
 2  10.20.30.1           11 ms  10 ms   10 ms    ← ISP's first hop, normal
 3  * * *                                        ← silent hop, probably a firewall
 4  68.86.90.34          14 ms  13 ms   13 ms    ← route continues, hop 3 was just a firewall
 5  96.110.40.1          15 ms  15 ms   15 ms
 6  96.110.40.2         180 ms 178 ms  179 ms    ← latency jumps here, bottleneck at this link
 7  162.151.77.10       182 ms 181 ms  180 ms    ← stays high from here on
 8  destination         184 ms 183 ms  182 ms

In this trace: hops 1-5 are healthy, the silent hop 3 is a firewall (route continues fine), and hop 6 is where something slowed down. The problem is at or before hop 6.

Common patterns and what they mean

Consistently high latency from hop 1: your home router is the bottleneck. This happens with overloaded older routers, routers running too many clients simultaneously, or routers with hardware issues. Rebooting sometimes helps; replacing old hardware is a more lasting fix.

Latency spikes on hops 2-4: your ISP’s local infrastructure is congested. This commonly appears in the evenings during peak hours in residential areas. You can try calling your ISP to report it, but there’s often nothing to do except wait.

One hop with high latency, subsequent hops normal: that router deprioritizes ICMP responses. The real data path through it is probably fine. Don’t act on this unless the destination also shows high latency.

Latency jumps sharply and stays high: this is the real signal. Find the hop where it jumps and that’s the bottleneck. If it’s hops 1-2, it’s your local network. If it’s hops 3-5, it’s your ISP. If it’s hop 8 or later, it’s out of your hands.

Route goes through unexpected geography: a connection to a nearby server might route through another region or even another continent. This can add significant latency. Internet routing is controlled by routing tables that optimize for cost and peering agreements, not necessarily for physical proximity. If you see a connection to a datacenter 50 miles away routing through Europe, that’s a routing table misconfiguration somewhere.

Packets never reach the destination: the route stops entirely. Either the destination is down, there’s an outage on a link between you and it, or a firewall is blocking your probes from getting through. Try ping to the same destination to see if ICMP at least gets a reply.

Running traceroute on Mac without Terminal

If you’d rather not work in Terminal, NetUtil includes a traceroute tool with a table-based interface. Enter a hostname and click Trace. Results appear hop by hop in a structured table with columns for hop number, hostname, IP address, and the three timing values.

Apple used to include this in Network Utility, a built-in app with a graphical traceroute tab. Network Utility was removed in macOS Monterey. NetUtil is a free replacement that covers traceroute along with ping, DNS lookup, port scanning, and other diagnostics.

The practical advantage of a GUI over Terminal output isn’t just aesthetics. When you’re comparing two traces run minutes apart, having them in separate windows with the same column layout makes differences easier to see. High-latency hops stand out without scanning through raw text.

Everything runs locally on your Mac. Traceroute probes go directly from your machine to the target without passing through any third-party servers.

What to do with what you find

Traceroute diagnoses but doesn’t fix. What you learn determines what to do next.

Problem on hops 1-2 (your local network): reboot your router. Check if the problem appears on other devices on your network. If it’s one device, check that device’s network configuration. If it’s all devices, the router is the issue.

Problem on hops 3-5 (your ISP): call support with the traceroute output. Knowing which hop is slow gives the support team something concrete to look at. Ask specifically about congestion or issues at that IP address.

Problem beyond your ISP: if the slow hop is far down the chain, it’s likely on backbone networks or the destination’s infrastructure. There’s usually nothing actionable on your end. Wait and check again later, or try routing through a VPN to see if a different path avoids the bottleneck.

Can’t reach destination at all: check if the site is down for everyone using a service like downdetector.com. If it’s not a general outage, try from a different network (like your phone’s LTE) to determine if the problem is specific to your connection or more widespread.

The next time something feels slow, run a traceroute before assuming the worst. It takes about 30 seconds and tells you immediately whether the problem is something you can fix or something you just have to wait out.