Your ping reads 25 ms in the lobby and 90 ms once the match starts. You fire, the server disagrees, and you rubber-band three metres backwards. Neither the in-game counter nor a speed test tells you where those milliseconds go. Between your machine and the game server sit your home router, your ISP, one or two transit networks and the host's own network. The delay, and the jitter behind lag spikes, comes from one of them.
A visual traceroute shows each of those hops on a map, with its latency, jitter and packet loss, and names the network that owns it. That tells you whether the culprit is your Wi-Fi, your ISP's congestion at peak hours, a poor peering between your ISP and the host, or simply a server region that is too far away. A traceroute does not lower your ping by itself; it tells you which fix is worth trying, and gives you proof when you talk to your ISP.
Find the hop that adds the latency
Trace to the server address, taken from the game's logs or your platform's server list, with 30 to 40 hops maximum. Read latency from the first hop to the last and look for the first jump that stays high afterwards. Hop 1 is your router: above 5 ms on Ethernet, or above 20 ms with visible jitter, means the problem is inside your home, usually Wi-Fi. Hops 2 to 4 belong to your ISP; a jump there at 9 pm that vanishes at 8 am is peak-hour congestion. A jump exactly where the ASN column changes is the handoff between your ISP and a transit carrier or the host. A steady 40 ms from the ASN change to the end is distance, and the answer is another region.
Jitter and loss, not average ping, cause rubber-banding
A 60 ms ping with 2 ms of jitter feels smooth; 40 ms with 30 ms of jitter feels broken, because the game predicts your position between packets and corrects it when they arrive late. Read the jitter column hop by hop: the first hop where it climbs is your unstable segment. Loss works the same way, with one trap. A middle hop showing 20% loss while the destination shows 0% is a router deprioritising traceroute replies, not lost game packets. Real loss starts at one hop and persists to the last. Run the trace at peak time and off-peak and compare the two side by side; the difference tells you whether you are facing congestion or a permanent path problem.
Wired versus Wi-Fi, region choice, and what to send your ISP
Trace once on Wi-Fi and once on Ethernet, same target, and compare. If hop 1 jitter drops from 15 ms to under 1 ms, you have your answer: no router setting beats a cable. Then trace to two or three server regions: the game's region list rarely reflects your real path, and a nearer region can route through a distant exchange. If the delay appears at your ISP's hops or at their handoff, run the same trace from a Globalping probe on another network in your country and export both. Same target, different network, half the ping: an argument your provider cannot dismiss. A VPN is worth a test when the issue is peering, since it changes where your traffic is handed over; it does nothing against distance or Wi-Fi.
Reading a trace: a match that lags every evening
A teaching example, not a real measurement. A player in Lyon traces to a server in Frankfurt. Hop 1, the home router, answers in 1 ms with no jitter. Hops 2 to 4, in the ISP's network, sit at 8 to 11 ms. At hop 5 the ASN changes to a transit carrier: 14 ms. Hop 6 reads 68 ms with 25 ms of jitter, and every hop up to the server stays near 70 ms. The jump persists to the end, so it is real, and it starts right after the handoff: the weak link is between that carrier and the host, not at home. The same trace at 7 am shows 18 ms end to end: peak-hour congestion. Options: a region served by another carrier, a VPN test, or an ISP ticket with both traces attached.
Tools to use before and after the trace
Ping sends a burst of probes and reports minimum, average, jitter and loss; use it first to confirm the spike is happening right now, then trace. DNS Lookup tells you which address the game's hostname resolves to, since some games use different addresses per region. WHOIS and IP Reputation identify who owns a server address, useful when a community server turns out to be hosted on another continent. Port Check confirms a game port is reachable when a firewall or CGNAT is suspected.
Frequently asked questions
- Can a traceroute lower my ping?
- No. It measures the path; it does not change it. What it gives you is the segment that adds the delay, so you fix the right thing: swap Wi-Fi for Ethernet if hop 1 is unstable, pick a server region with a cleaner path, test a VPN if the problem sits at a peering handoff, or send your ISP proof when the congestion is on their side.
- The game shows 30 ms but some hops show 60 ms. Which is right?
- Both can be. The in-game counter measures the round trip to the server on the game's own protocol. Traceroute measures each intermediate router, and routers often answer slowly because they deprioritise that kind of traffic. Only the last hop reflects your real ping, and only a delay that persists from one hop to the destination is real. Try TCP or UDP mode if ICMP looks unusual.
- I am behind CGNAT. Does it change how I read the trace?
- With carrier-grade NAT your ISP shares one public address between several customers, so hop 2 or 3 often shows a private address in the 100.64.0.0/10 range inside the ISP network. It adds little latency by itself, but it prevents hosting a server at home and can make Port Check report your port as closed or filtered. The rest of the path reads normally.