Dlaczego VPN WireGuard może działać wolno podczas podróży zagranicznych

Aktualizacja: 2 listopada 2026

Wprowadzenie

Wielu użytkowników dziwi się, gdy po połączeniu z innego kraju z serwerem WireGuard na routerze GL.iNet odkrywa, że prędkość internetu jest znacznie niższa niż na domowym symetrycznym łączu gigabitowym lub równie szybkim łączu w miejscu pobytu za granicą, na przykład w Airbnb. Na tę różnicę może wpływać kilka czynników: routing i peering operatorów, przeciążenie sieci, moc obliczeniowa routera oraz zachowanie aplikacji komunikujących się przez tunel VPN.

Czym jest opóźnienie i dlaczego ma znaczenie?

Opóźnienie to czas potrzebny na przesłanie danych z urządzenia do serwera VPN i z powrotem. Często mierzy się je w milisekundach (ms). Na przykład, gdy router GL.iNet w Wietnamie łączy się z serwerem VPN w Teksasie, czas podróży w obie strony (RTT) może bez trudu wynieść 250-300 ms.

Duże opóźnienie samo w sobie nie zmniejsza zdolności WireGuard do przekazywania pakietów. W przeciwieństwie do TCP transport danych WireGuard oparty na UDP nie używa potwierdzeń ani okien przeciążenia do regulowania transmisji zwykłych pakietów danych. Na przykład tunel WireGuard z RTT 300 ms może teoretycznie utrzymywać taką samą przepustowość przekazywania pakietów jak tunel z RTT 3 ms, przy porównywalnym dostępnym paśmie, utracie pakietów i możliwościach przetwarzania.

Aplikacje komunikujące się przez tunel VPN często korzystają z TCP lub QUIC, które polegają na informacjach zwrotnych od odbierającego punktu końcowego. Kierowanie ruchu przez odległy serwer VPN może zwiększać RTT odczuwany przez te aplikacje. Może to wpływać na ich wydajność, ale nie rozstrzyga, czy wąskim gardłem jest zachowanie transportu, trasa sieciowa czy przetwarzanie w routerze.

Znaczenie ma też zachowanie aplikacji. Otwieranie plików ze zdalnego folderu współdzielonego lub kopiowanie wielu małych plików może wymagać wielokrotnych żądań i odpowiedzi między urządzeniem a serwerem. Każda wymagana podróż w obie strony dodaje opóźnienie, dlatego zadania te mogą wydawać się wolne nawet wtedy, gdy połączenie umożliwia szybkie pobranie jednego dużego pliku. Zwiększenie okna odbiorczego TCP nie usuwa tych oczekiwań na poziomie aplikacji.

Związek przepustowości TCP z opóźnieniem

Przydatną zależnością do zrozumienia przepustowości TCP na łączach o dużym opóźnieniu jest iloczyn przepustowości i opóźnienia (BDP):

Iloczyn przepustowości i opóźnienia = Przepustowość x RTT

BDP określa ilość danych, która musi pozostawać w drodze, czyli być wysłana, ale jeszcze niepotwierdzona, aby utrzymać daną przepustowość przy określonym RTT. Sama ta zależność nie określa jednak maksymalnej osiągalnej przepustowości ani nie wskazuje czynnika ograniczającego konkretne połączenie sieciowe.

Na przykład utrzymanie przepustowości TCP 100 Mbps przy RTT 288 ms wymaga około 3.6 MB niepotwierdzonych danych w drodze, zakładając, że trasa sieciowa i punkty końcowe są w stanie obsłużyć taką prędkość.

Oto kilka ważnych definicji:

• Okno odbiorcze TCP (rwnd): Ilość dodatkowych danych, którą urządzenie odbierające zgłasza jako możliwą do przyjęcia na podstawie wolnego miejsca w buforze odbiorczym.
• Okno przeciążenia TCP (cwnd): Ilość niepotwierdzonych danych, którą nadawca może utrzymywać zgodnie ze swoim algorytmem kontroli przeciążenia i warunkami sieciowymi.
• Przepustowość: Efektywna szybkość skutecznego przesyłania danych
• RTT (czas podróży w obie strony): Czas potrzebny na przesłanie danych między punktami końcowymi i powrót odpowiedzi.

