Waarom uw WireGuard VPN traag kan zijn tijdens reizen in het buitenland

Bijgewerkt: 2 november 2026

Inleiding

Veel gebruikers zijn verrast wanneer ze vanuit een ander land verbinding maken met de WireGuard-server van hun GL.iNet-router en merken dat de internetsnelheid aanzienlijk lager is dan de symmetrische gigabitverbinding thuis of de even snelle verbinding op hun verblijfplaats in het buitenland, bijvoorbeeld een Airbnb. Verschillende factoren kunnen aan dit prestatieverschil bijdragen: routering en peering van de internetprovider, netwerkcongestie, de verwerkingscapaciteit van de router en het gedrag van toepassingen die via de VPN-tunnel communiceren.

Wat is latentie en waarom is het belangrijk?

Latentie is de tijd die gegevens nodig hebben om van uw apparaat naar de VPN-server en terug te reizen. Dit wordt vaak gemeten in milliseconden (ms). Als uw GL.iNet-router in Vietnam bijvoorbeeld verbinding maakt met een VPN-server in Texas, kan de round-trip time (RTT) gemakkelijk 250-300 ms bedragen.

Hoge latentie vermindert niet op zichzelf de capaciteit van WireGuard om pakketten door te sturen. Anders dan TCP gebruikt het UDP-gebaseerde gegevenstransport van WireGuard geen ontvangstbevestigingen of congestievensters om de verzending van gewone gegevenspakketten te regelen. Een WireGuard-tunnel met 300 ms RTT kan bijvoorbeeld theoretisch dezelfde pakketdoorvoer handhaven als een tunnel met 3 ms RTT, bij vergelijkbare beschikbare bandbreedte, pakketverlies en verwerkingscapaciteit.

Toepassingen die via de VPN-tunnel communiceren, gebruiken vaak TCP of QUIC. Die zijn afhankelijk van terugkoppeling van het ontvangende eindpunt. Verkeer via een verafgelegen VPN-server leiden kan de RTT voor deze toepassingen verhogen. Dat kan hun prestaties beïnvloeden, maar toont niet aan of het knelpunt het transportgedrag, het netwerkpad of de routerverwerking is.

Ook het gedrag van toepassingen telt mee. Bestanden openen uit een gedeelde map op afstand of veel kleine bestanden kopiëren kan herhaalde verzoeken en antwoorden tussen uw apparaat en de server vereisen. Elke noodzakelijke retourreis voegt vertraging toe. Daardoor kunnen deze taken traag aanvoelen, ook als de verbinding één groot bestand snel kan downloaden. Een groter TCP-ontvangstvenster neemt deze wachttijden op toepassingsniveau niet weg.

Hoe TCP-doorvoer samenhangt met latentie

Een nuttige relatie om TCP-doorvoer op verbindingen met hoge latentie te begrijpen, is het bandbreedte-vertragingsproduct (BDP):

Bandbreedte-vertragingsproduct = Doorvoer x RTT

Het BDP beschrijft hoeveel gegevens onderweg moeten blijven, dus verzonden maar nog niet bevestigd, om een bepaalde doorvoer te handhaven op een verbinding met een gegeven RTT. Deze relatie bepaalt op zichzelf echter niet de maximaal haalbare doorvoer en identificeert evenmin de beperkende factor van een specifieke netwerkverbinding.

Om bijvoorbeeld 100 Mbps TCP-doorvoer te handhaven bij een RTT van 288 ms, is ongeveer 3.6 MB aan onbevestigde gegevens onderweg nodig, mits het netwerkpad en de eindpunten die snelheid verder kunnen ondersteunen.

Hier volgen enkele belangrijke definities:

