Packet loss happens when data segments never reach their destination, causing lag, jitter, and dropped calls. Fix it by isolating where drops occur: run a ping and traceroute to a known target, then work outward from your device to the router, cabling, Wi-Fi, and finally your ISP path.
Symptoms
- Voice or video calls freeze, distort, or drop mid-sentence despite a reported strong connection.
- Online games show rubber-banding, teleporting players, or sudden disconnects to the lobby.
- Web pages stall on partial loads while ping to your router still succeeds.
- Speed test results fluctuate wildly between runs on the same device and network.
- VPN sessions time out repeatedly even though local LAN traffic seems fine.
Common Causes
Congested uplink or ISP path
When the WAN link or an upstream ISP router is saturated, queues overflow and packets are dropped by design. Evening peak hours make this pattern obvious.
Wi-Fi interference and weak signal
Overlapping 2.4 GHz channels, thick walls, and neighbouring access points force retransmissions. Packets that never get an ACK are eventually discarded.
Damaged or substandard cabling
Kinked patch cables, bent RJ45 clips, or cheap Cat5 runs near power lines introduce CRC errors on switch ports, which show up as loss to the endpoint.
Faulty NIC, driver, or firmware
An outdated network driver or a router with a memory leak will silently drop frames under load. A reboot temporarily masks it until the leak returns.
MTU mismatch or duplex error
Auto-negotiation failures leave one side at half-duplex, producing collisions. Oversized packets across a VPN with the wrong MTU get fragmented or dropped.
Step-by-Step Fix
- Measure the loss and locate where it starts
Run a sustained ping first to your gateway, then to 1.1.1.1 or 8.8.8.8. On Windows use ping -n 200, on macOS or Linux use ping -c 200. If loss appears only past your router, the problem is upstream. If it starts at the gateway, the fault is inside your LAN. - Trace the path to find the failing hop
Use tracert on Windows or mtr on Linux and macOS against the same destination. Let mtr run for at least two minutes. Loss that appears at one middle hop but disappears at the final hop is usually ICMP rate-limiting, not real loss. Loss that persists from a hop onward points to that hop. - Swap the cable and change the switch port
Replace the patch cable with a known-good Cat5e or Cat6 run and plug into a different port on the switch or router. On managed switches, check the port counters for CRC, alignment, or late-collision errors. Non-zero and rising values confirm a physical layer problem. - Test wired versus wireless side by side
Connect the same device by Ethernet and repeat the ping test. If wired is clean and Wi-Fi is not, the radio path is the culprit. This single comparison rules out half your suspects in under a minute. - Tune the wireless environment
Move the client closer, then use a Wi-Fi analyser to pick the least crowded channel. Force 5 GHz or 6 GHz for latency-sensitive devices, keep IoT on 2.4 GHz. Update the access point firmware and disable legacy 802.11b rates if your APs allow it. - Update NIC drivers and router firmware
Pull the current NIC driver directly from the chipset vendor rather than Windows Update, which often ships older builds. Reboot the router after firmware upgrades and verify the version reported in the admin UI actually changed. - Check for duplex, MTU, and QoS issues
Confirm both sides show full duplex at matching speeds. For VPN or PPPoE links, lower the MTU to 1400 and retest. Enable QoS on the router to protect voice and video queues when the uplink is near capacity. - Escalate to the ISP with evidence
If mtr shows sustained loss on an ISP hop across multiple days and times, open a ticket and attach the raw output with timestamps. Ask them to check the modem signal levels, upstream SNR on DOCSIS, or line attenuation on DSL and fibre.
Ping loss percentage, likely impact, and first action to take
| Loss rate | Typical impact | First action |
|---|---|---|
| 0.0 to 0.5% | Imperceptible for most applications | Monitor, no action required |
| 0.5 to 1.5% | Occasional call artefacts, minor game lag | Check Wi-Fi signal and channel |
| 1.5 to 3% | Noticeable stutter in voice and video | Run mtr, inspect cabling and NIC |
| 3 to 5% | Frequent disconnects, VPN instability | Bypass router, test at modem |
| Above 5% | Service unusable for real-time traffic | Open ISP ticket with mtr evidence |
Prevention
- Keep firmware and NIC drivers on a quarterly review cycle rather than only when something breaks.
- Run a scheduled mtr every hour to a fixed target and archive the results for baseline comparison.
- Label and date-code patch cables so ageing runs get retired before they start throwing CRC errors.
- Reserve dedicated SSIDs and channels for latency-sensitive traffic like softphones and conferencing.
FAQ
Is any packet loss normal on a healthy connection?
Yes. Brief spikes under 1% on internet paths are expected and rarely noticeable. What matters is sustained loss over minutes, not a single dropped ping. Real-time protocols like voice and gaming start to degrade around 1 to 2% sustained loss, while bulk downloads tolerate much more thanks to TCP retransmission.
Why does traceroute show loss on a middle hop but not the destination?
Intermediate routers often rate-limit or deprioritise ICMP replies to protect their control plane. If the final hop is clean, the middle-hop loss is cosmetic. Only treat middle-hop loss as real when every hop from that point onward also shows the same or higher loss.
Can a VPN cause packet loss on its own?
It can. VPNs add encapsulation overhead, so if the underlying MTU is not reduced, oversized packets get fragmented or dropped by routers that block fragments. Weak CPU on the VPN endpoint or an overloaded concentrator will also drop packets under load. Test with and without the tunnel to confirm.
Contact our network team to diagnose persistent packet loss on your infrastructure.