Efektywny limit niepotwierdzonych danych TCP u nadawcy wyznacza mniejsze z okna odbiorczego i okna przeciążenia, a także inne ograniczenia. To ważne rozróżnienie: wystarczająco duże okno odbiorcze nie gwarantuje wysokiej przepustowości, jeśli kontrola przeciążenia lub trasa sieciowa uniemożliwia nadawcy utrzymywanie dostatecznej ilości niepotwierdzonych danych.

Utrata pakietów może zmniejszać przepustowość TCP, wymuszając retransmisje i skłaniając nadawcę do zmniejszenia okna przeciążenia. Na łączu o dużym opóźnieniu informacje zwrotne i przywrócenie transmisji mogą trwać dłużej, więc samo duże okno odbiorcze może nie wystarczyć do utrzymania szybkich transferów.

Rzeczywisty przykład od użytkownika subreddita GL.iNet

Użytkownik subreddita GL.iNet przebywający w Wietnamie podał następujące wyniki po połączeniu ze swoim domowym serwerem WireGuard w Teksasie, działającym na routerze GL.iNet Flint 2.

• Lokalizacja serwera: Teksas, USA
  
  • Prędkości lokalne (symetryczne łącze światłowodowe) 700 Mbps pobierania / 940 Mbps wysyłania
• Lokalizacja klienta: Wietnam
  
  • Prędkości lokalne (bez VPN): 455 Mbps pobierania / 634 Mbps wysyłania
    
  • Prędkości lokalne (z włączonym klientem WireGuard VPN): 47.3 Mbps pobierania / 12.1 Mbps wysyłania, ping 288 ms

Pamiętaj, że podczas pobierania przez domowy serwer VPN maksymalna przepustowość pobierania zależy również od prędkości wysyłania domowego łącza internetowego.

Pomiary pokazują znaczną różnicę między lokalną wydajnością internetu a wydajnością międzynarodowego połączenia WireGuard. Testy nie muszą jednak mierzyć równoważnych tras sieciowych. Lokalny test w Wietnamie może korzystać z pobliskiego serwera, podczas gdy ruch przez VPN musi najpierw pokonać połączenie międzynarodowe do Teksasu. Oznacza to inne sieci tranzytowe operatorów, umowy peeringowe i potencjalne punkty przeciążenia. Dwa połączenia międzynarodowe o podobnym opóźnieniu mogą oferować bardzo różne prędkości zależnie od jakości tras. Choć VPN zgłaszał RTT około 288 ms, sam ten pomiar nie dowodzi, że opóźnienie było główną przyczyną spadku przepustowości. Mogły przyczynić się do tego utrata pakietów, nieefektywny routing międzynarodowy, przeciążenie lub inne czynniki.

Najpierw wskażmy kilka typowych czynników wpływających na przepustowość sieci:

1. Wahania wydajności operatora i przeciążenie sieci w okolicy: Przepustowość może znacznie się zmieniać zależnie od przeciążenia i obciążenia sieci.
2. Wydajność Wi-Fi: Bardzo zmienna w zależności od otoczenia fizycznego, zakłóceń od innych urządzeń bezprzewodowych, możliwości urządzenia klienckiego oraz z natury półdupleksowego działania Wi-Fi, w odróżnieniu od pełnego dupleksu Ethernetu
   • Szczegółowe wyjaśnienie rzeczywistej wydajności Wi-Fi znajdziesz tutaj: https://www.wiisfi.com/
3. Routing operatorów i peering międzynarodowy: Ruch między krajami może przechodzić przez wiele niezależnie zarządzanych sieci. Przeciążone łącza peeringowe, nieefektywne trasy lub utrata pakietów mogą znacznie ograniczyć przepustowość, nawet jeśli oba końce mają szybki lokalny internet. Dwie trasy międzynarodowe o podobnym RTT mogą zapewniać bardzo różne prędkości.

