Varför din WireGuard VPN kan vara långsam när du reser utomlands

Uppdaterad: 2 november 2026

Introduktion

Många användare blir förvånade när de ansluter till WireGuard-servern på sin GL.iNet-router från ett annat land och upptäcker att internethastigheten är betydligt lägre än den symmetriska gigabitanslutningen hemma eller den lika snabba anslutningen på boendet utomlands, till exempel en Airbnb. Flera faktorer kan bidra till skillnaden: internetleverantörernas routning och peering, nätverksbelastning, routerns bearbetningskapacitet och beteendet hos applikationer som kommunicerar genom VPN-tunneln.

Vad är latens och varför spelar den roll?

Latens är den tid det tar för data att färdas från din enhet till VPN-servern och tillbaka. Den mäts ofta i millisekunder (ms). Om din GL.iNet-router i Vietnam till exempel ansluter till en VPN-server i Texas kan tur- och returtiden (RTT) lätt bli 250-300 ms.

Hög latens minskar inte i sig WireGuards kapacitet att vidarebefordra paket. Till skillnad från TCP använder WireGuards UDP-baserade datatransport inte kvittenser eller överbelastningsfönster för att reglera överföringen av vanliga datapaket. En WireGuard-tunnel med 300 ms RTT kan till exempel teoretiskt upprätthålla samma genomströmning för paketvidarebefordran som en med 3 ms RTT, förutsatt jämförbar tillgänglig bandbredd, paketförlust och bearbetningskapacitet.

Applikationer som kommunicerar genom VPN-tunneln använder ofta TCP eller QUIC, som är beroende av återkoppling från den mottagande ändpunkten. Att skicka trafiken via en avlägsen VPN-server kan öka den RTT som applikationerna upplever. Det kan påverka prestandan, men visar inte om flaskhalsen ligger i transportens beteende, nätverksvägen eller routerns bearbetning.

Applikationernas beteende spelar också roll. Att öppna filer i en fjärrdelad mapp eller kopiera många små filer kan kräva upprepade förfrågningar och svar mellan din enhet och servern. Varje nödvändig tur och retur tillför fördröjning, så dessa uppgifter kan kännas långsamma även när anslutningen kan ladda ned en enda stor fil snabbt. Ett större TCP-mottagningsfönster tar inte bort dessa väntetider på applikationsnivå.

Hur TCP-genomströmning hänger ihop med latens

Ett användbart samband för att förstå TCP-genomströmning vid hög latens är bandbredds-fördröjningsprodukten (BDP):

Bandbredds-fördröjningsprodukt = Genomströmning x RTT

BDP beskriver hur mycket data som måste vara under överföring, alltså skickad men ännu inte kvitterad, för att upprätthålla en viss genomströmning med en given RTT. Sambandet avgör dock inte ensamt den högsta möjliga genomströmningen eller identifierar den begränsande faktorn för en viss nätverksanslutning.

För att till exempel upprätthålla 100 Mbps TCP-genomströmning vid 288 ms RTT krävs ungefär 3.6 MB okvitterad data under överföring, förutsatt att nätverksvägen och ändpunkterna i övrigt kan hantera den hastigheten.

Här är några viktiga definitioner:

• TCP-mottagningsfönster (rwnd): Den mängd ytterligare data som den mottagande enheten meddelar att den kan ta emot utifrån ledigt utrymme i mottagningsbufferten.
• TCP-överbelastningsfönster (cwnd): Den mängd okvitterad data som avsändaren tillåts hålla utifrån sin algoritm för överbelastningskontroll och nätverksförhållandena.
• Genomströmning: Den effektiva hastighet med vilken data överförs framgångsrikt
• RTT (tur- och returtid): Den tid som krävs för att data ska färdas mellan ändpunkterna och ett svar ska komma tillbaka.

Avsändarens effektiva gräns för utestående TCP-data styrs av det mindre av mottagningsfönstret och överbelastningsfönstret, tillsammans med andra begränsningar. Skillnaden är viktig: ett tillräckligt stort mottagningsfönster garanterar inte hög genomströmning om överbelastningskontrollen eller nätverksvägen hindrar avsändaren från att hålla tillräckligt mycket utestående data.

Paketförlust kan minska TCP-genomströmningen genom att kräva omsändningar och få avsändaren att minska överbelastningsfönstret. Vid hög latens kan återkoppling och återhämtning ta längre tid, så ett stort mottagningsfönster räcker kanske inte för att behålla höga överföringshastigheter.

Ett verkligt exempel från en medlem i GL.iNets subreddit

