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

You can fix packet loss, but only if you identify the root cause. Keep packet loss under 0.5% for optimal performance; loss above 1% degrades video calls and gaming, while anything above 5% indicates a severe fault. A cable problem looks identical to an ISP fault in your browser, and a failing router presents the same symptoms as wireless interference. Blindly rebooting equipment or upgrading your plan rarely helps because packet loss has a specific origin.

This guide works through the fixes in order, from the most common and easily verified to the complex upstream issues requiring your ISP's assistance. If you are specifically experiencing issues while playing Valorant, Dota 2, League of Legends, or Rocket League, check our Gaming Packet Loss Fix Guide for game-specific optimizations. Follow each step and run a test to verify if the loss has dropped.

Quick Checklist: How to Fix Packet Loss

  • Run a baseline test: Measure your current loss at OpenPacketLoss™.
  • Power cycle equipment: Unplug your modem and router for 30 seconds.
  • Replace Ethernet cable: Swap your cable with a known-good Cat5e or Cat6.
  • Switch to Ethernet: Move from Wi-Fi to a stable wired connection.
  • Update drivers and firmware: Ensure your NIC drivers and router firmware are current.
  • Contact ISP: Report persistent loss that originates on their network.

Step 1: Run a Baseline Test First

Before changing any settings, you must measure your current packet loss to establish a baseline. Use OpenPacketLoss™ for a WebRTC UDP test, as this reflects real-world performance in video calls and gaming. When you review your results, keep these thresholds in mind:

Packet Loss Severity Reference

Loss % Impact
0-0.5% Normal. This level has a negligible effect on most applications.
0.5–1% Marginal — occasional glitches in VoIP and video calls
1–2.5% Noticeable — VoIP degrades, gaming affected, video stutters
2.5–5% Severe — calls drop, gaming unplayable, downloads slow
>5% Critical — most real-time applications fail
# Linux / macOS mtr --report --report-cycles 60 8.8.8.8 # Windows (winmtr or via WSL) mtr -r -c 60 8.8.8.8

To identify where the loss originates, run an MTR report using the commands above. Interpretation is key: ICMP deprioritization occurs when the router ignores your diagnostic ping to focus on forwarding real traffic. Genuine packet loss is persistent; it starts at a specific hop and remains present at that same level (or higher) for every hop that follows.

Run these tests at least twice to establish a pattern. Test once while you actively experience the problem and again during a "quiet time" when network usage is low. Comparing these two reports helps you distinguish between a permanent hardware fault and peak-hour ISP congestion.

Verification Action: Record your baseline percentage from OpenPacketLoss™ and identify the first hop where persistent loss appears in your MTR log.

Step 2: Restart Your Router and Modem

A router restart resolves intermittent loss without any cost. Consumer routers develop NAT (Network Address Translation) table overflows, connection state bloat, and memory fragmentation over long uptimes. These software-level issues cause the router's processor to struggle, leading to dropped packets even when the physical connection is perfect. A cold reboot clears these internal tables and resets the network stack.

Follow this specific power cycle sequence:

  1. Power off both the modem and the router.
  2. Wait at least 30 seconds to allow the capacitors to fully discharge.
  3. Power on the modem first and wait 1–2 minutes for it to establish a full sync with your ISP.
  4. Power on the router and wait for the status lights to stabilize.

If this fix resolves your packet loss but the problem recurs every few weeks, your router is likely struggling with its current workload. Check your router's administration panel to see if it supports a scheduled weekly reboot to maintain performance.

Verification Action: Rerun the OpenPacketLoss™ test and your MTR report after the router has been up for at least 5 minutes.

Step 3: Replace Your Ethernet Cable

A damaged Ethernet cable is the most common cause of intermittent packet loss. A cable can look perfect externally while one of the internal conductors has a hairline break or a poorly crimped connector.

  • Replace the cable with a known-good Cat5e or Cat6 cable.
  • Avoid cables longer than 100 meters without a switch in between.
  • Check for bent or corroded pins on the RJ45 (standard Ethernet) connectors.
  • Avoid running Ethernet cables parallel to power cables to prevent electromagnetic interference.

Verification Action: Swap the cable and retest to confirm that the loss drops to 0%.

Step 4: Switch from Wi-Fi to Ethernet

Wi-Fi is a shared medium susceptible to interference from neighboring networks, microwave ovens, and physical obstructions. While Wi-Fi has built-in retries, high error rates lead to dropped packets that affect real-time applications.

Connect your device directly to the router with an Ethernet cable. Your wireless environment causes the problem if packet loss disappears on a wired connection.

To improve your wireless stability:

  • Change your Wi-Fi channel: Use a Wi-Fi analyzer to find the least congested channel. On 2.4GHz, stick to 1, 6, or 11.
  • Move closer to the access point: Eliminate walls and furniture between your device and the router.
  • Upgrade to 5GHz or 6GHz: These frequencies are less congested than 2.4GHz and offer more non-overlapping channels.

Verification Action: Disable Wi-Fi on your device, plug in an Ethernet cable, and run a test at OpenPacketLoss™.

