What a Traceroute Shows Before and After You Connect
A traceroute reveals the sequence of routers your traffic passes through on the way to a destination. Run it without a VPN and the first hops are your own router and your internet provider’s network. Run it with the tunnel up and the early hops collapse into the tunnel — you see your device, then the VPN server, then the provider’s onward network.
It is the most direct way to see that a tunnel is actually carrying your traffic, and it costs nothing but a command.
What the tool is doing
It exploits the mechanism that stops packets circulating forever. Every packet carries a counter that each router decrements. When the counter hits zero, the router discards the packet and sends back an error saying so — and that error identifies the router.
A traceroute sends packets with the counter set to one, then two, then three, and collects the error messages. Each one names the router at that distance. The result is an ordered list of the hops between you and the destination.
Three consequences worth knowing. Hops that decline to send errors show as timeouts, which is a configuration choice rather than a fault. Different tools use different packet types, and networks treat those differently, so two tools can produce different pictures of the same path. And the return path is not necessarily the same as the outbound one, so what you see is one direction only.
The shape of a normal result
Without a VPN, the hops fall into recognisable groups.
The first hop is your own router — its private address, matching the gateway in your network settings. If your first hop is something else, or absent, that alone is informative.
The next few belong to your internet provider: often addresses with reverse names identifying the provider and sometimes a city or facility. If you are behind carrier-grade NAT, you may see a 100.64.-range address here, which is a quiet confirmation of carrier NAT.
Then come interconnection points and transit networks, and finally the destination’s own network. Reverse names along the way often reveal which organisations the traffic crossed — the kind of reading discussed in what an ASN and reverse DNS reveal.
The shape with a VPN connected
The early hops disappear, because they are inside the tunnel.
Your traffic is encrypted and handed to the VPN server as a single connection, so the routers in between never see the inner packets and never generate errors about them. What you see instead is typically the tunnel’s local endpoint, then the VPN server, then the network beyond it.
That collapse is the confirmation you are looking for. Your provider’s hops should not appear. If they do, traffic to that destination is not going through the tunnel, which is a routing problem worth investigating even if the app reports a healthy connection.
The hops after the VPN server tell you where the server actually sits on the network, which is sometimes not where its advertised location suggests. Reverse names on the onward hops are a fair indication of the hosting network in use.
What it is good for
Four questions it answers well.
Is the tunnel carrying this traffic? The clearest test there is. Run it to any destination and look at whether your provider’s hops appear.
Is split tunnelling doing what I configured? Trace to a destination you routed inside the tunnel and one you routed outside. Two different shapes means split tunnelling is working; two identical ones means it is not.
Where does the path fail? If a destination is unreachable, the last hop that responded tells you roughly where the problem lies — your network, your provider, or somewhere further out. Useful groundwork before concluding the VPN is broken.
Why does a connection feel slow? A path that goes a long way round before reaching a nearby destination explains latency that otherwise seems inexplicable, and choosing a differently located server sometimes shortens it.
How to read it without over-reading it
Traceroutes invite misinterpretation, and a few rules keep it honest.
Timeouts in the middle are usually fine. A router that does not respond to these packets still forwards traffic. If later hops respond, the path is intact. Only a run of timeouts continuing to the end suggests a real failure.
Latency to a single hop is not the latency of the path. Routers give low priority to generating these errors, so a middle hop can look terrible while traffic through it is fine. What matters is the trend across hops and the figure at the destination.
Latency does not always increase monotonically. Later hops sometimes report lower times than earlier ones, which is a scheduling artefact, not a paradox.
Geography from reverse names is a guess. Airport codes and city names in hop names are conventions, not guarantees, and they are frequently stale.
A single run proves little. Paths shift, and one unusual result is worth repeating before drawing conclusions.
Running it
Every platform ships something suitable. Windows has tracert, macOS and Linux have traceroute, and there are variants that use different packet types where the default is filtered. On mobile you generally need an app.
Two habits that make results comparable:
Record a baseline. Trace to a destination you use often, with and without the VPN, while everything is working. Later runs are then a comparison rather than an interpretation.
Trace to something simple. Large services sit behind address ranges that vary by lookup, so the destination may differ between runs. Something with a stable address gives a more consistent picture, and clearing cached lookups first removes another source of variation — the reason behind flushing the DNS cache before comparative tests.
Why it is worth learning
Most VPN troubleshooting is guessing about invisible routing. A traceroute makes the routing visible, in one command, with no software to install.
It will not tell you whether your lookups are leaking or whether the encryption is sound. But it answers the foundational question — is my traffic going where I think it is — and that question is behind more confused VPN problems than any other.