What Is Packet Loss? Causes, Symptoms and How to Fix It for Gaming

Everything your computer sends across the internet is chopped into small, individually addressed units called packets. A single movement update in a shooter might be a few dozen bytes; a voice transmission is a steady stream of small packets; a game patch is millions of them. Each packet travels independently, is handed from router to router, and is reassembled or interpreted at the far end.

Packet loss is the proportion of those packets that never arrive. It is expressed as a percentage of a sample — 0% over a thousand packets means every one was delivered, 2% means twenty went missing. Nothing about the internet guarantees delivery at the packet level. Routers are permitted to discard packets when a queue is full, when a link is degraded, or when a device decides some traffic matters less than other traffic. That is not a bug; it is the design, and higher layers of software are expected to cope with it.

The reason packet loss matters so much more in games than in the rest of your internet use is that games choose not to cope with it in the usual way. A web page that loses a packet simply waits a few milliseconds for a copy. A game cannot afford to wait, because by the time the copy arrives the moment it described is already in the past.

When your game has something to tell the server — you moved, you fired, you changed weapon — it builds a small message, wraps it in addressing information, and hands it to your operating system. Your network adapter puts it on the wire or into the air. Your router forwards it to your ISP. From there it crosses a sequence of routers, each of which reads the destination address, consults its routing table, and passes the packet to the next device it believes is closer to the target.

No single device is responsible for the whole journey, and no device holds a copy once it has forwarded the packet on. Each hop has finite capacity: an input queue, an output queue and a scheduling policy. When a queue is full, the router has exactly two options — delay the packet or discard it. Both happen constantly across the internet, and both are invisible to you unless you measure them.

The behaviour that follows a discard depends on which transport protocol is in use. TCP, which carries web pages, downloads and most of the launcher and matchmaking traffic around a game, is reliable and ordered. The receiver acknowledges what it has received; the sender notices a missing acknowledgement, waits for a retransmission timeout or infers loss from duplicate acknowledgements, and resends the data. Nothing is ever lost from a TCP stream — but everything queued behind the missing segment waits for it, which is why a lossy connection makes a download feel like it stalls in bursts.

UDP, which carries the actual gameplay traffic in almost every real-time title, makes no such promises. There are no acknowledgements, no ordering guarantees and no retransmission. If a datagram is dropped, it is gone. That sounds worse and is usually better: a positional update from 80 ms ago has no value once a newer one exists, so resending it would waste time and bandwidth to deliver stale information.

In practice most engines run a hybrid. Critical events — you picked up an item, the round ended, you died — are sent with a lightweight reliability layer built on top of UDP, so they are acknowledged and resent if necessary. High-frequency positional state is sent unreliably, because the next update supersedes it anyway. This is why loss can affect games so unevenly: two titles on the same connection with the same loss percentage can feel completely different depending on how much of their traffic is protected and how aggressively they predict.

It also explains a pattern many players notice. Voice chat degrades before movement does, because a codec has no way to invent the missing audio. Movement degrades before scoreboards do, because scoreboards are reliable traffic that simply arrives a moment late. The same underlying loss produces different symptoms in different subsystems.

Packet loss rarely announces itself. Games are deliberately built to conceal it, and they succeed often enough that players attribute the residue to their own reactions, their hardware, or the other player's connection. The signatures below are the ones worth taking seriously — with the caveat that every one of them has more than one possible cause.

A useful discipline: separate what happens on your screen from what happens in the world. If your character animates smoothly and the world does not respond, that points at outbound loss. If your own actions land reliably and other players behave erratically, that points at inbound loss or at their connection. If everything is uniformly late but consistent, you are looking at latency, not loss — and the guide for that is why is my ping so high.

Every cause of packet loss sits in one of three zones, and knowing which zone you are in determines everything about what to do next. In our experience of reader reports, the great majority of gaming packet loss originates in the first zone — the part players control and rarely test properly.

