Why WireGuard VPN Speeds Drop with High Latency
Introduction
Many users are surprised when they connect to their GL.iNet router WireGuard server from another country only to find the internet speeds to be significantly less than the symmetrical gigabit speeds at their house or similarly fast internet speeds at their location abroad (ex. Airbnb). Usually, the ISP on the server or client end can be the one to blame. However, latency is a factor that is often overlooked despite having a very real and significant impact on throughput, or download/upload speeds. This post aims to set realistic expectations and explain why the speeds suffer when a high latency (i.e., ping results) are present.
What is Latency and Why Does it Matter?
Latency is the time it takes for data to travel from your device to the VPN server and back. It’s often measured in milliseconds (ms). For example, if your GL.iNet router in Vietnam is connecting to a VPN server in Texas, the round-trip time (RTT) can easily be 250-300 ms.
Even if your internet speed is technically “fast,” high latency can severely limit actual download and upload performance, especially when using TCP-based protocols (like HTTPs, file transfers, or most apps). Remember, even though WireGuard itself uses UDP, the traffic going through the VPN tunnel (web traffic, streaming, etc.) is often TCP-based. That TCP data is wrapped in UDP by WireGuard and sent over the internet.
The TCP Bottleneck: Throughput is Tied to Latency
Here’s the key formula that governs TCP performance:
Here are a few definitions first:
- TCP Window Size is the amount of data your system allows to be "in flight" (unacknowledged) before requiring acknowledgement.
- Throughput is your effective speed, or how much data per second you can send or receive.
- RTT (Round-Trip Time) is the delay between sending and receiving packets.
A Real Example from a GL.iNet Subreddit Member
Let’s say you’re located in Vietnam and connecting to your WireGuard VPN server back home in Texas running on a GL.iNet Flint 2 router.
- Server Location: Texas, USA
- Local speeds (symmetrical fiber) 700 Mbps download / 940 Mbps upload
- Client Location: Vietnam
- Local speeds (no VPN): 455 Mbps download / 634 Mbps upload
- Local speeds (with WireGuard VPN client enabled): 47.3 Mbps download / 12.1 Mbps upload, 288 ms ping
- Local speeds (no VPN): 455 Mbps download / 634 Mbps upload
First, let’s identify a few common constraints on any network connection:
- ISP performance variance and congestion in your neighborhood: Could see speeds varying as much as 100’s of Mbps
- Wi-Fi performance: Highly variable depending on physical environment, interference from other wireless devices, client device capability, and the inherent half-duplex nature of Wi-Fi (as opposed to full-duplex ethernet)
- For an in-depth explanation on realistic Wi-Fi performance read here: https://www.wiisfi.com/ The 1st constraint is out of your control. The 2nd constraint is mostly out of your control as well, except that it can potentially be eliminated by using wired, ethernet connections wherever possible.
The Bandwidth-Delay Product
Now, at first glance, the client-side VPN speed test results might look disappointing, but in reality they’re quite good given the latency involved. Here’s why using the formula from earlier:
TCP Window Size = 47.3 Mbps x 0.288 seconds
= 13.6 Mb, or ~1.7 MB
A 1.7 MB TCP window size is actually quite large and achieving that across a 288 ms latency connection means TCP is performing reasonably well. But how is this possible, when the original TCP window size field is limited to just 65,535 bytes (about 64 KB)?
TCP Window Scaling to Enable Better Performance
The answer lies in a feature called TCP Window Scaling, introduced to support modern high-bandwidth, high-latency networks. As described by Microsoft in this article, the TCP window size field is only 16 bits, which caps the unscaled window to 65,535 bytes. To overcome this, the TCP window scale option was introduced in RFC 7323, allowing the window size to be left-shifted by up to 14 bits, effectively increasing the maximum window size to 1 GB. The scaling factor is negotiated during the TCP three-way handshake. Once enabled, it allow endpoints to multiply the original window size. Congestion control algorithms on the client device operating systems are constantly at work to determine the correct window size scaling. In some cases, such as Microsoft Windows operating system, the window size “auto-tuning” does a particularly awful job at maximizing your download throughput.
Why You Can’t Just Keep Increasing TCP Window Size
Ultimately, the TCP window size is dependent on the available bandwidth and the round trip time. However, it’s not as simple as just increasing the window size to gain more throughput. Beyond a certain point, larger window sizes require more memory and processing power on both sender and receiver sides, which can overwhelm devices and networks and lead to increased packet loss and reduced performance.
Therefore, in the previous scenario, a TCP window size of around 1.7 MB is actually quite normal and reflects a well-performing connection given the high latency. The general upper limit of about 2 MB may act as a practical cap for many modern systems, balancing throughput and resource use. With a 2 MB window and 288 ms latency, the maximum theoretical throughput would be approximately 55.5 Mbps, which explains why speeds above this point become difficult to achieve despite having much faster raw internet connections on both ends (server and client). If we re-arrange the variables in the equation earlier to solve for throughput, you can see that with a latency of 80 ms and a 2 MB window size we could theoretically achieve about 200 Mbps. Unfortunately, however, the laws of physics prevent us from achieving this latency figure due to the physical distance (Texas <-> Vietnam).
Conclusion
Hopefully this article has provided an explanation that gives you more realistic expectations in download/upload speeds next time you use your WireGuard VPN abroad. And, lastly, remember routers are handling many simultaneous TCP sessions. While the beloved GL.iNet Flint 2 has a generous 1 GB of DDR4 RAM, the client-side router that’s connected to that Flint 2 may have much less RAM and thus exist as the limiting factor on the TCP window size scaling.
For more information and tips on troubleshooting and understanding your WireGuard VPN setup, see the following GL.iNet forum post: https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502
Introducing GL.iNet Home Routers
About GL.iNet
GL.iNet builds network hardware and software solutions that bring affordable and secure network connectivity to families and businesses all over the world. We work with a wide range of industries, solving everyday internet problems in offices, and providing complex networking solutions such as smart buildings and IoT Networks. At GL.iNet, We believe all successful businesses build upon a strong and secure foundation, which is why our highest priority is perfecting network security and reliability for our partners.