What Causes Packet Loss, and How to Fix It

Packet loss has a handful of common causes, from Wi-Fi and home hardware to ISP congestion and routing. Here is how to work out which one you have, and what actually fixes each.

Packet loss is what happens when data you sent never arrives. On a healthy connection it is close to zero. When it climbs, calls break up, games rubber-band and video freezes — while your speed test very often continues to report excellent numbers.

The causes range from your own Wi-Fi and cabling through to ISP congestion, routing problems and faults much further along the path. They fail in distinguishable ways, so the practical task is working out where the loss begins before changing anything. Most of the time that takes about ten minutes.

### Measure before you change anything The free connection test reports packet loss separately for upload and download, alongside jitter and latency. The number and the direction narrow the list considerably. Run the connection test →

The short answer

The common causes, each of which fails in a recognisable way:

1. Wi-Fi — interference, distance, channel congestion. One of the most common causes in home networks.
2. A saturated connection — something is using all the bandwidth, so packets get dropped.
3. Cables and hardware — a damaged cable, a failing adapter, a bad port.
4. An overloaded router — hardware struggling with NAT, QoS or inspection features.
5. The ISP access network — noise on a cable segment, a marginal DSL line, oversubscription.
6. Congested peering or transit — usually evenings only, and beyond your ISP's own network.
7. Traffic policing — traffic above your tier dropped rather than queued.

There is also a common eighth possibility: the loss is not real, and you are misreading a diagnostic.

The fastest way to find yours

Work outward. Each step eliminates one layer, and most people stop before step four.

1. Test over Ethernet. Loss disappears? It was Wi-Fi.
2. Test with nothing else running. Loss disappears? The connection was saturated.
3. Check interface error counters. Climbing? Cable, port or adapter.
4. Bypass the router. Loss disappears? The router.
5. Run an MTR. Loss beginning at one hop and continuing through the rest? Note that hop.
6. Check the return path. Outbound clean but loss persists? Look inbound.
7. Repeat at different times. Evenings only suggests congestion; constant suggests a hard fault.

If loss survives the first four steps, it is upstream of you, and the rest is about locating it precisely enough to report. Each step is expanded below.

How much packet loss is normal?

There is no universal threshold that makes a connection good or bad. Impact depends on the application, how bursty the loss is, the latency it sits on top of, the codec in use and how long it persists. The values below are practical guidelines rather than limits.

Two things change how those numbers feel.

Distribution matters as much as the percentage. Loss spread evenly is far more survivable than the same total arriving in bursts. Audio codecs conceal isolated missing packets by interpolating across the gap; they cannot conceal forty consecutive packets vanishing. A connection measuring 1% in tight bursts can sound worse than one measuring 2% spread thinly.

Direction matters. Loss on upload affects what other people receive from you; loss on download affects what you receive. If only one direction is affected, that alone eliminates several causes.

Rule out a false reading first

A surprising share of reported packet loss is not packet loss at all.

ICMP deprioritisation. ping and traceroute use ICMP, which many routers deliberately rate-limit — they answer some probes and ignore others while forwarding real traffic perfectly. A router that appears to be dropping 8% of pings may be dropping none of your actual data. This is the most common false positive in network troubleshooting.

The tell in an MTR is a hop showing loss where the hops after it are clean. Probes to those later hops pass through the same router, so if it were dropping transit traffic they would generally inherit the damage too.

Here is a real trace, run from our San Jose server to 1.1.1.1 on 25 August 2026:

HOST: network-tests-sanjose-1     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 140.91.234.180             0.0%    50    0.3   0.3   0.2   0.4   0.0
  2.|-- 172.68.188.109             0.0%    50    0.8   0.7   0.4   2.2   0.2
  3.|-- 172.68.188.108            58.0%    50    1.3   3.3   1.0  16.7   4.3
  4.|-- 172.68.188.107             0.0%    50    1.2   2.4   0.9  20.5   3.3
  5.|-- 1.1.1.1                    0.0%    50    0.9   0.9   0.9   1.6   0.1

Hop 3 reports 58% loss. Hop 4 and the destination report none at all. Every packet that reached hop 4 travelled through hop 3 first, so hop 3 cannot be discarding well over half of what passes through it — it is discarding over half of the probes addressed to it, while forwarding everything else untouched. Reporting this as a fault would waste everyone's time.

Loss isolated to a single hop is far more consistent with rate-limited replies than with a real problem. The guide to reading MTR results covers the patterns in detail.

Testing against a single public address. Public resolvers such as 8.8.8.8 and 1.1.1.1 may rate-limit or deprioritise ICMP, so ping loss to one of them is not proof of end-to-end loss. Compare several destinations, or use a test that measures actual data delivery rather than ICMP.

Testing while the connection is busy. A large upload running in the background will cause loss that is entirely self-inflicted. Test with everything else stopped.

Cause 1: Wi-Fi

If you are testing over Wi-Fi, start here. Wireless is a shared medium with no delivery guarantee, and loss occurring before the first hop is invisible to every path-based diagnostic you might run afterwards.