Przeciążenie lokalnego operatora i warunki routingu międzynarodowego są zwykle poza bezpośrednią kontrolą użytkownika, choć testowanie innych operatorów lub tras może ujawnić różnice wydajności. Gdy oba końce mają szybki lokalny internet, ale trasa dalekiego zasięgu jest wolna, często podejrzewa się słaby routing międzynarodowy lub przeciążony peering. Test u innego operatora, na przykład w kawiarni, lub przez hotspot może pomóc ustalić, czy spowolnienie występuje na trasie. Ograniczenia Wi-Fi można często zmniejszyć, używając przewodowego Ethernetu wszędzie, gdzie to możliwe. Przy diagnozowaniu przepustowości VPN warto też zbadać ograniczenia przetwarzania routera i problemy z MTU.

Ostatecznie ustalenie przyczyny wolnego międzynarodowego VPN wymaga odróżnienia ograniczeń trasy sieciowej, routera VPN i aplikacji komunikujących się przez tunel.

Skalowanie okna TCP dla lepszej wydajności

Pierwotnie okno odbiorcze TCP było ograniczone do około 64 KB. Skalowanie okna (RFC 7323) podnosi limit do około 1 GiB, a nowoczesne systemy operacyjne automatycznie dostrajają okno. Na przykład udokumentowane przez Microsoft ustawienie automatycznego dostrajania Normal może reprezentować okna odbiorcze o wielkości około 16.8 MB. Nowoczesne połączenia TCP nie są więc z natury ograniczone do 64 KB.

Źródło: duckware.com/blog/how-windows-is-killing-internet-download-speeds

Jak limity okna TCP oddziałują z RTT

Dla połączenia TCP ze stałym limitem niepotwierdzonych danych przybliżony pułap przepustowości wynikający z okna to:

Przepustowość w bitach na sekundę ≈ Limit okna w bajtach × 8 ÷ RTT w sekundach

Przy stałym limicie okna wyższy RTT oznacza niższy pułap wynikający z okna. Poniższe przykłady ilustrują tę zależność; nie są prognozami rzeczywistej przepustowości VPN.

Teoretyczne pułapy wynikające z okna (okno ÷ RTT), przy 1 MB = 1,000,000 bajtów. Są to ilustracje, a nie prognozy rzeczywistej przepustowości VPN.

Rzeczywista przepustowość zależy także od kontroli przeciążenia, utraty pakietów, dostępnego pasma i ograniczeń przetwarzania. Wiele połączeń TCP może czasem osiągnąć wyższą przepustowość łączną, lecz nie istnieje uniwersalny próg RTT, powyżej którego nie mogą wykorzystać całego dostępnego pasma.

W przykładzie Wietnam–Teksas hipotetyczne pojedyncze połączenie TCP ograniczone do 2 MB niepotwierdzonych danych przy RTT 288 ms miałoby pułap wynikający z okna około 55.6 Mbps. Wiersz 300 ms w tabeli ma nieco niższą wartość ze względu na wyższy RTT. Nie wyjaśnia to jednak, dlaczego użytkownik zmierzył 47.3 Mbps.

Bez znajomości liczby połączeń w teście, rzeczywistych okien TCP i warunków sieciowych nie można ustalić, czy wąskim gardłem był limit okna, przeciążenie, utrata pakietów, routing operatora czy coś innego.

Co decyduje o wielkości okna TCP?

Rozmiary okien TCP są przypisane do poszczególnych połączeń i mogą zmieniać się podczas przesyłania danych. Dlatego powyższych wartości przykładowych nie należy traktować jako stałych ustawień obowiązujących dla każdego połączenia na urządzeniu.

Oknem odbiorczym zarządza system operacyjny urządzenia odbierającego. Jego rozmiar zależy między innymi od wolnego miejsca w buforze odbiorczym, automatycznego dostrajania i limitów systemu, ustawień aplikacji oraz tempa przetwarzania napływających danych przez aplikację. Gdy pobierasz plik na laptop, laptop ogłasza serwerowi wysyłającemu swoje okno odbiorcze. Podczas wysyłania serwer odbierający ogłasza swoje okno laptopowi.

