Why Your WireGuard VPN May Be Slow When Traveling Abroad

Updated: November 2, 2026

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 (e.g., an Airbnb). Several factors can contribute to this performance difference, including ISP routing and peering, network congestion, router processing capacity, and the behavior of applications communicating through the VPN tunnel.

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.

High latency does not inherently reduce WireGuard's packet-forwarding capacity. Unlike TCP, WireGuard's UDP-based data transport does not use acknowledgements or congestion windows to regulate the transmission of ordinary data packets. For example, a WireGuard tunnel with 300 ms RTT can theoretically sustain the same packet-forwarding throughput as one with 3 ms RTT, assuming comparable available bandwidth, packet loss, and processing capabilities.

Applications communicating through the VPN tunnel often use TCP or QUIC, which rely on feedback from the receiving endpoint. Routing traffic through a distant VPN server can increase the RTT those applications experience. This can affect application performance, but it does not establish whether the bottleneck is transport behavior, the network path, or router processing.

Application behavior also matters. Opening files from a remote shared folder or copying many small files can involve repeated requests and responses between your device and the server. Each required round trip adds delay, so these tasks can feel slow even when the connection can sustain a fast download of one large file. Increasing the TCP receive window does not remove those application-level waits.

How TCP Throughput Relates to Latency

One useful relationship for understanding TCP throughput over high-latency connections is the Bandwidth-Delay Product (BDP):

Bandwidth-Delay Product = Throughput x RTT

The BDP describes the amount of data that must remain in flight (sent but not yet acknowledged) to sustain a particular throughput over a connection with a given RTT. However, this relationship does not independently establish the maximum achievable throughput or identify the limiting factor on a particular network connection.

For example, sustaining 100 Mbps of TCP throughput at an RTT of 288 ms requires approximately 3.6 MB of unacknowledged data in flight, assuming the network path and endpoints can otherwise support that rate.

Here are a few important definitions:

• TCP Receive Window (rwnd): The amount of additional data the receiving device advertises that it can accept based on available receiver-buffer space.
• TCP Congestion Window (cwnd): The amount of unacknowledged data the sender is permitted to maintain based on its congestion-control algorithm and network conditions.
• Throughput: The effective rate at which data is successfully transferred
• RTT (Round-Trip Time): The time required for data to travel between endpoints and for a response to return.

The sender's effective limit on outstanding TCP data is governed by the smaller of the receive window and congestion window, along with other constraints. This distinction is important because a sufficiently large receive window does not guarantee high throughput if congestion control or the network path prevents the sender from maintaining enough outstanding data.

Packet loss can reduce TCP throughput by requiring retransmissions and causing the sender to reduce its congestion window. On a high-latency connection, feedback and recovery can take longer, so a large receive window alone may not be enough to maintain high transfer speeds.

A Real Example from a GL.iNet Subreddit Member

A GL.iNet subreddit member in Vietnam reported the following results while connecting to their home WireGuard server 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

Remember that when downloading through a VPN server at home, your maximum download throughput also depends on the home internet connection's upload speed.

These measurements demonstrate a substantial difference between local internet performance and performance when using the international WireGuard connection. However, the tests do not necessarily measure equivalent network paths. A local speed test in Vietnam may connect to a nearby test server, while traffic routed through the VPN must first traverse the international connection to Texas. This introduces different ISP transit networks, peering arrangements, and potential congestion points. Two international connections with similar latency can deliver very different speeds depending on the quality of their network routes. Although the VPN connection reported approximately 288 ms RTT, this measurement alone does not establish that latency was the primary cause of the reduced throughput. Packet loss, inefficient international routing, congestion, or other factors may have contributed.

First, let's identify a few common factors that can affect network throughput:

1. ISP performance variance and congestion in your neighborhood: Throughput can vary substantially with congestion and network load.
2. 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/
3. ISP routing and international peering: Traffic between countries may traverse multiple independently operated networks. Congested peering links, inefficient routes, or packet loss can substantially reduce throughput even when both endpoints have fast local internet connections. Two international routes with similar RTTs may deliver very different speeds.