Step 5: Update Network Drivers and Firmware

Outdated or buggy drivers can cause the network stack to drop packets before they even leave your machine. Router firmware updates frequently fix stability bugs and security vulnerabilities.

Windows: Open Device Manager, right-click your network adapter, and select Update driver.

Linux: Check for hardware-level drops immediately after reproducing loss:

dmesg | grep -E "eth|eno|enp|NETDEV|TX timeout|dropped"

Router: Log into your router's admin interface (usually 192.168.1.1 or 192.168.0.1) and check for a "Firmware Update" section.

Verification Action: Install pending updates, restart your device, and retest your connection.

Step 6: Fix Bufferbloat and Local Congestion

Bufferbloat occurs when your router's buffers fill with bulk traffic and start dropping new packets, particularly the latency-sensitive ones required for gaming or video calls. This condition typically triggers packet loss during high-bandwidth activities like downloading or streaming.

Diagnosis Method 1 (Visual): Run a speed test while simultaneously running a continuous ping in your terminal to 8.8.8.8. If your ping latency jumps from 10ms to 200ms+ as soon as the speed test starts, you have a bufferbloat problem.

Diagnosis Method 2 (CLI): For a more precise measurement on Linux or macOS, compare your network's idle state against its loaded state using these commands:

# Run while the network is quiet ping -i 0.2 -c 100 8.8.8.8 > ping_idle.txt # Start a large download (e.g., a Linux ISO or game update) and immediately run: ping -i 0.2 -c 100 8.8.8.8 > ping_loaded.txt

Compare the maximum latency values in both files. If the loaded max is significantly higher than the idle max, your router is not managing its queue effectively.

To fix this, enable Quality of Service (QoS) or Smart Queue Management (SQM) in your router's settings. For advanced users running OpenWrt, install the luci-app-sqm package. When configuring, ensure you select the correct external interface (usually wan or eth0). If you have an asymmetric connection where download speed is much higher than upload, which is common in most home broadband, the CAKE queue discipline is generally superior to fq_codel as it better manages traffic flow on these links.

If you cannot install third-party firmware, check your router's stock admin panel under "Advanced" or "Gaming" settings. Modern routers from brands like Asus, Netgear, and TP-Link often include "Adaptive QoS" or "CAKE" options natively. Simply enabling these and entering your ISP's rated speeds (usually 90-95% of your actual speed) can eliminate bufferbloat-induced packet loss without requiring new hardware.

Verification Action: Rerun the CLI ping comparison test. A successful QoS configuration will keep your loaded max latency within 10–20ms of your idle baseline.

Step 7: Isolate Hardware by Substitution

If you have confirmed the problem is local but cannot find the specific cause, use substitution to isolate the failing hardware.

  1. Swap the router: Connect a different router or plug your PC directly into the modem. If loss disappears, your router is faulty.
  2. Try a different NIC: Use a USB-to-Ethernet adapter or a different computer. If the new device has 0% loss, your original network card is failing.
  3. Test different ports: Plug your cable into a different port on the router or switch.

Verification Action: Test each hardware configuration individually at OpenPacketLoss™ until you identify the failing component.

Step 8: Contact Your ISP

The problem originates on the ISP infrastructure if your MTR report shows loss beginning at the first hop outside your network (the ISP gateway) and persisting to all destinations. ISPs often close tickets after running a basic remote ping test, so you must provide detailed evidence to escalate the issue.

How to report the issue effectively:

  • Provide MTR logs: Include data showing consistent loss over at least 1 hour.
  • Isolate the fault: Confirm you have tested with a device connected directly to the modem to rule out your router.
  • Check your signal levels: For cable internet, access your modem's gateway (usually http://192.168.100.1).
    • Arris/Motorola modems: Go to the "Signal" tab. Look for downstream SNR (Signal-to-Noise Ratio) below 33dB or power levels outside the -7 to +7 dBmV range.
    • Other modems: Look for a "Signal" or "Status" tab to find these values.
  • Request a line fault investigation: Ask the technician to check the physical infrastructure and signal levels at your port.

ISP Support Message Template:

Subject: Packet Loss Investigation Required for Account [ACCOUNT NUMBER] I am experiencing [X]% packet loss that began approximately [DATE]. Troubleshooting completed: - Baseline Test: [X]% loss measured at openpacketloss.com - MTR Pattern: Loss begins at hop [X] and persists to destination - Isolation: Problem persists when connected directly to the modem via Ethernet - Timing: [Constant loss / Peak hour loss occurring between X and Y] - Signal Check: [Downstream SNR is X dB / Power is Y dBmV] Please open a line fault investigation and check for physical layer errors on the local node or signal instability at my ONT/modem.

Verification Action: Ask the ISP technician for the results of their head-end diagnostic test and run a follow-up test at OpenPacketLoss™ to confirm the fix.

Step 9: Monitor for ISP-Level Congestion

If packet loss only occurs during peak hours in your local timezone (typically evening), your ISP has over-provisioned their local nodes. This congestion causes packets to be dropped at the neighborhood level.