Local network. Wi-Fi is the dominant cause. A wireless link shares airtime with every neighbouring network on the same channel, retransmits corrupted frames automatically, and gives up when retransmission fails. Interference from other 2.4 GHz devices, distance from the access point, walls, and the sheer density of networks in apartment buildings all reduce delivery reliability in ways no speed test will reveal. Beyond Wi-Fi: damaged or cheap Ethernet cabling, a failing port, an overheating or long-uptime router with an exhausted connection table, saturated uploads from cloud sync or streaming, and network adapter drivers with aggressive power management.

ISP and routing. Beyond your router, capacity is shared with everyone around you. Local access networks are contended, and evening peaks can push a segment past the point where queues absorb the load. Further out, your ISP hands your traffic to other networks at peering points and via transit providers; an under-provisioned interconnect drops packets exactly when everybody wants to use it. Routing changes can move your traffic onto a longer or busier path overnight with no warning. And some loss is a plain line fault — water in a joint, a degraded drop cable, a failing line card — which no configuration change will address.

Server side. Your packets can arrive at the destination network and still not be processed. An overloaded game server, a datacentre incident, or DDoS mitigation filtering traffic during an attack all produce behaviour indistinguishable from network loss on your side. The distinguishing evidence is other players: if the whole lobby is affected simultaneously and your own path measurements look unremarkable, the problem is not yours.

These three metrics are routinely used interchangeably and are not interchangeable at all. They describe different failures, are measured differently, and have different fixes. A connection can be excellent on two of them and unusable on the third.

The reason this distinction matters commercially as well as technically is that products are sold against latency while most complaints are actually about loss and jitter. A shorter path genuinely reduces latency. Whether it reduces loss depends entirely on where the loss is happening — which is the subject of the rest of this article. Jitter has its own full treatment in what is jitter.

Testing badly is worse than not testing, because it produces confident conclusions from insufficient data. Four ping packets to a search engine at midday tells you nothing about your evening experience against a game server three networks away. The principles below matter more than the specific tool.

Start with the game's own network statistics. Most competitive titles expose a netgraph or connection overlay showing loss percentage against the actual server you are connected to. This is the most relevant measurement available, because it counts the real traffic on the real path. Its weakness is that it disappears when you leave the match, so record what you see.

Run a sustained ping, not a default one. A continuous test of several hundred packets against a stable address in the region you play in will report loss alongside minimum, average and maximum round-trip time. On Windows this means adding a count or continuous flag to the ping command; on macOS and Linux the default is already continuous. Let it run for at least ten minutes, and let it run while you are actually playing.

Use a trace to localise it. A traceroute shows the sequence of routers between you and the destination. It is a snapshot, and a snapshot is not enough to judge loss, but it tells you the shape of the path and where the latency steps occur. Our walkthrough is how to run a traceroute for gaming.

Use a per-hop loss tool for evidence. Windows includes pathping, which sends many probes to every hop and reports loss per hop; MTR is the equivalent on macOS and Linux and is what most network engineers will ask for. These are the tools that turn "my game feels bad" into something an ISP can act on, because they show where loss begins and whether it persists.

Check the router's own diagnostics. Most routers expose error counters, line statistics and wireless retry rates. Rising error counts, a poor signal-to-noise margin, or a high wireless retransmission rate localise the problem immediately, before you touch anything else.

Raw numbers mislead more often than they inform. What matters is the pattern: where the loss starts, whether it continues, when it appears, and what else was happening at the time.

Loss at the first hop — your own router — is unambiguous. Nothing outside your home is involved, so the cause is Wi-Fi, cabling, a port, the router itself, or local saturation. This is good news: it is the cheapest category to fix.

Loss at an intermediate hop only, with clean hops after it, is the single most misread result in networking. Routers commonly deprioritise or rate-limit packets addressed to themselves in favour of forwarding real traffic, so a hop can report 100% loss while passing your game data flawlessly. If the destination is clean, the path is fine.

