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 traceroute shows each of those hops with its latency, jitter and packet loss, and names the network that owns it. Run from your own PC (tracert on Windows, mtr on macOS or Linux), it shows your line: your Wi-Fi, your ISP. TraceMapper runs it from our servers in Germany and France or from probes in 30+ cities: the path to the game server seen from outside your home, on a map. Side by side, the two tell you whether the delay is on your side, at a peering point or at the host. A traceroute does not lower your ping by itself; it tells you which fix is worth trying.
Find the hop that adds the latency
Run tracert or mtr from your PC to the server's address (from the game's logs or your platform's server list) and read the latency from the first hop to the last: 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, 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 changes is the handoff to a transit carrier or to the host. A steady 40 ms from the ASN change to the end is distance, and the answer is another region. A TraceMapper trace starts in our datacenter or at a probe: its first hops are not yours, so read it from the first change of network.
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.
Wi-Fi or cable, region choice, and the proof to send
Run tracert once on Wi-Fi and once on a cable, same target, and compare: if hop 1 jitter drops from 15 ms to under 1 ms, no router setting beats a cable. Then trace two or three server regions in TraceMapper from the probe closest to you: the game's region list rarely reflects the real path, and a nearer region can route through a distant exchange. If your own tracert degrades from your ISP's hops while TraceMapper's path from a probe in your country stays clean, the problem is on your line: export the TraceMapper trace (a dated PDF) and attach your tracert to the ticket. If both degrade at the same distant hop, it is beyond your ISP. 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 runs tracert 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. A TraceMapper trace to the same server from a probe in Paris reaches it in 12 ms through another carrier: the server is fine, the weak link is the carrier the player's ISP hands traffic to. The same tracert at 7 am shows 18 ms: 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.