• TCP-ontvangstvenster (rwnd): De hoeveelheid extra gegevens die het ontvangende apparaat aangeeft te kunnen accepteren op basis van de beschikbare ruimte in de ontvangstbuffer.
• TCP-congestievenster (cwnd): De hoeveelheid onbevestigde gegevens die de zender mag handhaven op basis van het congestiebesturingsalgoritme en de netwerkcondities.
• Doorvoer: De effectieve snelheid waarmee gegevens succesvol worden overgedragen
• RTT (round-trip time): De tijd die gegevens nodig hebben om tussen eindpunten te reizen en die een antwoord nodig heeft om terug te komen.

De effectieve limiet voor uitstaande TCP-gegevens van de zender wordt bepaald door het kleinste van het ontvangstvenster en het congestievenster, naast andere beperkingen. Dit onderscheid is belangrijk: een voldoende groot ontvangstvenster garandeert geen hoge doorvoer als congestiebesturing of het netwerkpad verhindert dat de zender voldoende uitstaande gegevens handhaaft.

Pakketverlies kan de TCP-doorvoer verlagen doordat hertransmissies nodig zijn en de zender het congestievenster verkleint. Bij hoge latentie kunnen terugkoppeling en herstel langer duren. Alleen een groot ontvangstvenster is dan mogelijk niet genoeg om hoge overdrachtssnelheden vast te houden.

Een praktijkvoorbeeld van een GL.iNet-subredditlid

Een lid van de GL.iNet-subreddit in Vietnam meldde de volgende resultaten bij verbinding met de WireGuard-server thuis in Texas, die op een GL.iNet Flint 2-router draaide.

• Serverlocatie: Texas, VS
  
  • Lokale snelheden (symmetrische glasvezel) 700 Mbps download / 940 Mbps upload
• Clientlocatie: Vietnam
  
  • Lokale snelheden (zonder VPN): 455 Mbps download / 634 Mbps upload
    
  • Lokale snelheden (met WireGuard-VPN-client): 47.3 Mbps download / 12.1 Mbps upload, 288 ms ping

Onthoud dat bij downloaden via een VPN-server thuis de maximale downloaddoorvoer ook afhangt van de uploadsnelheid van de internetverbinding thuis.

Deze metingen tonen een aanzienlijk verschil tussen de lokale internetprestaties en de prestaties via de internationale WireGuard-verbinding. De tests meten echter niet noodzakelijk gelijkwaardige netwerkpaden. Een lokale snelheidstest in Vietnam kan een nabijgelegen testserver gebruiken, terwijl verkeer via de VPN eerst de internationale verbinding naar Texas moet doorkruisen. Daarbij spelen andere transitnetwerken van providers, peeringafspraken en mogelijke congestiepunten een rol. Twee internationale verbindingen met vergelijkbare latentie kunnen door de kwaliteit van hun routes heel verschillende snelheden bieden. Hoewel de VPN-verbinding ongeveer 288 ms RTT rapporteerde, bewijst die meting alleen niet dat latentie de belangrijkste oorzaak van de lagere doorvoer was. Pakketverlies, inefficiënte internationale routering, congestie of andere factoren kunnen hebben bijgedragen.

Laten we eerst enkele veelvoorkomende factoren benoemen die de netwerkdoorvoer kunnen beïnvloeden:

1. Variërende ISP-prestaties en congestie in uw buurt: De doorvoer kan sterk variëren met congestie en netwerkbelasting.
2. Wi-Fi-prestaties: Sterk afhankelijk van de fysieke omgeving, storing door andere draadloze apparaten, de mogelijkheden van het clientapparaat en de inherent halfduplexwerking van Wi-Fi, tegenover full-duplex Ethernet
   • Lees hier een uitgebreide uitleg over realistische Wi-Fi-prestaties: https://www.wiisfi.com/
3. ISP-routering en internationale peering: Verkeer tussen landen kan meerdere onafhankelijk beheerde netwerken doorkruisen. Overbelaste peeringverbindingen, inefficiënte routes of pakketverlies kunnen de doorvoer aanzienlijk beperken, ook als beide eindpunten snelle lokale internetverbindingen hebben. Twee internationale routes met vergelijkbare RTT kunnen heel verschillende snelheden leveren.

