Diagnosing Packet Loss: Causes, Tests, and Solutions

By PingTester · August 10, 2026 · 6 min read

Packet loss is what happens when data sent across a network never arrives at its destination. A small amount of loss is normal on the wider internet; a sustained or high rate of loss is the cause of stuttering voice, rubber-banding in games, slow page loads, and broken SSH sessions. The good news is that packet loss is one of the easiest network problems to measure, locate, and — often — fix.

This guide covers what packet loss is, the most common causes, how to test for it with ping, traceroute, and mtr, and what to do when you find it.

What Is Packet Loss and Why It Matters

A packet is the unit of data that the network routes from source to destination. When a packet leaves your device and is dropped somewhere along the path — by a congested router, a failing switch, a noisy wireless link — that is packet loss. Loss is measured as a percentage: 5 packets lost out of 100 sent is 5% packet loss.

Why it matters depends on what the lost packets were carrying. A dropped TCP packet triggers retransmission, which inflates latency (see our TCP vs UDP latency comparison for the mechanics). A dropped UDP packet in a voice call is a gap in the audio. A dropped packet in a competitive game is a moment of unresponsiveness. Even 1% loss is perceptible in real-time applications; 5% or more makes most interactive services unusable.

Common Causes of Packet Loss

Packet loss falls into a few recurring categories:

• Network congestion. When a link is offered more traffic than it can forward, routers drop the excess. This is the most common cause of loss on shared and ISP links. Congestion loss is often periodic, spiking at peak-use hours.
• Hardware issues. A failing network interface, an overheating router, a damaged cable, or a faulty switch port can all drop packets. Hardware-induced loss is often random and persistent regardless of time of day.
• Wireless interference. WiFi uses shared spectrum. Microwave ovens, Bluetooth devices, neighboring networks, and physical obstructions all cause retransmissions and, eventually, dropped packets. WiFi loss typically improves when you move closer to the access point or switch to a wired connection.
• Routing problems. A misconfigured or unstable route can send packets into a black hole. This kind of loss usually affects only specific destinations, not the entire internet.
• ISP peering saturation. The handoff between two networks (your ISP and a content network) can become saturated during peak hours, causing loss only on traffic that crosses that peering link.

Testing with Ping: Reading Packet Loss Percentage

The fastest way to quantify packet loss is with ping. Send a meaningful number of packets and read the summary. On Windows: ping -n 100 example.com sends 100 packets. On macOS/Linux: ping -c 100 example.com does the same.

The summary line reports the loss percentage directly:

$ ping -c 100 example.com
100 packets transmitted, 97 received, 3.0% packet loss
round-trip min/avg/max/stddev = 12.1/15.8/45.2/4.7 ms

A 3% loss figure is worth investigating. Anything above 0% on a healthy home connection is a signal; above 1% will be noticeable in real-time applications; above 5% is severely disruptive. Note the high max RTT (45ms vs an average of 16ms) — a wide spread between average and max is a classic sign of congestion. For a step-by-step primer on running ping and reading its full output, see our guide to running a ping test.

Using Traceroute to Locate Where Loss Occurs

Ping tells you that loss is happening but not where. traceroute (Windows: tracert) reveals the hop-by-hop path packets take, with RTT for each hop. By running traceroute and looking for the hop where latency spikes or stars (no reply) appear, you can localize the loss.

$ traceroute example.com
 1  192.168.1.1       1.2 ms   1.1 ms   1.0 ms
 2  10.0.0.1          8.4 ms   8.2 ms   8.5 ms
 3  isp-edge.net     14.1 ms  13.9 ms  14.2 ms
 4  isp-core.net     42.7 ms  85.3 ms  63.1 ms
 5  *  *  *
 6  dest-net.net     45.0 ms  44.8 ms  45.1 ms

In this example, latency jumps between hops 3 and 4, and hop 5 returns no replies. The loss is occurring at or after hop 4 — likely at the peering handoff between the ISP core and the destination network. If the problem hop belongs to your ISP, the issue is on their side; if it belongs to the destination's network, the problem is beyond your control.

Be careful interpreting a single line of stars: many routers rate-limit ICMP and will show as loss even when they forward real traffic normally. Look for hops where loss is sustained and where subsequent hops also show loss, which indicates real drops rather than ICMP rate-limiting.

Using MTR for Continuous Monitoring

mtr (My Traceroute) combines ping and traceroute into a single tool that continuously probes each hop and reports loss percentage per hop over time. It is the best tool for diagnosing intermittent loss because it shows not just the path but the statistical behavior of every hop on it.

$ mtr --report --report-cycles 100 example.com
HOST: myhost                Loss%   Snt   Last   Avg  Best  Wrst
 1. 192.168.1.1              0.0%   100    1.1   1.1   1.0   2.3
 2. 10.0.0.1                 0.0%   100    8.4   8.3   8.0  10.1
 3. isp-edge.net             0.0%   100   14.1  14.0  13.9  16.2
 4. isp-core.net             3.0%   100   42.7  48.5  42.1 110.3
 5. ???                     100.0%   100    0.0   0.0   0.0   0.0
 6. dest-net.net             2.0%   100   45.0  45.2  44.8  52.1

Run mtr --report --report-cycles 100 example.com for a stable 100-cycle summary, or mtr example.com for a live updating view. The per-hop loss column is what makes mtr indispensable: it shows exactly where in the path packets disappear, so you know whether the problem is your LAN, your ISP, or somewhere in between.

Fixing Packet Loss

Once you know where the loss is, the fix depends on the cause:

• Hardware. Replace overheating routers, swap suspect cables, and try different switch ports. A restart often resolves transient issues, but persistent loss after a restart points to failing hardware.
• Cables. Damaged Ethernet cables cause retransmissions and loss. Replace any cable that is kinked, crushed, or old. Cat5e or Cat6 is sufficient for gigabit; fiber is best for longer runs.
• WiFi channels. Use a WiFi analyzer to find a less congested channel. On 2.4 GHz, channels 1, 6, and 11 are non-overlapping. On 5 GHz, many channels are available and interference is rarer. Where possible, switch latency-sensitive devices to Ethernet.
• Local congestion. If mtr shows loss starting at your router, another device on the network may be saturating the uplink. Enable QoS on the router to prioritize real-time traffic, or schedule large downloads for off-peak hours.
• ISP issues. If mtr shows loss entering at your ISP's edge or core, the problem is outside your home. Restarting your modem may help if the ISP has pushed a new config; otherwise, contact your ISP.

When to Contact Your ISP

Contact your ISP when all of the following are true: mtr shows loss beginning at a hop inside the ISP's network; the loss is sustained (not a brief blip); you have already ruled out your local hardware and LAN by testing with a wired connection and a different router if possible. Provide the ISP with your mtr output — it tells them exactly where in their network the problem is and saves hours of back-and-forth. Ask them to escalate to network engineering if the front-line support cannot resolve the issue, since peering and core routing problems are usually beyond tier-1 support's tools.

Summary

Packet loss is measurable, locatable, and usually fixable. Start with ping to quantify the loss, run traceroute or mtr to find where it enters the path, and attack the cause based on location: hardware, cables, or WiFi if the loss starts at your LAN; congestion or peering if it starts at your ISP. Run mtr for a hundred cycles to separate real loss from ICMP rate-limiting, and bring that data with you if you have to open a support ticket with your ISP. For broader context on what the resulting latency means, see our guide to understanding network latency.