Visual Traceroute: Map Your Network Path from iPhone

By Paul Snyman · Published August 28, 2026 · 8 min read

A normal traceroute gives you a column of IP addresses and numbers. It tells you the truth, but you have to already know how to read it. A visual traceroute plots those same hops on a map, and suddenly "why is this slow" often answers itself: you can see the traffic cross an ocean.

This covers what a traceroute actually measures, what the map can and cannot tell you, and how to read one without drawing the wrong conclusion.

What traceroute measures

Your traffic does not go straight to its destination. It passes through routers: your own, your ISP's, one or more intermediate networks, and finally the destination's. Each of those is a hop.

Traceroute maps them with a trick. Every packet carries a hop limit, a counter decremented by each router it passes. When it hits zero the router discards the packet and sends back an error, which reveals that router's address. So traceroute sends a packet with a limit of 1, and the first router answers. Then 2, and the second answers. Repeat, and you have the path.

Each hop gives you two things: the address of the router that replied, and how long the round trip took.

What the map adds

Every hop address can be looked up in a geolocation database, which returns an approximate city and country, plus the network that owns the address. Plotted in order, that turns a list into a route.

PingKit's Traceroute resolves each hop to a city and country, the ISP or network operator, and the autonomous system, the identifier for the network the router belongs to. Those get drawn on a map in sequence.

What that makes obvious at a glance:

• Where your traffic physically goes. A service that feels local may be answered from another continent.
• Where the latency appears. A jump from 20 ms to 160 ms between two hops is where the distance or the congestion is.
• Whose network you are on at each stage. Useful for knowing whether a problem is your ISP's or somewhere past their border.
• Whether a VPN is doing something strange. Routing to a nearby site by way of a different country is a common and rarely noticed cost.

One thing to be clear about: hops have no names

Traditional traceroute output often shows names like ae-1-3502.ear2.London1.example.net, produced by a reverse lookup on each address. Operators frequently encode the city and link type in those names, and experienced people read them like a map.

PingKit does not do reverse lookups on hops. Each hop is an address, a latency and a geolocation result, and nothing else. That is a real difference from desktop tools, and worth stating plainly rather than letting a screenshot imply otherwise. The geolocation covers most of what those names would have told you, with the caveat below.

How to read the map without fooling yourself

Latency only goes up, and that is normal

Each hop is further away, so times rise along the path. What matters is not the final number but where it jumps. Twelve hops climbing gently from 8 ms to 90 ms is a healthy route. Six hops at 15 ms followed by one at 210 ms means something happened at that step.

A slow hop in the middle is often nothing

This one trips up almost everyone. Routers treat these error replies as their lowest priority. A busy router will forward your real traffic instantly while taking 300 ms to answer traceroute. If hop 5 looks terrible but hops 6 through 12 are fine, hop 5 is not your problem. Traffic clearly passed through it without difficulty.

The rule: a slow hop only matters if every hop after it is also slow.

Missing hops are usually deliberate

Stars or blanks mean a router chose not to reply, which many are configured to do. As long as later hops answer, the path is fine and one router simply declined to identify itself.

The geolocation is approximate

IP geolocation is inference from registration records and routing data, not a GPS fix. Accuracy is usually good at country level, decent at city level, and sometimes wrong. Addresses registered to a company headquarters can place a router in the wrong city entirely. Treat the map as a strong indication of the route's shape, not as surveyed coordinates.

What it is genuinely good for

Telling local problems from distant ones

If hop 1, your own router, is already slow or erratic, stop reading the rest. The problem is inside your house and a Connection Monitor run will tell you more. If your first few hops are clean and it degrades six hops out on another continent, there is nothing at your end to fix.

Understanding why a specific site is slow

A game server or website that feels sluggish while everything else is fine usually has a route explanation. Seeing the traffic leave your country and come back, or take an indirect path, explains a latency figure that otherwise looks arbitrary.

Checking what a VPN actually does

Run a traceroute to the same destination with the VPN on and off. The two maps make the added distance concrete, which is often more persuasive than a latency number on its own.

Making a case to your ISP

"The internet is slow" gets a router reboot suggestion. A traceroute showing latency climbing sharply at a specific hop inside your ISP's own network, repeated at the same time of day, is a different conversation. PingKit keeps unlimited history and exports to CSV, JSON or PDF free, so you can show a pattern rather than a single bad run.

Running one properly

1. Pick a destination that matters. Trace the actual slow service, not a generic address, since routes differ per destination.
2. Run it more than once. Routes change and a single run can catch a transient.
3. Run a comparison. Trace something known-good alongside it. If both degrade at the same hop, that hop is your bottleneck for everything.
4. Note the time. Congestion has a schedule, so a route that is fine at 3pm and bad at 9pm points at load rather than a fault.
5. Read it in order: your router first, then your ISP, then everything past their border, which is not theirs to fix.

Traceroute, ping and MTR

Ping tells you there is a problem. Traceroute tells you roughly where. MTR keeps testing every hop continuously, which is what catches a hop that fails one time in twenty, the kind of fault a single traceroute will usually walk straight past.

Frequently asked questions

What is a visual traceroute?

A traceroute that plots each hop on a map instead of only listing addresses. Each hop's address is resolved to an approximate city and network operator, so you can see the physical shape of the route.

Why does one hop show huge latency but the rest are fine?

Because routers treat traceroute replies as their lowest priority. A busy router forwards real traffic immediately while responding slowly to the probe. If the hops after it are fast, that hop is not your problem. A slow hop only matters when everything after it is slow too.

How accurate is traceroute geolocation?

Good at country level, reasonable at city level, occasionally wrong. It is inferred from registration and routing data rather than measured, so an address registered to a head office can place a router in the wrong city. Read the route's shape, not the exact pins.

Why do some hops show no address at all?

Many routers are configured not to reply to traceroute. A blank hop is usually a deliberate configuration rather than a fault, and as long as later hops respond the path is working.

Can I run traceroute on an iPhone?

Yes. iOS does not restrict it the way it restricts WiFi scanning, so a traceroute from an iPhone gives the same path information a desktop would, along with per-hop geolocation.