Lokale ISP-congestie en internationale routeringscondities vallen doorgaans buiten de directe controle van de gebruiker, al kunnen tests met andere providers of routes prestatieverschillen zichtbaar maken. Slechte internationale routering of overbelaste peering is een veelvoorkomende verdachte als beide eindpunten lokaal snel internet hebben maar het langeafstandspad traag is. Een test via een andere provider, bijvoorbeeld in een café, of een hotspot kan helpen aantonen of de vertraging op het pad zit. Wi-Fi-beperkingen kunnen vaak worden verminderd door waar mogelijk bekabeld Ethernet te gebruiken. Bij het onderzoeken van VPN-doorvoer verdienen ook de verwerkingslimieten van de router en MTU-problemen aandacht.

Uiteindelijk moet u bij een trage internationale VPN-verbinding onderscheid maken tussen beperkingen van het netwerkpad, de VPN-router en de toepassingen die door de tunnel communiceren.

TCP Window Scaling voor betere prestaties

Oorspronkelijk was het TCP-ontvangstvenster beperkt tot ongeveer 64 KB. Vensterschaling (RFC 7323) verhoogt die limiet tot ongeveer 1 GiB, en moderne besturingssystemen stemmen het venster automatisch af. Zo kan de door Microsoft gedocumenteerde autotuninginstelling Normal ontvangstvensters van ongeveer 16.8 MB vertegenwoordigen. Moderne TCP-verbindingen zijn dus niet inherent beperkt tot 64 KB.

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

Hoe TCP-vensterlimieten samenwerken met RTT

Voor een TCP-verbinding met een vaste limiet aan uitstaande gegevens is het geschatte venstergerelateerde doorvoerplafond:

Doorvoer in bits per seconde ≈ Vensterlimiet in bytes × 8 ÷ RTT in seconden

Bij een constante vensterlimiet leidt een hogere RTT tot een lager venstergerelateerd plafond. De volgende voorbeelden illustreren deze relatie; ze voorspellen de werkelijke VPN-doorvoer niet.

Theoretische venstergerelateerde plafonds (venster ÷ RTT), met 1 MB = 1,000,000 bytes. Dit zijn illustraties, geen voorspellingen van de werkelijke VPN-doorvoer.

De werkelijke doorvoer hangt ook af van congestiebesturing, pakketverlies, beschikbare bandbreedte en verwerkingslimieten. Meerdere TCP-verbindingen kunnen soms een hogere totale doorvoer bereiken, maar er bestaat geen universele RTT-drempel waarboven ze de beschikbare bandbreedte niet meer kunnen benutten.

Voor het voorbeeld Vietnam–Texas zou een hypothetische enkele TCP-verbinding met maximaal 2 MB uitstaande gegevens bij 288 ms RTT een venstergerelateerd plafond van ongeveer 55.6 Mbps hebben. De rij van 300 ms in de tabel is iets lager door de hogere RTT. Dit verklaart echter niet waarom de gebruiker 47.3 Mbps heeft gemeten.

Zonder het aantal testverbindingen, de werkelijke TCP-vensters en de netwerkcondities te kennen, kunnen we niet bepalen of een vensterlimiet, congestie, pakketverlies, ISP-routering of iets anders het knelpunt vormde.

Wat bepaalt de grootte van uw TCP-venster?

TCP-venstergroottes horen bij afzonderlijke verbindingen en kunnen tijdens gegevensoverdracht veranderen. De bovenstaande voorbeeldwaarden mogen daarom niet worden gezien als vaste instellingen voor elke verbinding op uw apparaat.

Het besturingssysteem van het ontvangende apparaat beheert het ontvangstvenster. De grootte hangt onder meer af van de beschikbare ontvangstbufferruimte, autotuning en limieten van het besturingssysteem, toepassingsinstellingen en hoe snel de toepassing binnenkomende gegevens verwerkt. Als u een bestand naar uw laptop downloadt, meldt uw laptop zijn ontvangstvenster aan de verzendende server. Bij uploaden meldt de ontvangende server zijn venster aan uw laptop.

