How to Fix Packet Loss & Stop Network Lag

Packet loss is fixable, but only if you identify the root cause. A cable problem looks identical to an ISP fault in your browser. 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.

Quick Checklist: How to Fix Packet Loss

  • Restart Equipment: Power cycle your modem and router.
  • Check Cables: Replace old or damaged Ethernet cables.
  • Go Wired: Move from Wi-Fi to a stable Ethernet connection.
  • Update Drivers: Ensure your network adapter drivers are current.
  • Contact ISP: Report persistent loss originating on their network.

Step 1: Run a Baseline Test First

Before touching anything, measure your current packet loss and write it down. You need a number to compare against after each fix.

Use OpenPacketLoss™ for a WebRTC UDP test; this reflects what video calls and games actually experience, not just ICMP ping behavior. Also run an MTR report to see where in the network path the loss occurs:

# Linux / macOS mtr --report --report-cycles 60 8.8.8.8 # Windows (winmtr or via WSL) mtr -r -c 60 8.8.8.8

The hop where loss first appears, and stays for all subsequent hops, is your problem location. Loss at hop 1 or 2 is local. Loss starting at hop 3 or beyond originates at your ISP or upstream network.

Fix 1: Replace Your Ethernet Cable

Start here. A damaged Ethernet cable is the single most common and most overlooked cause of intermittent packet loss. The cable can look perfect externally while one of the eight internal conductors has a hairline break or a poorly crimped RJ45 connector.

  • Replace with a known-good Cat5e or Cat6 cable
  • Avoid cables longer than 100 meters without a switch in between
  • Check connectors — bent or corroded pins on RJ45s cause intermittent contact faults
  • Avoid running Ethernet cables parallel to power cables; cross them at 90° if they must intersect

After swapping the cable, run your packet loss test again. If loss disappears, you found it.

Fix 2: Switch from Wi-Fi to Ethernet

Wi-Fi is a shared, half-duplex medium operating in unlicensed spectrum. Neighboring networks on the same channel, microwave ovens, Bluetooth devices, baby monitors, and physical obstructions all cause retransmissions and dropped frames. At the link layer, Wi-Fi masks this with automatic retries, but at high error rates those retries fail, leading to dropped packets.

Connect your device directly to the router with an Ethernet cable and retest. If your packet loss drops to zero or near zero, the problem is wireless.

To fix Wi-Fi packet loss specifically:

  • Change your Wi-Fi channel. Use a Wi-Fi analyzer (Android: WiFi Analyzer; macOS: Wireless Diagnostics → Scan; Linux: iwlist scan) to find the least congested channel in your area. On 2.4GHz, only channels 1, 6, and 11 are non-overlapping. On 5GHz, there are far more non-overlapping options.
  • Move closer to the access point or eliminate obstructions between the device and AP.
  • Upgrade to 5GHz or 6GHz. 5GHz has shorter range but is less congested and supports wider channels with higher throughput. 6GHz (Wi-Fi 6E/7) is essentially interference-free in most environments.
  • Replace an aging access point. Consumer Wi-Fi hardware degrades over time. If your router is more than five years old and in a high-density area, replace it.
  • Use a wired access point or MoCA adapter to backhaul a mesh node if running cables is impractical.

Fix 3: Restart and Test Your Router and Modem

Consumer routers develop memory leaks, connection table bloat, and NAT table overflow over long uptimes. A cold reboot (power off for 30 seconds, not just a soft restart) clears these states.

Power off the modem first, wait 30 seconds, power it back on and let it fully connect, then power on the router. Retest. If this fixes loss that had been building over days or weeks, set a scheduled weekly reboot in your router's administration panel.

Fix 4: Update Network Drivers and Firmware

Network Interface Card (NIC) Drivers

Outdated or buggy drivers cause the network stack to drop packets before they leave your machine. This is particularly common after OS upgrades that install generic drivers incompatible with your specific hardware.

Windows: Device Manager → Network Adapters → right-click your NIC → Update driver. Alternatively, download directly from the manufacturer (Intel, Realtek, Broadcom).

Linux: Check dmesg for NIC errors immediately after reproducing loss:

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

Update via package manager or install the manufacturer's out-of-tree driver if your distribution ships an older version.

macOS: NIC drivers are bundled with macOS updates. Run all pending system updates.

Router and Modem Firmware

Log into your router's admin interface and check for firmware updates. ISP-provided modems often update automatically, but check anyway. Firmware updates frequently contain fixes for connection stability bugs.

Fix 5: Check for Local Network Congestion

If multiple devices share your connection and one saturates the uplink with a large transfer, you will see packet loss on other devices due to buffer bloat: a condition where your router's buffers fill up and drop packets.

Diagnosis: Run a speed test while also running a continuous ping. If ping latency jumps from 10ms to 200ms+ during the speed test, you have buffer bloat.

Fix: Enable QoS (Quality of Service)
Most modern routers support QoS or Smart Queue Management (SQM). Enabling it tells the router to prioritize latency-sensitive traffic (VoIP, video calls, gaming) over bulk transfers (downloads, backups, streaming). Look for QoS settings in your router's advanced configuration.

