How to Fix Packet Loss: Step-by-Step Troubleshooting Guide

Packet loss rarely shows up as packet loss. Users report choppy Teams calls, frozen screen shares, slow SaaS apps, or a connection that feels unstable. By the time the ticket reaches IT, the issue has often cleared. Even small amounts of loss degrade real-time traffic. And because TCP retransmits every lost packet, sustained loss also cuts throughput for everything else on the link.

Packet loss happens when data packets fail to reach their destination. How to fix it depends on where those packets are being dropped: on a user’s device, the LAN, the firewall, the ISP’s local loop, or deeper in the ISP’s network. More bandwidth won’t fix a duplex mismatch, and new cabling won’t fix congestion inside your provider’s network.

This guide covers how to fix packet loss step by step. You’ll confirm and measure the loss, find where it’s happening, identify the root cause, and apply the right fix for that location.

To fix packet loss, first confirm the loss rate with continuous monitoring. Then isolate where packets are being dropped: on a device, the LAN, the firewall or router, or your ISP’s network. Fix the root cause at that location, such as faulty cabling, an overloaded firewall, or ISP congestion, and keep monitoring to confirm it’s resolved.

Before fixing anything, confirm that packet loss is actually the problem, and measure how much loss there is, when it happens, and on which paths. The symptoms overlap with latency, jitter, and application-side issues. A one-off ping test usually isn't enough either: it covers a minute or two, uses ICMP that routers may deprioritize, and misses loss that only appears during peak hours or in short bursts.

Continuous monitoring between your key network locations gives you a measured loss rate over time instead of a single snapshot.

Obkio's Network Performance Monitoring solution measures packet loss continuously using Network Monitoring Agents. These agents exchange synthetic UDP traffic with each other in Network Monitoring Sessions. To get a measurement you can troubleshoot from, deploy:

• Local Agents at the affected site (an office, data center, or a remote user's workstation), installed as hardware, software, or virtual agents.
• Public Monitoring Agents in AWS, Azure, or Google Cloud, which act as reference points on the Internet. Comparing sessions to several of them is what lets you isolate the loss in Step 3.

Let the agents collect data for at least three hours. Intermittent loss often only shows up under real traffic patterns.

Once the agents are exchanging traffic, the Network Response Time graph shows the packet loss rate for each monitoring session, alongside latency and jitter. Compare that rate to the thresholds below to decide how urgently it needs fixing.

Obkio's Network Response Time Graph and VoIP Quality Graph showing Latency, Jitter, and Packet Loss

Generally, below 1% paclet loss is acceptable, 1–5% warrants investigation, and above 5% is critical and needs immediate troubleshooting

Packet loss thresholds

For application-specific benchmarks, see acceptable packet loss and high packet loss.

• Loss rate: the average and peak percentage per session.
• Timing pattern: constant, tied to business hours, or random bursts. Loss during business hours points toward congestion. Constant loss points toward hardware or configuration.
• Affected sessions: whether all sessions show loss or only one. This is the starting point for Step 3.

Packet loss can happen anywhere between the user and the application: on the user’s device, the LAN, the firewall, the ISP’s local loop, deeper in the ISP’s network, or at the destination. Each location has a different fix, so isolating it comes before changing anything.

The pattern of loss across your monitoring sessions tells you how far from your network the problem is.

How to locate packet loss by comparing monitoring sessions:

• Packet loss on every session points to the LAN, firewall, or ISP local loop
• Packet loss on one session points to intermediary networks, ISP routing, or the destination
• No Packet loss on any session points to the user's device or Wi-Fi

If no session shows loss but users still report issues, install a Local Agent directly on the affected user’s workstation. If loss shows up there but not on the site’s other agents, the problem is the device, its network adapter, or its wireless connection, not the network.

Once you know whether the loss is close to your network or further out, traceroutes show the exact hop where it starts. Obkio’s Visual Traceroutes run continuously alongside your monitoring sessions. You can see which hops showed loss at the time of the issue, instead of running a manual traceroute after it has cleared.

When reading traceroute results, look for loss that starts at a hop and continues through every hop after it to the destination. That’s where packets are actually being dropped.

Loss that appears at one intermediate hop but disappears at the next isn’t real packet loss. Many routers rate-limit or deprioritize the ICMP responses traceroutes rely on, while still forwarding your traffic normally. Reporting that kind of hop to your ISP as the cause usually gets the ticket closed without action.

Packet loss is usually a symptom, not the root problem. Something else causes the drops: a firewall running out of CPU, a saturated Internet circuit, a failing switch port, or congestion inside the ISP's network. Knowing where the loss happens narrows the search. Knowing why it happens tells you what to fix.

To find the cause manually, match the loss against data from the same time window:

• Device resource usage: CPU and memory on the firewall and routers in the affected path. Devices that can't process traffic fast enough drop packets.
• Interface utilization: bandwidth usage on the Internet-facing interface. Loss that tracks utilization peaks points to a saturated circuit and network congestion.
• Interface errors and discards: CRC errors, input errors, and output drops on switch and router network interfaces. These point to cabling, duplex mismatches, or buffer exhaustion.
• Traceroute path data: the hop where loss starts and persists to the destination (see Step 3).

The hard part is timing. By the time someone pulls device metrics and runs a traceroute, the issue has often cleared, and the evidence with it.

Obkio's solution automates this correlation through Obkio Insights, an automatic network diagnostics engine. When a monitoring session detects packet loss, Insights analyzes the Network Performance Monitoring, SNMP Device Monitoring, and Visual Traceroute data from the same time window. It then shows the probable root cause directly on the issue.

The diagnosis follows the same process a network engineer would use:

1. Rule out false positives. Insights first checks whether the Monitoring Agent had the resources it needed to run its tests. If it didn't, the issue is flagged as user-side.
2. Check network devices. It examines CPU, memory, and bandwidth usage on your firewall to see whether a resource constraint is dropping traffic.
3. Analyze the network path. It cross-references traceroute data to identify where along the path the loss occurs.

Each diagnosis points to a location and to the fix that applies:

Traceroute-based Insights (LAN and ISP issues) work out of the box, with no configuration. Device-based Insights (high bandwidth, CPU, and memory) need Network Device Monitoring on your firewall. You also need to set the Internet interface's maximum upload and download speeds, so Insights can detect when the circuit is saturated. Without Device Monitoring, firewall and ISP local loop issues show as a single combined result.

To see the evidence behind any diagnosis, select See what led to this conclusion. This opens an automatically generated dashboard with the performance, device, and traceroute data from the time of the issue. That same evidence is what you'll need if the fix involves your ISP.

Once you know where the packet loss happens and what's causing it, the fix depends on that location. A fix that works on the LAN won't help if the loss is inside your ISP's network, so match the fix to what Steps 3 and 4 found.

Signs the device is the problem: Packet loss shows up on an agent installed on the workstation but not on the site's other agents, or Obkio Insights flags the issue as user-side.

• Switch from Wi-Fi to a wired Ethernet connection: If the loss disappears, the problem is the wireless connection, not the network.
• Improve Wi-Fi conditions: Move closer to the access point, use the 5 GHz or 6 GHz band, or change to a less congested channel.
• Update network adapter drivers and the operating system.
• Check CPU and memory on the device: Background processes like backups, cloud sync, and updates can saturate the connection or starve the network stack.
• Replace the Ethernet cable or try a different port or adapter.
• Test with the VPN client disconnected to see whether the VPN tunnel is dropping traffic.

Signs the LAN is the problem: Obkio Insights reports an issue on the LAN network, or interface counters on switch ports show errors or discards.

• Check switch port counters for CRC and input errors. Rising errors point to bad cabling, patch cords, or transceivers. Replace them, or reseat SFPs.
• Fix duplex mismatches. Set both ends of the link to auto-negotiate, or set both to the same fixed speed and duplex. A mismatch causes collisions and loss that get worse under load.
• Look for output drops on uplinks. Drops on a congested uplink mean it needs more capacity, link aggregation, or QoS to protect real-time traffic.
• Check for loops and broadcast storms. Confirm Spanning Tree is configured correctly on every switch.
• Review wireless capacity. Overloaded access points, poor channel planning, and interference cause loss for every user connected to them.
• Replace failing switches. If errors persist after the cabling is replaced, the switch port or the switch itself may be failing.

Signs the firewall is the problem: Obkio Insights reports a firewall performance issue, or the loss lines up with spikes in the firewall's CPU, memory, or bandwidth usage.

• High bandwidth usage: identify the top talkers during the loss window. Apply traffic shaping and QoS to prioritize VoIP, video, and business-critical apps, and schedule backups and large transfers outside business hours. If the circuit stays saturated, it's undersized. See high bandwidth usage for more.
• High CPU usage: review the features that load the CPU most, such as IPS, SSL/TLS inspection, and verbose logging. Tune or narrow those policies and update the firmware. If CPU stays near capacity under normal traffic, the appliance needs an upgrade.
• High memory usage: check for session table exhaustion and lower idle session timeouts if needed. Firmware updates often fix memory leaks that build up over time.

Signs the ISP is the problem: Obkio Insights reports an issue on the ISP's local loop or in the ISP's network, or the traceroute shows loss starting at the ISP's first hop and continuing to the destination, with no resource issues on your firewall.

• Rule out your own equipment first: Restart the modem or CPE, and check the cabling between the modem and your firewall.
• Open a ticket with evidence: Include the packet loss rate, the time windows when it happened, the affected sessions, and a traceroute showing the hop where packet loss starts and persists. Loss at a single intermediate hop isn't evidence (see Step 3) and usually gets the ticket closed.
• Give the ISP direct access to the data: With Obkio, you can share a read-only link to your monitoring data, so the ISP's engineers can review it without an Obkio account.
• Escalate beyond first-level support if the issue persists. Explain the business impact, such as dropped calls or affected sites.
• Reduce your dependence on one provider: For recurring loss, add a redundant circuit from a different ISP with SD-WAN or failover, and review your SLA. See ISP packet loss for more.

What is High Packet Loss & How to Fix It

Learn all you need to know about high packet loss and its impact on network performance. Discover practical tips for diagnosing and fixing packet loss.

Learn more

Signs the problem is a specific path: Packet loss appears on only one monitoring session, or only when reaching one application or site.

• Find where the loss starts on the path: If it starts inside your ISP's network, it's likely a routing or peering problem your ISP needs to fix.
• If it starts beyond your ISP, contact the destination's support team or provider with the traceroute and monitoring data.
• Use an alternative path if one is available, such as a different SaaS region, a different ISP circuit, or SD-WAN path selection.

Fixing packet loss once doesn't stop it from coming back. Cabling degrades, traffic grows, firmware changes, and ISPs have bad days. These practices reduce packet loss over time and catch new issues before users report them.

After applying a fix, compare the packet loss rate on the affected monitoring sessions before and after the change, over the same time of day. Loss tied to business hours can look resolved in the evening and come back the next morning, so give it at least a full business day.

Packet loss is often intermittent, so continuous monitoring is the only reliable way to catch it. Deploy Monitoring Agents at every site, data center, and cloud environment that matters to your users. Every location then gets a measured loss rate, not just the one where someone complained. See packet loss monitoring for more.

Alert on sustained loss, not single-packet blips, so alerts point to real issues instead of creating noise. Set tighter thresholds on sessions that carry VoIP and video, where even low loss is noticeable. Obkio's network monitoring alerts notify you as soon as packet loss crosses the thresholds you set.

Know what normal looks like for each session. A gradual rise in packet loss over weeks often points to failing hardware or growing congestion before it becomes an outage. Comparing current loss to the baseline also shows whether a network change made things better or worse.

Watch bandwidth usage on Internet-facing interfaces and WAN links over time. Upgrade or rebalance links when peak usage regularly approaches capacity, not after loss starts.

Apply QoS consistently across the LAN, firewall, and WAN, so VoIP, video, and business-critical apps keep priority when links get busy. QoS doesn't add capacity, but it controls which traffic gets dropped when congestion happens.

Update firmware on firewalls, routers, switches, and access points to pick up fixes for performance bugs and memory leaks. Log network changes, so that when packet loss starts you can check what changed at that time.

For sites that can't afford downtime, add a second Internet circuit from a different provider with SD-WAN or automatic failover. Redundancy won't eliminate packet loss, but it lets traffic move off a degraded path. See how to measure and improve network reliability for more.

Yes. Most packet loss can be fixed once you know where it happens. Loss on a device, the LAN, or the firewall is within your control: cabling, duplex settings, Wi-Fi, device resources, and QoS. Loss inside your ISP's network has to be fixed by the ISP, so the fix there is getting them clear evidence.

To get rid of packet loss, measure it continuously, find whether it's on a device, the LAN, the firewall, or the ISP's network, and fix the root cause at that location. Then keep monitoring to confirm the loss is gone and to catch it if it comes back.

Compare monitoring sessions and traceroutes. If loss starts at your firewall or router and lines up with high CPU, memory, or bandwidth usage, it's your equipment. If loss starts at the ISP's first hop and continues to the destination, with no resource issues on your firewall, the ISP is the likely cause.

Yes. Wireless interference, weak signal, congested channels, and overloaded access points all cause packet loss. The quickest test is to connect the same device over Ethernet. If the loss disappears, the problem is the Wi-Fi connection, not the wider network.

Only if the loss is caused by congestion. If packet loss lines up with bandwidth usage reaching the circuit's capacity, more bandwidth or QoS will help. If the cause is a duplex mismatch, faulty cabling, an overloaded firewall CPU, or a problem in the ISP's network, more bandwidth won't fix it.

Usually not. A VPN can sometimes route traffic around a congested path, but it adds encryption overhead and can cause packet loss of its own through MTU and fragmentation issues. If packet loss gets worse with the VPN connected, check the VPN client and tunnel configuration.

Start by switching to a wired Ethernet connection, updating your network adapter drivers, and closing background apps that use bandwidth, like backups and cloud sync. Also test with your VPN disconnected. If the loss continues on a wired connection, the cause is likely further out on the network.

Packet loss below 1% is generally acceptable for most applications. Between 1% and 5%, VoIP and video calls start to degrade noticeably, and above 5% is high enough to need immediate troubleshooting. See acceptable packet loss for benchmarks by application.

Fixing packet loss comes down to measuring it, finding where it happens, and knowing what's causing it. The hardest part is having that data at the moment the issue happens, not after it has cleared.

Obkio's network monitoring solution measures packet loss continuously with Monitoring Agents at every location. It traces the path with integrated Visual Traceroutes and diagnoses the probable root cause automatically with Obkio Insights. When the problem is on your ISP's side, you already have the evidence to hand them.