En medlem i GL.iNets subreddit i Vietnam rapporterade följande resultat vid anslutning till sin WireGuard-server hemma i Texas, som kördes på en GL.iNet Flint 2-router.

• Serverplats: Texas, USA
  
  • Lokala hastigheter (symmetrisk fiber) 700 Mbps nedladdning / 940 Mbps uppladdning
• Klientplats: Vietnam
  
  • Lokala hastigheter (utan VPN): 455 Mbps nedladdning / 634 Mbps uppladdning
    
  • Lokala hastigheter (med WireGuard VPN-klient aktiverad): 47.3 Mbps nedladdning / 12.1 Mbps uppladdning, 288 ms ping

Kom ihåg att den högsta nedladdningshastigheten via en VPN-server hemma också beror på hemanslutningens uppladdningshastighet.

Mätningarna visar en stor skillnad mellan lokal internetprestanda och prestandan via den internationella WireGuard-anslutningen. Testerna mäter dock inte nödvändigtvis likvärdiga nätverksvägar. Ett lokalt hastighetstest i Vietnam kan ansluta till en närliggande testserver, medan trafik via VPN först måste passera den internationella anslutningen till Texas. Det innebär andra transitnät hos internetleverantörerna, peeringavtal och möjliga överbelastningspunkter. Två internationella anslutningar med liknande latens kan ge mycket olika hastigheter beroende på nätverksvägarnas kvalitet. Även om VPN-anslutningen rapporterade ungefär 288 ms RTT visar inte mätningen ensam att latens var den främsta orsaken till den lägre genomströmningen. Paketförlust, ineffektiv internationell routning, överbelastning eller andra faktorer kan ha bidragit.

Låt oss först identifiera några vanliga faktorer som kan påverka nätverkets genomströmning:

1. Variationer i internetleverantörens prestanda och överbelastning i ditt område: Genomströmningen kan variera kraftigt med överbelastning och nätverkslast.
2. Wi-Fi-prestanda: Varierar kraftigt beroende på den fysiska miljön, störningar från andra trådlösa enheter, klientenhetens kapacitet och Wi-Fis inneboende halvduplexfunktion, i motsats till Ethernet med full duplex
   • En djupare förklaring av realistisk Wi-Fi-prestanda finns här: https://www.wiisfi.com/
3. Internetleverantörernas routning och internationell peering: Trafik mellan länder kan passera flera oberoende drivna nätverk. Överbelastade peeringlänkar, ineffektiva vägar eller paketförlust kan minska genomströmningen avsevärt, även om båda ändpunkterna har snabba lokala internetanslutningar. Två internationella vägar med liknande RTT kan ge mycket olika hastigheter.

Överbelastning hos den lokala internetleverantören och internationella routningsförhållanden ligger normalt utanför användarens direkta kontroll, men tester med andra leverantörer eller vägar kan visa prestandaskillnader. Dålig internationell routning eller överbelastad peering är vanliga misstankar när båda ändpunkterna har snabbt lokalt internet men långdistansvägen är långsam. Ett test via en annan leverantör, till exempel på ett kafé, eller en hotspot kan hjälpa till att visa om fördröjningen finns längs vägen. Wi-Fi-begränsningar kan ofta minskas genom att använda kabelanslutet Ethernet där det går. Routerns bearbetningsbegränsningar och MTU-problem är också värda att undersöka vid felsökning av VPN-genomströmning.

För att avgöra varför en internationell VPN-anslutning är långsam måste man i slutändan skilja mellan begränsningar i nätverksvägen, VPN-routern och applikationerna som kommunicerar genom tunneln.

TCP Window Scaling ger bättre prestanda

Ursprungligen var TCP:s mottagningsfönster begränsat till ungefär 64 KB. Fönsterskalning (RFC 7323) höjer gränsen till ungefär 1 GiB, och moderna operativsystem anpassar fönstret automatiskt. Microsofts dokumenterade inställning Normal för automatisk anpassning kan till exempel representera mottagningsfönster på ungefär 16.8 MB. Moderna TCP-anslutningar är därför inte i grunden begränsade till 64 KB.

Källa: duckware.com/blog/how-windows-is-killing-internet-download-speeds

Hur TCP-fönstergränser samverkar med RTT

För en TCP-anslutning med en fast gräns för utestående data är det ungefärliga fönsterrelaterade genomströmningstaket:

Genomströmning i bitar per sekund ≈ Fönstergräns i byte × 8 ÷ RTT i sekunder

Om fönstergränsen hålls konstant ger högre RTT ett lägre fönsterrelaterat tak. Följande exempel illustrerar sambandet; de förutsäger inte faktisk VPN-genomströmning.

