SwiftNetScanHome / Knowledge Center / ISP Troubleshooting
What Causes Packet Loss and How Do You Fix It?
9 min read · Updated 2026-08-03
Packet loss is the percentage of packets that never reach their destination. TCP hides small amounts of loss by retransmitting, which is why loss shows up as slowness rather than an error. Real-time protocols cannot retransmit, so loss becomes audible and visible immediately.
Key takeaways
- Under 0.1% is healthy; 1% degrades calls; above 2% breaks real-time applications.
- Loss is caused by congestion, physical-layer errors, or deliberate policing.
- Loss that only appears on one hop of a traceroute is often ICMP rate-limiting, not real loss.
- Consistent loss at the final destination is the only kind that always matters.
The three families of causes
Almost every real packet loss investigation ends in one of three buckets.
- Congestion: a queue somewhere is full, so the router drops what it cannot buffer. This is the most common cause and typically follows a daily pattern.
- Physical errors: noise on a coax segment, a damaged Ethernet cable, a dirty fiber connector, or WiFi interference corrupting frames.
- Policy and configuration: rate limiting, faulty QoS rules, MTU mismatches causing fragmentation drops, or an overloaded firewall.
Finding where the loss happens
The goal is to identify the first hop where loss begins and persists to the destination. Loss that appears at one intermediate hop but not at later hops is almost always ICMP deprioritisation by that router, and can be ignored.
- Test wired first — this eliminates WiFi, the most common culprit, in one step.
- Test to your router's LAN address: loss here means a local cable or NIC problem.
- Test to your ISP's first hop: loss here points at the access line or modem.
- Test to a well-connected public destination: loss only here suggests a peering or destination issue.
- Repeat at different times of day to separate congestion from hardware faults.
Fixes by cause
Match the fix to what the isolation step revealed rather than changing everything at once.
- WiFi loss: change channel, move to 5 GHz, reduce distance, or run Ethernet.
- Cable faults: replace patch cables, reseat coax connectors, remove unnecessary splitters.
- Bufferbloat-driven loss: enable SQM/CAKE on the router.
- Evening-only loss on the access line: report it to the ISP with timestamped measurements — segment congestion is their fix, not yours.
- Loss beyond your ISP: usually transient peering congestion; a VPN that changes the path can work around it.
How much loss is acceptable?
Applications differ. File transfers over TCP tolerate 1% loss with only a throughput penalty. Voice and video degrade audibly at the same figure because the codec has to conceal missing frames.
- 0 to 0.1%: healthy, no action needed.
- 0.1 to 1%: acceptable for browsing; calls may occasionally stutter.
- 1 to 2.5%: noticeable in calls and games; worth investigating.
- Above 2.5%: real-time applications become unusable.
Put this into practice with a real measurement.
Run a packet loss test