For advanced users, OpenWrt with the SQM-scripts package (using fq_codel or CAKE queue discipline) is a highly effective solution for buffer bloat.

Fix 6: Check Hardware on the Local Network

If you're on a managed switch, check its port statistics for errors:

# On a Cisco/managed switch CLI show interfaces GigabitEthernet0/1 # Look for: input errors, CRC, runts, giants, ignored

Non-zero CRC errors on a port indicate a physical layer problem, such as a bad cable, bad NIC, or duplex mismatch. A duplex mismatch (one end auto-negotiated to half-duplex, the other forced to full) severely degrades network performance under load.

Force both ends to the same speed and duplex setting explicitly rather than relying on auto-negotiation if you suspect a mismatch.

Fix 7: Isolate Faulty Hardware by Substitution

If you've confirmed the problem is local but can't isolate it further:

  1. Swap the router with a known-good device or connect directly to the modem. If loss disappears, your router is faulty.
  2. Try a different NIC. On desktops, install a cheap PCIe NIC. On laptops, use a USB-to-Ethernet adapter. If the new NIC eliminates loss, your onboard NIC is failing.
  3. Test a different switch port. Plug your cable into a different port on the switch. Port-level faults on managed switches are common.

Fix 8: Contact Your ISP

If MTR shows loss beginning at the first hop outside your network (your ISP's router) and persisting to all destinations, the problem is on their infrastructure.

How to make an effective ISP support call:

  • Run MTR every 5 minutes for 1–2 hours and save the output. Document the time, loss percentage, and which hop it starts at.
  • Test from multiple devices to confirm it's not a single-device issue.
  • Test with a device connected directly to the modem (bypassing your router entirely) to confirm it's not your equipment.
  • Request a line fault investigation, not just a remote diagnostic. ISPs typically run remote diagnostics first and close the ticket. Insist they check line signal levels, error rates on the DSLAM or ONT port, and physical infrastructure if the remote check shows nothing.

For cable internet, line signal issues (SNR margin, power levels) cause packet loss before they cause a total outage. Ask for raw signal readings if you're on DOCSIS.

Fix 9: Reduce ISP-Level Congestion

Some ISPs over-provision their infrastructure in high-density areas, causing peak-hour congestion that manifests as packet loss between roughly 7 and 11 PM. If your loss follows a consistent daily pattern, this is the likely cause.

Options:

  • Upgrade to a business-class plan. Business accounts typically have dedicated bandwidth and SLA guarantees, while residential plans are usually best-effort.
  • Switch ISPs. If a fiber provider serves your area, fiber infrastructure is generally less susceptible to congestion than cable or DSL.
  • Use a VPN with a congestion-free peering arrangement. In some cases, your ISP congests a specific peering point but not others. A VPN that routes around the congested peer can reduce loss; test to verify before committing.

Fix 10: Address Upstream Routing Issues

If MTR shows loss that starts beyond your ISP (hop 5+, inside a backbone or transit network) and is destination-specific:

  • The issue is a routing or peering problem between your ISP and the destination's network.
  • Your ISP can raise a ticket with their upstream transit provider, but you need to demonstrate the pattern clearly.
  • In some cases, a VPN or changing the destination's DNS to a different anycast node routes your traffic over a different path, bypassing the problem hop entirely.

Fix 11: Enterprise and Server Environments

For data centers, office networks, and server infrastructure:

  • Check firewall CPU and session table utilization. Stateful firewalls that hit CPU or connection table limits drop packets silently. Review your firewall's resource dashboards.
  • Tune kernel network buffers (Linux):
# Increase socket receive/send buffers sysctl -w net.core.rmem_max=134217728 sysctl -w net.core.wmem_max=134217728 sysctl -w net.ipv4.tcp_rmem="4096 87380 134217728" sysctl -w net.ipv4.tcp_wmem="4096 65536 134217728"
  • Enable hardware offloading on high-throughput NICs. Use ethtool -k eth0 to review and ethtool -K eth0 to enable TSO, GRO, and checksum offloading.
  • Review interrupt coalescing settings. On high-packet-rate servers, interrupt coalescing tuning with ethtool -C can reduce CPU-induced drops.
  • Check for NIC ring buffer drops:
ethtool -S eth0 | grep -i "drop\|miss\|error"

Non-zero values here mean the NIC is receiving packets faster than the kernel is pulling them from the ring buffer. Increase ring buffer size:

ethtool -G eth0 rx 4096 tx 4096

Related Articles

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.

Verifying the Fix

After each change, run a fresh packet loss test at OpenPacketLoss™ and a new MTR report. Compare against your baseline. A genuine fix will produce a measurable, consistent improvement, not a temporary improvement that reverts within hours.

If loss returns after a fix, the root cause is still present. Intermittent hardware faults, ongoing ISP congestion, and routing instability all produce loss that fluctuates. Keep testing at different times of day across several days before concluding the problem is resolved.