Local ISP congestion and international routing conditions are generally outside the user's direct control, although testing alternative ISPs or network routes may help identify performance differences. Poor international routing or congested peering is a common suspect when both endpoints have fast local internet but the long-distance path is slow. A test over a different ISP (e.g., a cafe) or hotspot can help show whether the slowdown is on the path. Wi-Fi limitations can often be reduced by using wired Ethernet connections wherever possible. Router processing limitations and MTU-related problems are also worth investigating when troubleshooting VPN throughput.

Ultimately, determining why an international VPN connection is slow requires distinguishing between limitations of the network path, the VPN router, and the applications communicating through the tunnel.

TCP Window Scaling to Enable Better Performance

Originally, TCP's receive window was limited to about 64 KB. Window Scaling (RFC 7323) raises that limit to about 1 GiB, and modern operating systems autotune the window automatically. For example, Microsoft's documented Normal autotuning setting can represent receive windows of about 16.8 MB. Modern TCP connections are therefore not inherently capped at 64 KB.

Source: duckware.com/blog/how-windows-is-killing-internet-download-speeds

How TCP Window Limits Interact with RTT

For a TCP connection with a fixed limit on outstanding data, the approximate window-related throughput ceiling is:

Throughput in bits per second ≈ Window limit in bytes × 8 ÷ RTT in seconds

Holding that window limit constant, higher RTT produces a lower window-related ceiling. The following examples illustrate this relationship; they are not predictions of actual VPN throughput.

Theoretical window-related ceilings (window ÷ RTT), using 1 MB = 1,000,000 bytes. These are illustrations, not predictions of actual VPN throughput.

Actual throughput also depends on congestion control, packet loss, available bandwidth, and processing limits. Multiple TCP connections can sometimes achieve higher aggregate throughput, but there is no universal RTT threshold beyond which they cannot fill the available bandwidth.