Teoretiska fönsterrelaterade tak (fönster ÷ RTT), där 1 MB = 1,000,000 byte. Detta är illustrationer, inte förutsägelser om faktisk VPN-genomströmning.

Den faktiska genomströmningen beror också på överbelastningskontroll, paketförlust, tillgänglig bandbredd och bearbetningsgränser. Flera TCP-anslutningar kan ibland nå högre sammanlagd genomströmning, men det finns ingen universell RTT-tröskel över vilken de inte kan utnyttja hela den tillgängliga bandbredden.

I exemplet Vietnam–Texas skulle en hypotetisk enskild TCP-anslutning, begränsad till 2 MB utestående data vid 288 ms RTT, ha ett fönsterrelaterat tak på ungefär 55.6 Mbps. Tabellen visar ett något lägre värde på raden för 300 ms eftersom RTT är högre. Detta visar dock inte varför användaren uppmätte 47.3 Mbps.

Utan att känna till antalet anslutningar i testet, de faktiska TCP-fönstren och nätverksförhållandena kan vi inte avgöra om flaskhalsen var en fönstergräns, överbelastning, paketförlust, internetleverantörens routning eller något annat.

Vad bestämmer storleken på ditt TCP-fönster?

TCP-fönsterstorlekar hör till enskilda anslutningar och kan ändras under dataöverföringen. Exempelvärdena ovan bör därför inte betraktas som fasta inställningar som gäller varje anslutning på din enhet.

Den mottagande enhetens operativsystem hanterar mottagningsfönstret. Storleken beror bland annat på ledigt utrymme i mottagningsbufferten, operativsystemets automatiska anpassning och gränser, applikationsinställningar och hur snabbt applikationen tar hand om inkommande data. När du laddar ned en fil till din bärbara dator meddelar datorn sitt mottagningsfönster till den sändande servern. Vid uppladdning meddelar den mottagande servern sitt fönster till datorn.

Avsändaren hanterar sitt överbelastningsfönster separat utifrån algoritmen för överbelastningskontroll och nätverkets återkoppling. Detta kan begränsa mängden utestående data även när mottagaren meddelar ett stort fönster. I en typisk WireGuard-installation mellan routrar hör dessa TCP-fönster till datorerna och servrarna som kommunicerar; de är inte en enda inställning för fönsterstorlek på VPN-routrarna.

Hur kan du kontrollera en faktisk anslutning?

För dig som är van vid paketanalys kan Wireshark visa det annonserade TCP-mottagningsfönstret. I en installation mellan routrar ska du fånga trafiken på datorn som utför överföringen. Starta fångsten innan en ny TCP-anslutning upprättas så att Wireshark registrerar den första handskakningen och förhandlingen om fönsterskalning. Under en nedladdning granskar du en utgående TCP-kvittens från datorn för överföringen, expanderar avsnittet Transmission Control Protocol och letar efter Calculated window size. Detta visar mottagningsfönstret som datorn annonserade vid det tillfället, med skalning tillämpad när Wireshark känner till den förhandlade skalfaktorn.

Värdet kan ändras under överföringen. Det avslöjar inte direkt avsändarens överbelastningsfönster och visar inte heller att mottagningsfönstret begränsar prestandan. Att kontrollera operativsystemets inställning för automatisk anpassning talar inte heller om vilket faktiskt fönster en viss anslutning annonserar just nu.

Ett annat exempel från verkligheten: högre hastigheter utan lägre ping

I ett annat supportärende undersökte jag en långsam Tailscale-VPN-anslutning. Tailscale använder WireGuard-kryptering, men reläalternativen kan transportera de krypterade paketen på olika sätt: DERP-reläer använder TCP-baserade anslutningar, medan Tailscale Peer Relays använder UDP. Detta skiljer sig från en fristående WireGuard-anslutning som normalt skickar sina krypterade paket direkt över UDP. I det här fallet var båda reläerna egenhostade på samma AWS Lightsail-instans, så jämförelsen gällde två privat hostade relämetoder och inte Tailscales offentliga DERP-servrar.

Klientens internetanslutning uppmättes till ungefär 83 Mbps, medan VPN-serverns internetanslutning hade en uppmätt uppladdningshastighet på ungefär 40.6 Mbps. Följande nedladdningshastigheter observerades:

SQM står för Smart Queue Management, en routerfunktion som hanterar paketköer och minskar alltför stora fördröjningar under belastning. I jämförelsen aktiverades eller avaktiverades SQM på reseroutern på klientsidan.