What causes it:

• Interference. On 2.4 GHz, overlapping networks, Bluetooth devices, microwaves and baby monitors all contend for the same spectrum. Only channels 1, 6 and 11 do not overlap.
• Distance and obstructions. Signal weakens with distance and is absorbed by walls — brick, concrete and anything containing metal or water are particularly effective.
• Channel congestion. In an apartment building, a dozen networks on one channel means your device spends much of its time waiting for a clear moment to transmit.
• Airtime contention. One old device connecting at a low rate occupies the airwaves far longer per byte than a modern one, degrading the network for everyone on it.

The fastest way to rule out Wi-Fi

Run the same connection test twice — once over Wi-Fi, once over Ethernet. If packet loss disappears on the cable, the fault is wireless and your ISP is not involved. This single comparison resolves more cases than any other step, and it takes two minutes.

Fixes, roughly in order of effectiveness:

• Move to 5 GHz or 6 GHz, which are less congested and have more non-overlapping channels. The trade-off is shorter range.
• Reposition the access point — central, elevated, away from metal and appliances. Distance to the farthest device matters more than distance to the nearest.
• Pick a genuinely clear channel rather than trusting auto-selection, which often chooses badly and rarely revisits the decision.
• Move stationary devices — desktops, consoles, TVs — onto Ethernet to free up airtime.
• For a large or awkward layout, add a second access point wired back to the router. Mesh over wireless backhaul helps coverage but consumes airtime doing it.

Cause 2: A saturated connection

When a link is full, something has to give, and dropping packets is how networks signal that. Some loss under saturation is normal rather than a fault.

The characteristic pattern is that everything is fine until someone starts a large upload, a cloud backup runs, or a console downloads an update — and then everything degrades at once.

How to confirm it: watch what latency does under load. Start a continuous ping and begin a large transfer:

Windows          ping -t 1.1.1.1
macOS / Linux    ping 1.1.1.1

A large latency increase under load is a classic sign of queueing delay, and commonly indicates bufferbloat — oversized buffers holding packets instead of dropping them promptly. If latency climbs from tens of milliseconds into the hundreds during the transfer and recovers the moment it finishes, that is the signature.

Fixes:

• Enable Smart Queue Management if your router supports it — fq_codel or CAKE. Shaping works by keeping the queue in your router, where it can be managed, rather than in your ISP's equipment where it cannot. Start somewhat below your measured line rate and tune by re-testing latency under load; around 85–90% is a reasonable starting point on many connections, but the right value depends on where the actual bottleneck sits.
• Schedule backups and large syncs outside the hours you need the connection.
• If saturation is constant rather than occasional, the connection is genuinely undersized for the household — one of the few situations where more bandwidth actually helps.

Cause 3: Cables and hardware

Physical faults produce loss that is stubbornly consistent — it does not follow time of day, does not care about load, and does not improve when you change anything upstream.

What causes it: a kinked or crushed cable, a damaged connector, a run alongside mains power picking up interference, a run longer than 100 m, a failing network adapter, or a marginal switch port. Cheap unshielded cable in an electrically noisy environment is a recurring culprit.

How to confirm it: check your interface error counters, which count exactly this.

Windows          netstat -e
macOS            netstat -i
Linux            ip -s link show

Errors and discards should be effectively zero. A counter climbing steadily while the interface is in use points squarely at the physical layer.

Also check the negotiated link speed. An interface that has quietly negotiated 100 Mbps on a gigabit port is a strong signal of a cabling fault — a damaged pair, a poor termination, or a cable that is not rated for the speed. Windows shows this in the adapter status; on Linux, ethtool eth0 reports it. A link that should be 1 Gbps and is not usually explains a great deal.

Fixes: replace the cable, try a different port, test the same machine on a different connection to isolate the adapter. On Windows, also confirm power management is not permitted to turn the adapter off — that setting causes intermittent loss that looks baffling until you find it.

Cause 4: An overloaded router

Consumer routers are small computers, and routing at gigabit speeds while performing NAT, QoS, traffic inspection and VPN termination is more work than the cheaper ones can manage. When the CPU saturates, packets are dropped.

The signature: loss appearing only at high throughput, often with the router's web interface becoming sluggish at the same time. It typically affects all devices at once.

How to confirm it: connect a machine directly to the modem, bypassing the router. If loss disappears, you have found it. Note that you will have no firewall in that configuration — treat it as a brief test, not a workaround.

Fixes: temporarily disable CPU-intensive features — deep packet inspection, traffic analysis, per-device QoS, VPN processing — to see whether the behaviour changes, then re-enable the security features you want once you know which one was responsible. Enable hardware NAT acceleration if it is available and switched off, and update the firmware. If the router predates a connection upgrade, it may simply be underpowered for the line it is now serving.

Cause 5: The ISP access network

If loss survives a wired test, with the router bypassed and nothing else running, it is beyond your control.

