Why Is My VPN So Slow? Test These Four Segments

A call that stutters, a download that crawls and an upload that freezes halfway are three different complaints wearing one label. Deciding which one you are chasing before you measure anything saves the rest of the investigation. Then change one segment of the path at a time and repeat the same task afterwards.

The order below moves outward from the task, because the tunnel cannot supply bandwidth that is missing underneath it.

Decide What Slow Means Before You Measure

A low steady rate, a high latency with sharp spikes and a transfer that stops dead at a fixed size are not variations of one fault. Each points at a different segment: throughput, the path itself, or a packet-size limit. Pick the task that actually bothers you and use it as the reference, since a speed test measures a bulk transfer that may behave nothing like a video call. Write down the endpoint, the protocol, the time of day and the number that matters to you.

Without that record, every later comparison becomes an argument about impressions.

Check the Access Network First

Pause your own large transfers, then measure the local link before the tunnel is involved. Compare with a harmless task and follow the client's kill-switch procedure instead of disabling several protections at once, and keep the same destination for both runs. A speed-test provider may hand you a different measurement server once your visible location changes, which turns the comparison into a test of two different servers.

ping -c 20 192.168.50.1
ping -c 20 198.51.100.7
curl -o /dev/null -w "%{time_starttransfer} %{speed_download}\n" https://speed.example.net/10mb.bin

If the baseline is already poor, the work belongs to Wi-Fi, router demand or the access service. A wired test or a stationary position near the access point separates a weak radio link from a congested uplink. Nothing the tunnel does will add capacity that the access line is not delivering.

Swap the Exit, Then the Transport

Hold the device, the network and the protocol fixed and test a second endpoint. Pick a plausible city from the location list, but do not assume the nearest label means the best route. If one exit is slow and others are fine, its host or path deserves the investigation; if every exit is slow on one device while another device is fine, the client is the better suspect.

Where the service supplies both profiles, compare OpenVPN over UDP with OpenVPN over TCP. UDP is the usual starting point for interactive work, while TCP can help on an access network that does not pass the UDP traffic at all. A TCP tunnel recovers loss by retransmitting inside the stream, which is why it can feel slower on a link that drops packets, and the OpenVPN performance troubleshooting notes cover the same trade-off before you tune anything else. Editing the word "udp" to "tcp" in a profile cannot create a listener that the server never opened.

Save the profile that helps before trying the next change. Otherwise a later regression leaves you guessing which edit produced the improvement.

Read the Device and the Symptom Together

Watch processor load during the transfer rather than after it, because encryption cost scales with traffic and a small router serving a household is a different machine from a laptop running its own client. Another VPN, a virtual machine or a network filter can sit in the same path and take a share of the traffic. Keep the software current without removing authentication checks or a kill switch to make a benchmark look better. If small requests succeed and large uploads stall at a consistent size, the MTU check is the next stop.

ping -M do -s 1400 -c 3 198.51.100.7
ip link show dev tun0 | grep -o "mtu [0-9]*"

When the tunnel resets repeatedly, fix the disconnections before interpreting any throughput number, because a reconnecting tunnel measures the handshake rather than the path. Repeat the original task after each change and keep the result. A faster speed test that still breaks the call has not solved the complaint you started with.