VPN Packet Loss: Causes and Diagnostics

You are on a video call and the other person's voice breaks into robotic pieces. A web page hangs for a second, then loads all at once. A download keeps slowing down and speeding up. Your speed test number looks fine, yet the connection feels wrong. Very often the hidden cause is packet loss: small chunks of data that were sent but never arrived.

This article is about one specific question: why packet loss can appear when a VPN is switched on, and how to find out where the loss really happens. You will get a plain explanation of what loss is, a list of the usual causes, a repeatable test routine you can run with built-in tools, and a table for reading the results. If you only need a general explanation of delay, read how latency works with a VPN first.

What packet loss actually is

Everything you send over the internet is cut into packets, small pieces of data, usually up to about 1,500 bytes each. Every packet travels through a chain of devices: your phone or laptop, your Wi-Fi router, your internet provider, several carriers, and finally the destination. Any device along the way can drop a packet when its queue is full, when a radio signal is corrupted, or when the packet is too large to pass. The Internet Protocol itself makes no promise that a packet will arrive, as described in the basic IP specification.

What happens next depends on the traffic type.

• TCP traffic (web pages, downloads, most apps) notices the missing packet, waits, and sends it again. Nothing is lost for good, but the transfer slows down and the wait feels like a pause.
• UDP traffic (many calls, games and live streams) usually does not wait. The missing piece is simply gone, so you hear a click, see a frozen frame or watch your character jump.

That difference explains why one connection with 3 percent loss can still load a web page and yet make a call unusable.

How VPN packet loss shows up

Loss is easy to confuse with a slow connection. These signs point to it more than to plain low speed.

• Audio on calls cuts out in short bursts, while the video picture freezes and then catches up.
• Online games show "rubber-banding", where your position snaps back.
• Speed tests show a good number but the result changes widely between runs.
• Pages start loading, stall for one or two seconds, then finish.
• Large downloads reach a certain speed, collapse, and climb again in a saw-tooth pattern.
• The problem appears when the VPN is on and disappears when you switch it off, or the reverse.

If the problem is a steady low speed rather than stalling, read why a VPN can feel slow instead, because the fixes are different.

The usual causes, from your desk outward

Loss can start anywhere along the path. It helps to think in zones, starting with the one closest to you.

Zone 1: your device

An old or busy device can drop packets before they leave. A phone with a nearly flat battery in power-saving mode, a laptop whose CPU is at 100 percent because of a backup or an antivirus scan, or a network adapter driver that needs an update can all behave this way. Encryption adds some CPU work for every packet, which on a weak device makes the shortage more obvious while the tunnel is active.

Zone 2: your Wi-Fi

This is the most common source. Walls, microwaves, neighbouring networks on the same channel and distance from the router all damage radio signals. A damaged frame is retried by the Wi-Fi layer; when the retries fail the packet is lost. A 2.4 GHz network in a crowded condo is a classic case. Because a VPN changes nothing about the radio, loss that exists on Wi-Fi without the VPN will still exist with it, and may feel worse because the tunnel adds retransmission on top.

Zone 3: your internet provider

Congestion in the evening, a faulty line, a failing modem or a very busy shared connection can cause loss on the first few hops after your router. If your family is streaming and someone uploads a large video, the router queue fills and drops packets. This is sometimes called bufferbloat when delay also climbs.

Zone 4: the route to the VPN server

When you use a VPN, your traffic first goes to the VPN server and only then to the website. If the path between you and that server crosses a congested link, loss appears only with the VPN on. Providers choose different routes at different times, so a location that was fine in the morning may be lossy at night. Distance matters too: more hops means more chances for a drop.

Zone 5: the VPN server itself

A server that is busy at peak hours can drop packets because its own network card or CPU cannot keep up. You cannot measure this directly, but you can suspect it when loss is high to the server and the same route is clean for other destinations.

Zone 6: packet size and MTU

Every VPN adds a header to each packet, so a packet that was exactly the right size without the tunnel becomes too big with it. If the network cannot fragment it or the error messages that should tell your device are blocked, big packets vanish while small ones pass. The typical symptom is that pings work and small pages open, but large downloads or some secure sites hang. The standard method for discovering the largest safe size is described in the Path MTU Discovery specification, and the practical consequences are covered in our article on the MTU issue.

A repeatable test: three runs of the same ping

You do not need special software. The idea is to change one thing at a time and compare. Pick a stable public address that answers ping, such as a well-known public DNS resolver address, and write the results down.

Step 1: Test your router. Open Command Prompt on Windows or Terminal on macOS and Linux. Find your router address (often 192.168.0.1 or 192.168.1.1) and send 100 pings.

• Windows: ping -n 100 192.168.1.1
• macOS or Linux: ping -c 100 192.168.1.1

At the end, read the line with "packet loss". On a healthy home network, the answer is 0 percent and the times are only a few milliseconds. Any loss here means the problem is your Wi-Fi or your device, and nothing beyond it matters yet.

Step 2: Test the internet with the VPN off. Disconnect the VPN and ping the public address 100 times. Note the loss percentage and the average time.

Step 3: Test the internet with the VPN on. Connect the VPN, wait ten seconds, and run the exact same command. Compare.