Nadawca osobno zarządza oknem przeciążenia zgodnie ze swoim algorytmem kontroli przeciążenia i informacjami zwrotnymi z sieci. Może to ograniczać ilość niepotwierdzonych danych nawet wtedy, gdy odbiorca ogłasza duże okno. W typowej konfiguracji WireGuard między routerami okna TCP należą do komunikujących się komputerów i serwerów; nie są jednym ustawieniem rozmiaru okna na routerach VPN.

Jak sprawdzić rzeczywiste połączenie?

Osoby zaznajomione z analizą pakietów mogą wyświetlić ogłaszane okno odbiorcze TCP w Wireshark. W konfiguracji między routerami przechwytuj ruch na komputerze wykonującym transfer. Uruchom przechwytywanie przed nawiązaniem nowego połączenia TCP, aby Wireshark zarejestrował początkowy handshake i negocjację skalowania okna. Podczas pobierania sprawdź wychodzące z komputera potwierdzenie TCP dla tego transferu, rozwiń sekcję Transmission Control Protocol i poszukaj Calculated window size. Pokazuje to okno odbiorcze ogłoszone przez komputer w danym momencie, ze skalowaniem, jeśli Wireshark zna wynegocjowany współczynnik skali.

Wartość ta może zmieniać się w trakcie transferu. Nie ujawnia bezpośrednio okna przeciążenia nadawcy ani nie dowodzi, że okno odbiorcze ogranicza wydajność. Sprawdzenie ustawienia automatycznego dostrajania systemu operacyjnego również nie pokazuje rzeczywistego okna ogłaszanego aktualnie przez konkretne połączenie.

Kolejny przykład z praktyki: większa prędkość bez niższego pingu

W innym zgłoszeniu pomocy technicznej badałem wolne połączenie VPN Tailscale. Tailscale używa szyfrowania WireGuard, ale jego opcje przekaźników mogą inaczej transportować zaszyfrowane pakiety: przekaźniki DERP korzystają z połączeń TCP, a Tailscale Peer Relays z UDP. Różni się to od samodzielnego połączenia WireGuard, które zwykle wysyła zaszyfrowane pakiety bezpośrednio przez UDP. W tym przypadku oba przekaźniki były samodzielnie hostowane na tej samej instancji AWS Lightsail, więc porównanie dotyczyło dwóch prywatnie hostowanych metod przekazywania, a nie publicznych serwerów DERP Tailscale.

Łącze internetowe klienta osiągało w teście około 83 Mbps, a zmierzona prędkość wysyłania łącza serwera VPN wynosiła około 40.6 Mbps. Zaobserwowano następujące prędkości pobierania:

SQM oznacza Smart Queue Management, funkcję routera służącą do zarządzania kolejkami pakietów i ograniczania nadmiernych opóźnień pod obciążeniem. W tym porównaniu SQM włączano lub wyłączano na routerze podróżnym po stronie klienta.

SQM nie jest uniwersalnym rozwiązaniem problemu niskiej prędkości VPN. Gdy widzi tylko jeden zaszyfrowany przepływ tunelowy, nie może oddzielnie nadawać priorytetów połączeniom aplikacji ukrytym w jego wnętrzu. Nadal może zarządzać wspólną kolejką pakietów, ale zmniejsza to opóźnienia w kolejce tylko wtedy, gdy nadmierne kolejkowanie jest problemem, któremu SQM może zaradzić. Jeśli nie występuje nadmierne kolejkowanie, które SQM może skutecznie kontrolować, niepotrzebnie restrykcyjne ustawienia przepustowości lub dodatkowy narzut przetwarzania mogą obniżyć przepływność bez poprawy responsywności.

Opóźnienie pozostało niemal niezmienione, a mimo to przekaźnik oparty na UDP zapewniał znacznie wyższą przepustowość zarówno z włączonym, jak i wyłączonym SQM. Największej poprawie towarzyszyła zmiana metody przekazywania, a nie zmniejszenie pingu czy wyłączenie SQM.

