Visual Traceroute for iPhone

How PingKit's Traceroute Works

PingKit performs a genuine ICMP-based traceroute directly from your iPhone. It sends packets with incrementing time-to-live (TTL) values, causing each router along the path to reveal itself. Unlike web-based traceroute tools that run from a remote server, PingKit traces the actual route from your device on your network, showing you exactly what your traffic experiences.

When Traceroute Solves the Problem

Diagnosing Slow Routes

Your speed test looks fine, but a particular website or game server feels slow. A traceroute reveals whether your traffic is taking a detour - routing through a distant city or congested exchange point instead of a direct path. Once you know where the delay is, you know whether it is something your ISP can fix or an upstream routing issue beyond their control.

Finding ISP Routing Issues

If latency spikes at your ISP's first few hops, the problem is on their network. If it spikes at a peering point where your ISP hands traffic to another network, it may be a capacity issue between providers. PingKit's visual map makes these handoff points obvious - you can literally see where your data crosses from one network to another.

Visualizing CDN Paths

Content delivery networks serve data from edge servers near you. A traceroute shows whether you are actually hitting a nearby CDN node or being routed to one far away. If a streaming service feels slow despite good bandwidth, a traceroute to the CDN hostname might reveal your ISP is routing you to a distant server when a closer one exists.

Educational Use

Traceroute makes the invisible internet visible. Watch your data hop from your router to your ISP, across undersea cables, through internet exchange points, and into a data center. It is a powerful way to understand how the internet actually works, not just as an abstraction but as a physical network of connected routers spanning the globe.

How the Trace Runs

PingKit sends an ICMP echo request with a time-to-live of 1^[source]. The first router decrements it to zero, gives up, and replies to say so, which is how it reveals itself. Then TTL 2, and so on, up to thirty hops. Each probe waits up to two seconds.

One detail separates this from the simplest implementation: a hop that times out is probed a second time before being written off. A single dropped echo is common and means very little, and without the retry an otherwise healthy router shows as a row of asterisks purely by chance. The trace stops early when the destination itself answers, or after five silent hops in a row, so a path that ends behind a firewall does not cost you twenty-five pointless timeouts.

When the walk finishes, PingKit looks up the addresses it collected to find where they are. Those lookups happen after the trace rather than during it, deduplicated so an address appearing twice is fetched once, and spaced out to stay inside the geolocation service's rate limits. That is why the route appears first and the cities fill in a moment later.

Private addresses are never looked up. Hops inside your own network, your router and anything between it and your ISP, are filtered out before any lookup is made, so the addresses of your own equipment are never sent to a geolocation service. It is also why the first hop or two never has a city attached.

What the Map Shows, and What It Leaves Out

The map draws the hops that geolocation could place, joined into a route in order. A marker carries the hop number and the country flag underneath it, coloured by round-trip time: green under 50 ms, orange under 150, red above that, and orange for a hop that timed out. Tap one and a card gives you the address, the location, the latency, the AS number and the organisation that operates it.

Two things are deliberately absent from the map, and knowing which is which saves confusion.

Hops that never answered have no address, so there is nothing to look up and nothing to place. They still appear in the list with asterisks; they are simply not on the map.

Hops on private addresses are excluded on purpose, as above. Your router is a real hop and it is genuinely part of the path, but it is not going in a geolocation database, and no lookup of its address is ever made.

There is one piece of honest cosmetic trickery. Several consecutive hops frequently sit in the same data centre, which would stack their pins into one unreadable blob. PingKit fans them out in a small circle, about sixteen kilometres across, so each stays tappable. The route line therefore shows a tiny loop where the real path went straight. That is the drawing, not the network.

Treat the geography as approximate throughout. Hop locations come from the same databases as any IP lookup, which are dependable about the country and the network operator and much less so about the city. The IP Geolocation page covers exactly how far to trust them.

Reading a Traceroute Without Fooling Yourself

Most traceroute confusion comes from expecting it to behave like a measurement of your traffic. It is not. Each row is a separate reply generated by a router that was doing you a favour.

Latency that jumps at one hop and drops at the next is not a problem. The reply to a TTL expiry is generated by the router's own processor, which is the slowest, least important thing it does. A busy core router will happily forward your traffic at full speed while taking 200 ms to answer a probe about it. Only a rise that persists to the destination is real added delay.

Asterisks are usually policy, not failure. A router configured not to answer ICMP is invisible to the trace and completely functional. If the hops after it answer, the path through it is fine. A run of asterisks all the way to the end is different, and usually means the far network drops these probes at its edge.

The path is one direction only. You are seeing the route out. The return path can be, and often is, completely different, and traceroute cannot show it. An asymmetry like that is a normal consequence of how networks choose routes, and it is why a hop can look fine here while the return leg is where the delay lives.