De zender beheert het congestievenster afzonderlijk op basis van het congestiebesturingsalgoritme en terugkoppeling uit het netwerk. Dit kan de hoeveelheid uitstaande gegevens beperken, zelfs als de ontvanger een groot venster meldt. In een typische WireGuard-opstelling tussen routers horen deze TCP-vensters bij de communicerende computers en servers; ze zijn geen enkele venstergrootte-instelling op de VPN-routers.

Hoe kunt u een werkelijke verbinding controleren?

Als u vertrouwd bent met pakketanalyse, kan Wireshark het gemelde TCP-ontvangstvenster tonen. Leg in een opstelling tussen routers het verkeer vast op de computer die de overdracht uitvoert. Start de opname voordat u een nieuwe TCP-verbinding opzet, zodat Wireshark de eerste handshake en onderhandeling over vensterschaling vastlegt. Bekijk tijdens een download een uitgaande TCP-bevestiging van uw computer voor die overdracht, klap de sectie Transmission Control Protocol open en zoek naar Calculated window size. Dit toont het ontvangstvenster dat uw computer op dat moment meldde, inclusief schaling als Wireshark de onderhandelde schaalfactor kent.

Die waarde kan tijdens de overdracht veranderen. Ze toont niet direct het congestievenster van de zender en bewijst evenmin dat het ontvangstvenster de prestaties beperkt. Ook de autotuninginstelling van een besturingssysteem vertelt niet welk werkelijk venster een individuele verbinding op dat moment meldt.

Nog een praktijkvoorbeeld: hogere snelheden zonder lagere ping

In een andere ondersteuningszaak onderzocht ik een trage Tailscale-VPN-verbinding. Tailscale gebruikt WireGuard-versleuteling, maar de relay-opties kunnen versleutelde pakketten anders vervoeren: DERP-relays gebruiken TCP-verbindingen, terwijl Tailscale Peer Relays UDP gebruiken. Dit verschilt van een zelfstandige WireGuard-verbinding, die zijn versleutelde pakketten normaal direct via UDP verzendt. In dit geval werden beide relays zelf gehost op dezelfde AWS Lightsail-instance. De vergelijking ging dus tussen twee privé gehoste relay-methoden en niet met de openbare DERP-servers van Tailscale.

De internetverbinding van de client haalde in de test ongeveer 83 Mbps, terwijl de internetverbinding van de VPN-server een gemeten uploadsnelheid van ongeveer 40.6 Mbps had. De volgende downloadsnelheden werden waargenomen:

SQM staat voor Smart Queue Management, een routerfunctie die pakketwachtrijen beheert en buitensporige vertraging onder belasting vermindert. In deze vergelijking werd SQM in- of uitgeschakeld op de reisrouter aan de clientzijde.

SQM is geen universele oplossing voor lage VPN-snelheden. Als het slechts één versleutelde tunnelstroom ziet, kan het de daarin verborgen applicatieverbindingen niet afzonderlijk prioriteit geven. Het kan nog steeds de gedeelde pakketwachtrij beheren, maar dat vermindert de wachtrijvertraging alleen als overmatige wachtrijvorming een probleem is dat het kan aanpakken. Als er geen overmatige wachtrijvorming is die SQM zinvol kan beheersen, kunnen onnodig beperkende bandbreedte-instellingen of extra verwerkingsbelasting de doorvoersnelheid verlagen zonder de responsiviteit te verbeteren.

De latentie bleef ongeveer gelijk, maar de UDP-gebaseerde relay leverde zowel met ingeschakeld als uitgeschakeld SQM aanzienlijk hogere doorvoer. De grootste verbetering ging samen met de wijziging van relay-methode, niet met lagere ping of het verwijderen van SQM.