Jednym z możliwych czynników jest transport DERP oparty na TCP. Każde urządzenie Tailscale łączy się z przekaźnikiem DERP przez TCP, więc zaszyfrowane pakiety przechodzą przez oddzielne połączenia TCP po obu stronach przekaźnika. Wiele połączeń aplikacji w tunelu może współdzielić te zewnętrzne połączenia TCP. Jeśli dane zostaną utracone na zewnętrznym połączeniu TCP, późniejsze dane mogą czekać na retransmisję przed dostarczeniem, co potencjalnie opóźnia kilka aplikacji naraz. Peer Relay oparty na UDP unika tej dodatkowej warstwy uporządkowanego transportu TCP, choć aplikacje TCP w tunelu nadal używają własnych potwierdzeń i kontroli przeciążenia.

Ponieważ oba przekaźniki działały na tej samej instancji, host i lokalizacja pozostawały stałe. Wzmacnia to interpretację, że do poprawy przyczynił się transport lub implementacja przekaźnika, a nie samo przeniesienie go bliżej użytkowników. Ten sam host nie gwarantuje jednak identycznych tras ani warunków sieciowych, więc porównanie nie wyodrębnia TCP względem UDP jako jedynej przyczyny.

Są to obserwacje z jednego zgłoszenia pomocy technicznej, a nie gwarantowane wyniki wydajności. Pokazują jednak, dlaczego samo opóźnienie nie wystarcza do przewidzenia prędkości VPN.

Podsumowanie

Mam nadzieję, że artykuł wyjaśnił, dlaczego prędkości pobierania i wysyłania przez dalekosiężne połączenia VPN WireGuard mogą być znacznie niższe niż prędkości internetu dostępne na obu końcach. Najważniejsze rozróżnienie polega na tym, że sam WireGuard nie narzuca pułapu przepustowości zależnego od RTT. Jego transport danych oparty na UDP nie implementuje dla zwykłych pakietów danych okien przeciążenia, potwierdzeń ani retransmisji charakterystycznych dla TCP.

Jednak aplikacje TCP i QUIC komunikujące się przez tunel nadal podlegają własnym mechanizmom kontroli przeciążenia i niezawodności. Wyższy RTT zwiększa ilość niepotwierdzonych danych potrzebną do utrzymania danej przepustowości. Wiele połączeń może poprawić wydajność łączną, lecz ani RTT, ani liczba połączeń nie wyznaczają samodzielnie osiągalnej prędkości. Rzeczywista wydajność zależy też od utraty pakietów, przeciążenia sieci, routingu i peeringu operatorów, dostępnego pasma, konfiguracji MTU i mocy obliczeniowej routera VPN.

W typowej konfiguracji WireGuard między routerami GL.iNet połączenia TCP są nawiązywane między urządzeniami końcowymi a serwerami docelowymi. Routery VPN szyfrują, odszyfrowują i przekazują pakiety bez bezpośredniego sterowania oknami odbiorczymi TCP tych połączeń end-to-end. Ograniczenia sprzętowe routera mogą wpływać na przepustowość zaszyfrowanych pakietów, ale nie należy mylić ich z ograniczeniami okna odbiorczego TCP.

Diagnozując wolne międzynarodowe połączenie WireGuard, zacznij od sprawdzenia internetu w obu lokalizacjach, używając w miarę możliwości przewodowego Ethernetu. Sprawdź, czy wydajność VPN zmienia się o różnych porach dnia lub po użyciu innego łącza, na przykład hotspotu komórkowego. Takie porównania mogą pomóc zawęzić miejsce spowolnienia, choć ustalenie przyczyny może wymagać dokładniejszych testów. Duże opóźnienie może spowalniać aplikacje, lecz nie powinno być automatycznie uznawane za jedyne wyjaśnienie wolnego VPN.

W przyszłości zamierzam eksperymentować ze strategicznie rozmieszczonymi przekaźnikami UDP, aby sprawdzić, czy alternatywne trasy mogą poprawić wydajność VPN WireGuard między USA a Azją.

Więcej informacji i wskazówek dotyczących rozwiązywania problemów oraz konfiguracji WireGuard VPN znajdziesz w następującym wpisie na forum GL.iNet: https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502