Step 4: Repeat at a different time. Loss that appears only in the evening points to congestion. Loss at all times points to a stable fault.

Step 5: Try a second VPN location. Switch the location in the VPN app and repeat step 3. If a different location is clean, the first path was the problem.

Reading the results

Router	Internet, VPN off	Internet, VPN on	Most likely cause
0%	0%	0%	No loss at the moment; test again during the problem, or check jitter
Loss	Loss	Loss	Wi-Fi, cable or device; move closer or use a cable
0%	Loss	Loss	ISP line or modem; restart equipment and contact the provider
0%	0%	Loss	Path to the VPN server, server load or packet size
0%	0%	Loss, but only large packets	MTU problem
0%	0%	0% on ping, bad on calls	Jitter or an app-level issue, not pure loss

Finding where on the route it happens

If the loss is clearly tied to the VPN path, a route trace shows which hop drops packets. On Windows use pathping, on macOS and Linux use mtr if it is installed or traceroute otherwise.

For example, pathping -q 50 8.8.8.8 on Windows takes a couple of minutes and prints a per-hop loss table. Read it with care.

• Loss at one hop that does not continue to later hops is often harmless. Many routers deprioritise replies to test packets even though they forward real traffic perfectly.
• Loss that begins at one hop and continues at every hop after it is real. That hop, or the link just before it, is where packets disappear.
• Loss only at the last hop can mean the destination does not like being pinged, or that the server is overloaded.

Run the trace once with the VPN off and once with it on. The first hops with the VPN on are the tunnel to the VPN server, so the details after that vary, but a clean first part and a bad middle part tells you the loss sits between the VPN server and the destination, not at home.

Worked example: a remote worker's evening calls

Mei works from a rented flat. During the day her calls are fine. At 9 pm, her team call stutters whenever the VPN is on.

• Router ping: 0 percent loss, 3 ms.
• Internet ping, VPN off, 9 pm: 0 percent loss.
• Internet ping, VPN on, 9 pm: 6 percent loss, 90 ms average.
• Same test at 2 pm with VPN on: 0 percent loss.
• Another VPN location at 9 pm: 0 percent loss.

The table says the path to the first location is crowded in the evening. Her home line and Wi-Fi are healthy. The practical fix is to choose the second location during peak hours, and to note the time pattern in case she ever needs to report it to support.

A second case. Arun has packet loss on Wi-Fi even with the VPN off. His router ping shows 4 percent loss in the living room and 0 percent in the study next to the router. No VPN setting can fix that. Moving the router, switching the laptop to the 5 GHz band, or running a cable solves it.

Practical fixes in order of effort

Try these in order, retesting with the same ping after each.

1. Use a cable or sit near the router. This removes the biggest suspect first.
2. Switch Wi-Fi band. 5 GHz is shorter range but usually cleaner than 2.4 GHz in crowded buildings.
3. Restart the router and modem, wait two minutes, and reconnect.
4. Close heavy background traffic. Pause cloud backups, updates and large uploads while you test.
5. Change the VPN location. Pick a nearer one first, because fewer hops means fewer chances for loss.
6. Reconnect the VPN so it builds a fresh tunnel and possibly a new route.
7. Keep the app default connection settings. If your VPN app has advanced options, change only one at a time and only after reading the app or support guidance.
8. Update the app, the operating system and the network driver.
9. Check for conflicts, such as another VPN, a security suite that inspects traffic, or a third-party firewall.
10. Try a different network, such as your phone's mobile data through a hotspot. If the loss disappears there, your home network is the source.

For general stability advice see how to improve VPN connection stability. To confirm the tunnel is really working during your tests, use the steps in checking if your VPN is working.

Limits: what you cannot fix

Be realistic about what is in your control.

• A congested ISP link at peak hours cannot be repaired by changing apps. You can only avoid peak times or contact the provider.
• Loss on the open internet between carriers is outside your control. A different VPN location sometimes dodges it, but there is no guarantee.
• One test is not proof. Packet loss is statistical, so a hundred pings only give you a rough picture. For borderline cases run 300 or more, and compare more than once.
• ICMP is not the same as your real traffic. Some networks treat ping differently from calls and downloads, so use the test to find patterns rather than as an exact measurement.
• A VPN does not guarantee better quality. It protects traffic on the way, which can cost a few extra milliseconds and a little extra overhead.

Common mistakes when diagnosing loss

• Running only one 4-packet ping and trusting "0 percent".
• Blaming the VPN without a VPN-off comparison.
• Testing on 2.4 GHz Wi-Fi at the far end of the flat and then changing VPN settings.
• Reading intermediate hop loss in a trace as proof of a fault.
• Changing several settings at once, so you never learn which one helped.
• Forgetting that other people in the house can fill the upload link and cause loss for you.
• Confusing loss with jitter or with plain low speed.

Summary

Packet loss means packets are dropped on the way, and the effect depends on whether the traffic waits for retransmission or not. With a VPN the loss can sit in your device, your Wi-Fi, your ISP, the route to the VPN server, the server itself or in packet-size handling. A simple routine of pinging your router, then the internet with the VPN off and on, then another location, tells you which zone to fix. Retest after every change and treat your results as patterns, not exact measurements.

If you want a prepaid pass to test a different location during your own troubleshooting, the pricing page explains how passes work.