If your ISP cannot resolve the congestion, consider switching to a provider that uses a different technology (e.g., fiber instead of cable) or upgrading to a business-class plan with better bandwidth guarantees.

Verification Action: Run tests at OpenPacketLoss™ at different times of the day to map out the congestion pattern.

Step 10: Inspect Managed Switch Port Counters

This step applies to office networks, data centers, and self-hosted server environments.

In office or data center environments, check your managed switches for physical layer errors. Non-zero CRC (Cyclic Redundancy Check) errors indicate a bad cable, a failing transceiver, or a duplex mismatch.

# Example for a managed switch CLI show interfaces GigabitEthernet0/1

Look for input errors, CRC, or runts. A duplex mismatch, where one end is full-duplex and the other is half-duplex, will cause massive packet loss as soon as link utilization increases.

Verification Action: Clear the counters, wait 10 minutes, and confirm that the error counts remain at zero.

Step 11: Analyze Upstream Routing and Peering

This step applies to office networks, data centers, and self-hosted server environments.

If loss starts multiple hops deep into a backbone network and only affects specific destinations, you are likely hitting a congested peering point or a routing loop. To confirm destination-specific loss, run MTR to at least three different destinations:

# Test to Google Public DNS mtr --report --report-cycles 60 8.8.8.8 # Test to Cloudflare DNS mtr --report --report-cycles 60 1.1.1.1 # Test to your specific affected destination mtr --report --report-cycles 60 [your game server or affected destination IP]

A transit network fault causes the loss if it appears at the same intermediate hop across all destinations. A peering or routing issue specific to that network path causes the loss if it only appears when targeting one destination. Check for an ISP "looking glass" (e.g., lg.example.com) to run traceroutes from their perspective and rule out asymmetric routing issues.

VPN-Induced Packet Loss

VPNs can introduce packet loss through overloaded servers, lossy UDP tunnels, or MTU (Maximum Transmission Unit) mismatches. An MTU mismatch causes packets to be fragmented or dropped if the "Do Not Fragment" bit is set.

Diagnosis and Fix for MTU Issues: Use these commands to find the largest packet size that passes through your VPN without fragmentation. Decrease the size until the ping succeeds:

# Linux / macOS (decrease size from 1400 until successful) ping -M do -s 1400 8.8.8.8 # Windows (decrease size from 1400 until successful) ping -f -l 1400 8.8.8.8

If your VPN uses the WireGuard protocol, you can set the MTU explicitly in your configuration to match your findings:

[Interface] MTU = 1380

If MTR shows the VPN server itself is the lossy hop, switch to a different server location in your VPN app. If switching servers doesn't resolve the issue, disable the VPN and retest at OpenPacketLoss™ to isolate the VPN as the definitive cause.

Verification Action: Compare MTR results with and without a VPN to see if the lossy hop is bypassed or introduced by the tunnel.

Step 12: Tune OS Network Stack and NIC Settings

This step applies to office networks, data centers, and self-hosted server environments.

High-load servers can drop packets if the OS kernel cannot process them fast enough. Tune your network buffers and ring sizes to handle high packet rates.

Increase Linux kernel receive/send buffers:

# Increase socket receive buffer sysctl -w net.core.rmem_max=134217728 # Increase socket send buffer sysctl -w net.core.wmem_max=134217728

Increase NIC ring buffer size:

# View current NIC ring buffer settings ethtool -g eth0 # Set RX and TX ring buffers to the maximum supported value ethtool -G eth0 rx 4096 tx 4096

Verification Action: Run ethtool -S eth0 | grep -i "drop" and confirm that the drop counters are no longer incrementing under load.

Related Articles

Gaming Fix Guide Optimizing your network for Valorant, Dota 2, League, and Rocket League. VoIP Fix Guide Fix choppy, robotic calls on Teams, Zoom, and Webex. What is Packet Loss? Deep dive into the causes and technical impacts of data loss. Self-Hosted Server Deploy your own private testing node on Windows, Linux, or Docker. FAQ & Troubleshooting Common error codes and WebRTC connection fixes.

Conclusion: Maintaining a Stable Connection

Fixing packet loss requires a disciplined diagnostic approach: measure first, change exactly one variable at a time, and verify the results with data before moving to the next step. By establishing a clear baseline and testing after each fix, you avoid the trap of "ghost fixes" where a temporary improvement hides a deeper, recurring issue.

Pay close attention to the timing of your results as you troubleshoot. Intermittent loss that appears only during peak hours almost always points to congestion. You can manage local bufferbloat via QoS, but ISP-level node overload requires their intervention. In contrast, persistent loss appearing at hop 1 of your MTR report definitively indicates a physical layer fault like a failing router, a bad NIC, or a damaged cable.

Bookmark OpenPacketLoss™ and make it a habit to run a test after any major network change. Whether you are installing a firmware update, deploying new hardware, or upgrading your ISP plan, a 60-second UDP/WebRTC test will help you catch performance regressions early before they disrupt your work or gaming.