SQM är ingen universallösning för låga VPN-hastigheter. När funktionen bara ser ett enda krypterat tunnelflöde kan den inte prioritera de applikationsanslutningar som är dolda inuti det var för sig. Den kan fortfarande hantera den gemensamma paketkön, men det minskar köfördröjningen bara när alltför stor köbildning är ett problem som funktionen kan åtgärda. Om det inte finns någon alltför stor köbildning som SQM kan hantera på ett meningsfullt sätt kan onödigt begränsande bandbreddsinställningar eller extra bearbetningsbelastning minska genomströmningen utan att förbättra svarstiderna.

Latensen var i stort sett oförändrad, men det UDP-baserade reläet gav betydligt högre genomströmning med både aktiverat och avaktiverat SQM. Den största förbättringen sammanföll med bytet av relämetod, inte med lägre ping eller borttagning av SQM.

En möjlig bidragande faktor är DERP:s TCP-baserade transport. Varje Tailscale-enhet ansluter till DERP-reläet via TCP, så de krypterade paketen passerar separata TCP-anslutningar på vardera sidan om reläet. Flera applikationsanslutningar i tunneln kan dela dessa yttre TCP-anslutningar. Om data förloras på en yttre TCP-anslutning kan senare data behöva vänta på omsändning innan de kan levereras, vilket kan fördröja flera applikationer samtidigt. En UDP-baserad Peer Relay undviker detta extra ordnade TCP-transportlager, även om TCP-applikationer i tunneln fortfarande använder egna kvittenser och egen överbelastningskontroll.

Eftersom båda reläerna kördes på samma instans var relävärden och platsen oförändrade. Det stärker tolkningen att relätransporten eller implementeringen bidrog till förbättringen, snarare än att reläet bara flyttades närmare användarna. Samma värd garanterar dock inte identiska nätverksvägar eller förhållanden, så jämförelsen isolerar inte TCP kontra UDP som den enda orsaken.

Detta är observationer från ett enda supportärende, inte garanterade prestandasiffror. De visar dock varför latens ensam inte räcker för att förutsäga VPN-hastigheter.

Slutsats

Förhoppningsvis har artikeln gjort det tydligare varför nedladdnings- och uppladdningshastigheter via WireGuard-VPN-anslutningar över långa avstånd kan vara betydligt lägre än internethastigheterna vid respektive ändpunkt. Den viktigaste skillnaden är att WireGuard i sig inte sätter något RTT-beroende genomströmningstak. Dess UDP-baserade datatransport implementerar inte TCP-liknande överbelastningsfönster, kvittenser eller omsändningar för vanliga datapaket.

TCP- och QUIC-applikationer som kommunicerar genom tunneln är däremot fortfarande beroende av sina egna mekanismer för överbelastningskontroll och tillförlitlighet. Högre RTT ökar mängden utestående data som krävs för att upprätthålla en viss genomströmning. Flera anslutningar kan förbättra den sammanlagda prestandan, men varken RTT eller anslutningsantal avgör ensamt den möjliga hastigheten. Faktiska prestanda beror också på paketförlust, nätverksbelastning, internetleverantörernas routning och peering, tillgänglig bandbredd, MTU-konfiguration och VPN-routerns bearbetningskapacitet.

I en typisk WireGuard-konfiguration mellan GL.iNet-routrar upprättas TCP-anslutningar mellan slutenheterna och deras destinationsservrar. VPN-routrarna krypterar, dekrypterar och vidarebefordrar paket utan att direkt styra TCP-mottagningsfönstren för dessa anslutningar mellan ändpunkterna. Routerns hårdvarubegränsningar kan påverka genomströmningen av krypterade paket, men ska inte förväxlas med begränsningar i TCP-mottagningsfönstret.

Vid felsökning av en långsam internationell WireGuard-anslutning bör du börja med att testa internetanslutningen på varje plats och använda kabelanslutet Ethernet där det går. Kontrollera om VPN-prestandan förändras vid olika tider på dygnet eller med en annan internetanslutning, till exempel en mobil hotspot. Jämförelserna kan hjälpa till att ringa in var flaskhalsen finns, även om mer detaljerade tester kan behövas för att identifiera orsaken. Hög latens kan bidra till långsammare applikationer, men bör inte automatiskt ses som den enda förklaringen till en långsam VPN-anslutning.

Framöver hoppas jag experimentera med strategiskt placerade UDP-reläer för att se om alternativa vägar kan förbättra WireGuard-VPN-prestandan mellan USA och Asien.

Mer information och felsökningstips för din WireGuard VPN-konfiguration finns i följande inlägg på GL.iNets forum: https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502