For the Vietnam-Texas example, a hypothetical single TCP connection limited to 2 MB of outstanding data at 288 ms RTT would have a window-related ceiling of approximately 55.6 Mbps (the table's 300 ms row is slightly lower because of its higher RTT). However, this does not establish why the user measured 47.3 Mbps.

Without knowing the test's connection count, actual TCP windows, and network conditions, we cannot determine whether the bottleneck was a window limit, congestion, packet loss, ISP routing, or something else.

What Determines Your TCP Window Size?

TCP window sizes belong to individual connections and can change while data is being transferred. The example values above therefore should not be treated as fixed settings that apply to every connection on your device.

The receiving device’s operating system manages its receive window. Its size depends on factors such as available receive-buffer space, operating-system autotuning and limits, application settings, and how quickly the application consumes incoming data. When downloading a file to your laptop, your laptop advertises its receive window to the sending server. When uploading, the receiving server advertises its window to your laptop.

The sender separately manages its congestion window according to its congestion-control algorithm and network feedback. This can restrict how much data remains outstanding even when the receiver advertises a large window. In a typical router-to-router WireGuard setup, these TCP windows belong to the communicating computers and servers; they are not a single window-size setting on the VPN routers.

How Can You Check an Actual Connection?

For readers comfortable with packet analysis, Wireshark can display the advertised TCP receive window. In a router-to-router setup, capture traffic on the computer performing the transfer. Start the capture before establishing a new TCP connection so that Wireshark records the initial handshake and window-scaling negotiation. During a download, inspect an outgoing TCP acknowledgment from your computer for that transfer, expand the Transmission Control Protocol section, and look for Calculated window size. This shows the receive window your computer advertised at that moment, with scaling applied when Wireshark knows the negotiated scale factor.

That value can change throughout the transfer. It does not directly reveal the sender’s congestion window or establish that the receive window is limiting performance. Checking an operating system’s autotuning setting also does not tell you the actual window currently advertised by an individual connection.

Another Real-World Example: Higher Speeds Without Lower Ping

In another support case, I investigated a slow Tailscale VPN connection. Tailscale uses WireGuard encryption, but its relay options can transport the encrypted packets differently: DERP relays use TCP-based connections, while Tailscale Peer Relays use UDP. This differs from a standalone WireGuard connection, which normally sends its encrypted packets directly over UDP. In this case, both relays were self-hosted on the same AWS Lightsail instance, so the comparison was between two privately hosted relay methods and not Tailscale's public DERP servers.

The client's internet connection tested at approximately 83 Mbps, while the VPN server's internet connection had a measured upload speed of approximately 40.6 Mbps. The following download speeds were observed:

SQM stands for Smart Queue Management, a router feature used to manage packet queues and reduce excessive delay under load. In this comparison, SQM was enabled or disabled on the client-side travel router.

SQM is not a general-purpose fix for slow VPN speeds. When it sees only a single encrypted tunnel flow, it cannot separately prioritize the application connections hidden inside it. It can still manage the shared packet queue, but that provides a queue-delay benefit only where excessive queueing is a problem it can address. If there is no excessive queueing that SQM can usefully control, unnecessarily restrictive bandwidth settings or additional processing overhead can reduce throughput without improving responsiveness.

Latency remained roughly unchanged, yet the UDP-based relay delivered substantially higher throughput with SQM either enabled or disabled. The largest improvement accompanied the change in relay method, not a reduction in ping or the removal of SQM.

One possible contributor is DERP's TCP-based transport. Each Tailscale device connects to the DERP relay over TCP, so the encrypted packets pass through separate TCP connections on either side of the relay. Multiple application connections inside the tunnel can share these outer TCP connections. If data is lost on an outer TCP connection, later data may have to wait for retransmission before it can be delivered, potentially delaying several applications at once. A UDP-based Peer Relay avoids this additional ordered TCP transport layer, although TCP applications inside the tunnel still use their own acknowledgements and congestion control.

Because both relays ran on the same instance, the relay host and location were constant. This strengthens the interpretation that the relay transport or implementation contributed to the improvement, rather than simply moving the relay closer to the users. However, using the same host does not guarantee identical network paths or conditions, so the comparison does not isolate TCP versus UDP as the sole cause.

These are observations from one support case, not guaranteed performance figures. However, they demonstrate why latency alone is insufficient to predict VPN speeds.

Conclusion

Hopefully, this article has provided a clearer understanding of why download and upload speeds over long-distance WireGuard VPN connections may be substantially lower than the internet speeds available at either endpoint. The most important distinction is that WireGuard itself does not impose an RTT-dependent throughput ceiling. Its UDP-based data transport does not implement TCP-style congestion windows, acknowledgements, or retransmissions for ordinary data packets.

However, TCP and QUIC applications communicating through the tunnel remain subject to their own congestion-control and reliability mechanisms. Higher RTT increases the amount of outstanding data required to sustain a given throughput. Multiple connections may improve aggregate performance, but neither RTT nor connection count alone determines the achievable speed. Actual performance also depends on packet loss, network congestion, ISP routing and peering, available bandwidth, MTU configuration, and VPN router processing capacity.

In a typical GL.iNet router-to-router WireGuard configuration, TCP connections are established between the end devices and their destination servers. The VPN routers encrypt, decrypt, and forward packets without directly controlling the TCP receive windows of those end-to-end connections. Although router hardware limitations may affect encrypted packet throughput, they should not be confused with TCP receive-window limitations.

When troubleshooting a slow international WireGuard connection, start by testing the internet connection at each location, using wired Ethernet where possible. Check whether VPN performance changes at different times of day or when using another internet connection, such as a mobile hotspot. These comparisons can help narrow down where the slowdown occurs, although more detailed testing may be needed to identify the cause. High latency can contribute to slower application performance, but it should not automatically be treated as the sole explanation for a slow VPN connection.

Looking ahead, I hope to experiment with strategically located UDP relays to see whether alternative routes can improve WireGuard VPN performance between the U.S. and Asia.

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