The useful evidence differs by access technology:

Cable is prone to upstream ingress noise — interference entering the shared coaxial segment, often through a damaged connector or splitter, sometimes at a neighbour's property. Rising uncorrectable codewords on your modem's status page are strong evidence, and this is usually fixable by a technician visit.

DSL degrades with line length and quality. A thin SNR margin means the line runs close to its limit and will drop packets when conditions shift slightly.

Fibre is generally clean at the physical layer, so loss on a fibre connection more often originates beyond the last mile.

Fixes: these are your ISP's to make. What you can do is document the fault properly — the guide to proving packet loss to your ISP covers what to measure and how to present it so the ticket gets escalated rather than closed.

Cause 6: Congested peering or transit

Sometimes your equipment and your ISP's access network are both healthy, and the loss occurs where your ISP hands traffic to another network.

The signature: loss confined to particular times — most often evenings — affecting some destinations while others are fine. If a game server is unplayable at 9pm but a speed test to your ISP's own server is perfect, this is the likely explanation.

How to confirm it, in order:

1. Run an MTR to an affected destination.
2. Find the first hop where loss begins and continues through every hop after it.
3. Use AS lookup to identify which organisation operates that hop. A boundary between two networks is a strong candidate for a congested interconnect.
4. Check the return path — routing is asymmetric, and a congested link inbound to you will not appear in any outbound test, including your ISP's.

Fixes: limited but not zero. Report it with evidence naming the interconnect. A VPN can sometimes route around a congested path by changing which networks your traffic crosses — a workaround rather than a fix, but occasionally a useful one.

Advanced: traffic policing

Some ISPs enforce speed tiers by policing rather than shaping — dropping traffic above the limit instead of queueing it. Policing produces packet loss by design, and can be aggressive enough to hurt applications that briefly burst above the rate.

This is a less common explanation than the six above, so treat it as something to consider once they have been ruled out rather than a first suspicion.

The signature: loss beginning precisely when throughput reaches a specific figure, and stopping immediately when you stay below it.

Fixes: shaping your own traffic slightly below the policed rate avoids triggering it — another argument for Smart Queue Management on your router.

What your pattern is telling you

A summary of the signatures above, for reference once you have measurements in hand:

Frequently asked questions

What causes packet loss on Wi-Fi?

Interference from neighbouring networks and household devices, distance and obstructions weakening the signal, congestion on a crowded channel, and airtime contention from older slow devices. Wireless has no delivery guarantee, so any of these produces loss directly. Testing the same connection over Ethernet confirms it in under a minute.

Is packet loss my ISP's fault?

Often not. Wi-Fi, a saturated link, a bad cable and an overloaded router are all common, and all are inside your home. Eliminate those first — test wired, with nothing else running, with the router bypassed — because your ISP will ask, and a ticket that has not done this gets closed quickly.

Can packet loss happen when my speed test looks fine?

Yes, and it is the usual case. Speed tests run over reliable transports that retransmit lost packets automatically, so the loss is repaired before it reaches the reported figure. Real-time applications cannot retransmit — a late audio packet is useless — so they experience it directly. Explained in full here.

Why do I get packet loss only at night?

Time-of-day patterns point at congestion rather than a hardware fault. It may be your own household, oversubscription in your ISP's local segment, or a congested interconnect between networks. An MTR during a bad period, compared with one during a good period, will usually show where the loss appears.

What is an acceptable amount of packet loss?

Under 0.1% is normal, and up to about 1% is tolerable for most uses. Above 1% sustained is worth investigating, and above 2.5% will noticeably break calls and games. Bursty loss hurts considerably more than the same percentage spread evenly.

Can a bad Ethernet cable cause packet loss?

Yes, more often than people expect. Damaged or crushed cable, poor connectors, runs alongside mains power, and lengths beyond 100 m all cause it. Interface error counters — netstat -e on Windows, ip -s link show on Linux — will show errors climbing, and an unexpectedly low negotiated link speed is another strong clue.

Does packet loss at one hop in a traceroute mean that router is broken?

Usually not. If the hops after it are clean, the result is far more consistent with that router rate-limiting replies to its own address than with it dropping transit traffic. Only loss that begins at a hop and continues through every subsequent hop indicates a real problem.

How do I prove packet loss is caused by my ISP?

Eliminate your own network first, then measure over UDP rather than relying on a speed figure, identify the hop where loss begins using MTR, check the return path, and repeat across several days for timestamps. The full method is here.

How do I fix packet loss caused by a full connection?

Enable Smart Queue Management on your router and shape slightly below your line rate, so queueing happens where it can be managed. Move large backups and downloads outside the hours you need the connection. If saturation is constant rather than occasional, more bandwidth genuinely will help.

Can a VPN cause packet loss?

It can add some, since traffic takes a longer path through the provider's server and encapsulation slightly reduces the usable packet size. A well-run VPN adds very little. Occasionally a VPN reduces loss by routing around a congested interconnect — testing with it on and off will tell you which applies.