Loss that begins at a hop and continues to the destination is the pattern that matters. That is consistent with a genuine problem at or beyond that point, and it is the evidence worth collecting and escalating. Even then, confirm it across multiple runs at different times before drawing conclusions.

Loss only at the final destination can mean the server is dropping or filtering probes rather than losing your game traffic. Many game servers do not respond to ICMP at all. Prefer the in-game loss counter over a ping to the server address when they disagree.

Intermittent versus persistent loss points at different causes. Bursts that correlate with the evening, or with someone else in the house doing something, are congestion. Steady, unchanging loss regardless of time or load is more consistent with a hardware or line fault. Weather-correlated loss on a copper line is a classic physical fault signature.

Upstream versus downstream is worth separating. Upload capacity is typically far smaller than download capacity, so a single cloud backup or stream can saturate it while a speed test still reports a fast connection. Loss that appears whenever you upload anything, and vanishes when you stop, is your own line — and queue management, not more bandwidth, is the fix. Bufferbloat is the related phenomenon and is covered in the advanced bufferbloat guide.

Work through these in order. Each question eliminates an entire zone, which is what stops you replacing hardware or buying software for a problem in a different layer.

If you prefer a lookup table to a sequence, the pattern you are seeing is probably in the list below, along with the test that confirms it and the action that follows.

Ordered by how often each one resolves the problem in practice, and free before paid. Re-measure after every step; a fix you cannot demonstrate is a fix you cannot trust.

Two notes on that order. First, the wired test is not optional: nearly every subsequent step is uninterpretable while Wi-Fi is still in the picture. Second, contacting the ISP is far more productive with evidence than without it. Support scripts exist to filter out unsubstantiated complaints, and a per-hop loss report with timestamps skips several tiers of that script. The broader router and network playbook is how to optimise your gaming network, and the practical loss-reduction walkthrough is how to reduce packet loss in games.

Sometimes, in a specific and fairly narrow set of circumstances. The mechanism is worth understanding before deciding, because it tells you immediately whether your case qualifies. A routing product sends your game traffic through its own network of servers instead of leaving path selection to the public internet. If the segment losing your packets is one that the alternative path avoids, the loss you experience can genuinely fall. Some products additionally send duplicate copies of packets over separate routes, so an isolated drop on one path is covered by the copy on the other — at the cost of extra bandwidth, and with no benefit if both paths share the congested segment.

It may help when loss is caused by: unstable or flapping routing, congested transit links, a poor peering relationship between your ISP and the game's host, awkward international paths where the default route takes a long way round, or a specific problem hop that the alternative path does not traverse.

It cannot repair: weak or interference-ridden Wi-Fi, damaged cabling, a failing router, a home network saturated by your own uploads, a game server that is overloaded or under attack, or a fault on your ISP line before the optimized route even begins. In all of those cases your packets are already lost before the product's network sees them, and adding a hop can make results marginally worse.

The honest summary is that route optimization is a targeted tool for a transit-path problem, not a general remedy for a bad connection. If your own diagnostics have not identified loss that begins outside your network and persists to the destination, the category has nothing to work with. If they have, a trial with before-and-after measurements is a reasonable next step — and the measurements, not the marketing, should decide it.

The mechanics of alternative routing are covered in the cornerstone, what is game route optimization. If you reach the point of evaluating products, our comparison of the category is best gaming network boosters, the category distinction is set out in gaming VPN vs gaming route optimizer, and the packet-duplication approach specifically is examined in our ExitLag review.

One further limitation applies to this entire article. Game behaviour under loss varies by engine, netcode and server design. A title with generous client-side prediction and a wide lag compensation window can absorb loss that would make a stricter, server-authoritative title unplayable. Comparing your experience in one game to a friend's experience in another, at the same loss percentage, is not a meaningful comparison.