Een mogelijke factor is het TCP-gebaseerde transport van DERP. Elk Tailscale-apparaat maakt via TCP verbinding met de DERP-relay. De versleutelde pakketten passeren dus afzonderlijke TCP-verbindingen aan beide zijden van de relay. Meerdere toepassingsverbindingen binnen de tunnel kunnen deze buitenste TCP-verbindingen delen. Bij gegevensverlies op een buitenste TCP-verbinding moeten latere gegevens mogelijk wachten op hertransmissie voordat ze kunnen worden afgeleverd. Dat kan meerdere toepassingen tegelijk vertragen. Een UDP-gebaseerde Peer Relay vermijdt deze extra geordende TCP-transportlaag, al gebruiken TCP-toepassingen in de tunnel nog wel hun eigen bevestigingen en congestiebesturing.

Omdat beide relays op dezelfde instance draaiden, bleven de relay-host en locatie gelijk. Dat ondersteunt de interpretatie dat het relay-transport of de implementatie bijdroeg aan de verbetering, in plaats van alleen de relay dichter bij de gebruikers te plaatsen. Dezelfde host garandeert echter geen identieke netwerkpaden of condities. De vergelijking isoleert TCP tegenover UDP daarom niet als enige oorzaak.

Dit zijn waarnemingen uit één ondersteuningszaak, geen gegarandeerde prestatiecijfers. Ze tonen wel waarom latentie alleen onvoldoende is om VPN-snelheden te voorspellen.

Conclusie

Hopelijk heeft dit artikel duidelijker gemaakt waarom download- en uploadsnelheden via WireGuard-VPN-verbindingen over lange afstanden aanzienlijk lager kunnen zijn dan de internetsnelheden aan beide eindpunten. Het belangrijkste onderscheid is dat WireGuard zelf geen RTT-afhankelijk doorvoerplafond oplegt. Het UDP-gebaseerde gegevenstransport implementeert voor gewone gegevenspakketten geen TCP-achtige congestievensters, ontvangstbevestigingen of hertransmissies.

TCP- en QUIC-toepassingen die via de tunnel communiceren, blijven echter onderworpen aan hun eigen congestiebesturing en betrouwbaarheidsmechanismen. Een hogere RTT verhoogt de hoeveelheid uitstaande gegevens die nodig is voor een bepaalde doorvoer. Meerdere verbindingen kunnen de totale prestaties verbeteren, maar noch RTT noch het aantal verbindingen bepaalt op zichzelf de haalbare snelheid. De werkelijke prestaties hangen ook af van pakketverlies, netwerkcongestie, ISP-routering en -peering, beschikbare bandbreedte, MTU-configuratie en de verwerkingscapaciteit van de VPN-router.

In een typische WireGuard-configuratie tussen GL.iNet-routers worden TCP-verbindingen opgezet tussen de eindapparaten en hun doelservers. De VPN-routers versleutelen, ontsleutelen en sturen pakketten door zonder rechtstreeks de TCP-ontvangstvensters van deze end-to-endverbindingen te besturen. Hardwarebeperkingen van de router kunnen de doorvoer van versleutelde pakketten beïnvloeden, maar moeten niet worden verward met beperkingen van het TCP-ontvangstvenster.

Begin bij het onderzoeken van een trage internationale WireGuard-verbinding met het testen van de internetverbinding op elke locatie, waar mogelijk via bekabeld Ethernet. Controleer of de VPN-prestaties veranderen op verschillende tijdstippen of via een andere internetverbinding, zoals een mobiele hotspot. Deze vergelijkingen kunnen helpen bepalen waar de vertraging optreedt, al kunnen uitgebreidere tests nodig zijn om de oorzaak vast te stellen. Hoge latentie kan toepassingen vertragen, maar moet niet automatisch als enige verklaring voor een trage VPN worden gezien.

In de toekomst hoop ik met strategisch geplaatste UDP-relays te experimenteren om te zien of alternatieve routes de WireGuard-VPN-prestaties tussen de VS en Azië kunnen verbeteren.

Voor meer informatie en tips over WireGuard-probleemoplossing raadpleegt u dit GL.iNet-forumbericht: https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502