The route changes. Run the same trace twice and you may get different hops. Load balancing across parallel links is routine, and it means a single trace is a snapshot rather than a fact about the path.

Where a delay first appears matters more than its size. A jump within your ISP's first few hops is theirs. A jump at the point where one network hands off to another is a peering issue between two companies, and is usually visible on the map as the moment the route crosses a border or an ocean. A jump in the last hop or two is the destination.

Explain This Result, in Plain Language

A finished trace is a column of numbered addresses and millisecond figures, the clearest case in the app of a result that tells an expert everything and a non-expert nothing. Under the summary of every completed run there is a button marked Explain This Result. Tap it and PingKit hands the hop list to a language model and gets a few sentences back. The questions the section above answers by hand, where a delay first appears and whether a run of asterisks matters, are the ones it is there for.

It only runs when you tap it. Nothing is generated on its own, for subscribers either.

The answer is written on the iPhone first. PingKit tries the on-device model before anything else, and when that answers, the trace never leaves the phone. If the device cannot answer, the request moves up a rung: Apple's Private Cloud Compute, which unlocks with a PingKit Guardian subscription, then PingKit's own service, which asks your permission the first time. What is sent then is the result text already on screen, the same hop lines the app produces when you share a trace. That list includes your router and any other hop inside your own network: those addresses are still never sent to a geolocation service, as above, but they are part of what an off-device rung is asked to explain. Every answer is captioned with which of the three wrote it.

It costs nothing. Without a subscription you get fifteen AI answers a week, no more than five in a day, shared across every AI feature in PingKit, and an answer the on-device model writes does not count against that. The same button sits under eighteen results, from Ping and Speed Test to DNS Lookup and the Devices tab. It is an iPhone and iPad feature; the Mac Agent does not have it.

PingKit vs Other Traceroute Tools

The important distinction is not features, it is where the trace starts.

Web-based traceroute runs from the operator's server, so it traces the path from a data centre to your target. That is a real path and it is not yours. When a site is slow for you and a web tool shows a clean route, the two results are not in conflict; they are about different journeys. PingKit traces from the phone, on the network you are actually complaining about.

Where a desktop traceroute still wins is control: three probes per hop by default, a choice of UDP, TCP or ICMP, and IPv6. PingKit is ICMP and IPv4. For the question people actually have, which is where their own connection slows down and whether it is their ISP's fault, tracing from the device that has the problem matters more than any of that.

Beyond Basic Traceroute

PingKit's traceroute is just the starting point. If you spot a problematic hop, switch to MTR to monitor it continuously and confirm whether the issue is persistent or intermittent. Use the Ping tool to measure baseline latency to your destination. And if you suspect a broader network problem, Smart Diagnostics ties everything together with an automated analysis and plain-language recommendations.

Questions and answers

Can I run a traceroute on iPhone?

Yes. PingKit runs a real ICMP traceroute on the device itself, over the unprivileged datagram ICMP socket Apple permits, so there is no jailbreak and no remote server running the trace on your behalf. It probes up to 30 hops, raising the TTL by one each time so each router in turn has to announce itself, and re-probes a hop once before recording it as a timeout. When the trace finishes, View Visual Route plots the hops that geolocated onto a map.

What does a traceroute show you?

Every router your packets pass through on the way to the destination, in order. Each hop that answers gives you its IP address, its round-trip time and, for public addresses, the city and country it geolocates to plus the AS number and the organisation operating it, which is how you see the point where your traffic leaves your ISP. Hops are identified by IP address only: PingKit does not perform a reverse-DNS lookup, so there are no router hostnames to read.

What is the difference between traceroute and MTR?

A traceroute is a single pass: it probes each hop, prints the route and stops. MTR keeps going until you stop it, re-probing every hop cycle after cycle and accumulating statistics, so each hop carries a loss percentage and its best, average and worst latency, beside a running count of the cycles completed. That is the difference that matters in practice, because loss that happens one time in twenty is invisible to a single pass. Both tools are free.

Why do some hops show asterisks or no response?

Because that router did not send back the ICMP Time Exceeded message the probe depends on, which plenty of routers suppress or rate-limit deliberately. PingKit probes each hop twice before giving up on it and then shows the hop as "* * *", so one dropped packet is not enough to produce one. It is not a fault in itself: if the hops on either side answer with sane latency, traffic is passing through that router perfectly well. A trace stops early after five silent hops in a row, and the destination itself often declines to reply.

How do I use traceroute to diagnose slow internet?

Run the trace to the host that feels slow, then look for the point where latency steps up and stays up for every hop after it. A single hop reading high while the ones behind it read normally is usually a busy router deprioritising your probe rather than a real delay, and that is the most common misreading of a traceroute. Once you have found a genuine step, the AS number and organisation shown on that hop tell you whose network it happened on, which is what decides whether your ISP can do anything about it. To find out whether it is constant or intermittent, switch to MTR and let it run.