Dlaczego do serwerów w UE jest wolniej niż w Speedteście?

To znajoma sytuacja. Speedtest pokazuje 600/700 Mb/s, a mimo to realna prędkość podczas pracy z serwerami w UE nigdy nie przekracza 20 Mb/s. Liczby różnią się dziesięciokrotnie albo bardziej, co rodzi zrozumiałe pytania. Poniżej wyjaśniamy szczegółowo, dlaczego tak się dzieje, i pokazujemy, że przyczyna niemal zawsze leży po stronie łączy szkieletowych operatora, a nie po stronie Twojego sprzętu czy naszej usługi.

W skrócie

Speedtest i realne połączenie z odległym serwerem mierzą zupełnie różne rzeczy. Speedtest sprawdza czystą przepustowość lokalnego łącza na bardzo krótkiej trasie. Praca z serwerami w UE zależy natomiast od opóźnienia, stanu łączy międzynarodowych i jakości trasy. Wysoki wynik Speedtestu potwierdza więc, że łącze działa prawidłowo, a niska prędkość do UE wynika z fizyki dalekich połączeń oraz obciążenia sieci tranzytowych.

Co naprawdę mierzy Speedtest

Speedtest jest tak zaprojektowany, aby pokazać najwyższą możliwą liczbę, dlatego jego wynik tylko częściowo odzwierciedla realną pracę z odległymi serwerami.

1. Wybiera najbliższy serwer. Speedtest automatycznie dobiera serwer o najmniejszym opóźnieniu, a zwykle jest to serwer w sieci samego operatora albo w tym samym mieście. Ruch do niego biegnie krótką trasą i w ogóle nie dotyka łączy międzynarodowych.
2. Otwiera wiele równoległych połączeń. Speedtest uruchamia kilka jednoczesnych strumieni TCP (zazwyczaj od 4 do 16) i sumuje ich prędkość. W ten sposób omija ograniczenie, na które pojedyncze połączenie natrafia na długich trasach (więcej o tym za chwilę). Realne aplikacje często pracują przez jedno połączenie lub kilka, więc tego przyspieszenia nie otrzymują.
3. Opóźnienie jest minimalne. Na krótkiej trasie czas obiegu (RTT) wynosi zaledwie kilka milisekund, dzięki czemu TCP zdąża rozpędzić się do pełnej prędkości łącza.

W efekcie Speedtest pokazuje "laboratoryjną" przepustowość łącza, a nie prędkość, jaką faktycznie uzyskasz przy wymianie danych z serwerem w innym kraju.

Główna przyczyna: iloczyn pasma i opóźnienia oraz okno TCP

To kluczowy moment techniczny i to on wyjaśnia większość różnicy.

TCP wysyła dane w "oknach". Nadawca przesyła porcję danych, po czym czeka na potwierdzenie odbioru, zanim ruszy dalej. Maksymalna prędkość pojedynczego połączenia TCP wynika z prostego wzoru:

Prędkość = Rozmiar okna / Opóźnienie (RTT)

Aby w pełni wypełnić łącze, okno musi być co najmniej tak duże jak tzw. iloczyn pasma i opóźnienia (BDP):

BDP = Przepustowość × RTT

Policzmy to dla łącza 600 Mb/s przy opóźnieniu do serwera w UE rzędu 50 ms:

BDP = 600 000 000 bit/s × 0,05 s = 30 000 000 bitów = 3,75 MB

Oznacza to, że aby nasycić łącze, w danej chwili w "locie" musi znajdować się około 3,75 MB danych. Jeśli jednak jedna strona utknęła na starym lub ograniczonym rozmiarze okna (klasyczne 64 KB bez skalowania okna), górny pułap dla pojedynczego połączenia wynosi:

Prędkość = 65 536 bajtów × 8 bit / 0,05 s ≈ 10,5 Mb/s

Właśnie dlatego pojedyncze połączenie z odległym serwerem zatrzymuje się na 10 do 20 Mb/s, nawet gdy samo łącze obsługuje setki megabitów. Na krótkiej trasie (RTT 2 ms) to samo okno dałoby ponad 260 Mb/s, i właśnie dlatego problem nigdy nie ujawnia się w Speedteście. Im wyższe opóźnienie, tym silniejszy efekt, a to nie usterka sprzętu, lecz fundamentalna właściwość protokołu.

Opóźnienie (RTT) i fizyka długich łączy

Opóźnienie na długich trasach składa się z kilku elementów, a części z nich nie da się usunąć w ogóle.

Światło biegnie w światłowodzie z prędkością około 200 000 km/s, czyli zauważalnie wolniej niż w próżni, ponieważ spowalnia je współczynnik załamania szkła. Każdy tysiąc kilometrów trasy dodaje około 5 ms w jedną stronę, czyli mniej więcej 10 ms na drogę tam i z powrotem. Co więcej, realna trasa rzadko biegnie po linii prostej, więc zwykle jest dłuższa od odległości geograficznej.

Do tego dochodzi opóźnienie na każdym węźle pośrednim (routerze): przetworzenie pakietu, ustawienie go w kolejce i przekazanie dalej. Na drodze do serwera w UE takich węzłów (przeskoków) jest zazwyczaj od 10 do 20, a każdy dokłada swoją część. Im wyższe końcowe RTT, tym niższy pułap dla pojedynczego połączenia zgodnie z powyższym wzorem.

Utrata pakietów i jej wpływ na TCP

Nawet niewielka utrata pakietów na łączu międzynarodowym gwałtownie obniża osiąganą prędkość. TCP odczytuje utracony pakiet jako oznakę przeciążenia, więc w odpowiedzi zwalnia, a potem ponownie buduje prędkość. Zależność opisuje równanie Mathisa:

Prędkość ≈ MSS / (RTT × √p)

Tutaj MSS to maksymalny rozmiar segmentu (zwykle około 1460 bajtów), RTT to opóźnienie, a p to udział utraconych pakietów. Wzór pokazuje, że prędkość spada odwrotnie do pierwiastka ze współczynnika strat i zależy wprost od opóźnienia.

W praktyce wygląda to dramatycznie. Przy RTT 50 ms i standardowym MSS już 0,1% strat ogranicza pojedyncze połączenie do około 73 Mb/s, 1% strat sprowadza je do mniej więcej 23 Mb/s, a 2% strat poniżej 17 Mb/s. Na długich trasach tranzytowych straty rzędu 1 do 2% w godzinach szczytu to rzecz zupełnie normalna i często główny ogranicznik.

Trasowanie i peering

Droga Twojego ruchu do serwera w UE nie jest bezpośrednia. Biegnie przez łańcuch operatorów i protokół trasowania BGP, który wybiera trasę według kryteriów handlowych i technicznych, a nie według najkrótszej odległości.

Rodzi to kilka typowych problemów. Trasa może biec nieoptymalnie, na przykład przez kraj trzeci, co podnosi zarówno opóźnienie, jak i ryzyko strat. Ruch przechodzi przez styki między sieciami (punkty peeringu i łącza tranzytowe), a jeśli któryś ze styków jest przeciążony, prędkość spada właśnie tam. Częste jest też trasowanie asymetryczne, w którym pakiety w jedną i drugą stronę biegną różnymi drogami, co utrudnia diagnozę. A u tanich operatorów łączność międzynarodowa bywa kupowana "z resztek", przez co jej pojemność nie wystarcza w godzinach szczytu.

Przeciążenie międzynarodowych łączy operatora

Ruch lokalny (w obrębie miasta i kraju) ma u większości operatorów spory zapas, dlatego Speedtest do bliskiego serwera zawsze pokazuje wysoką liczbę. Łącza międzynarodowe są natomiast droższe i kupowane w ograniczonej ilości. W wieczornym szczycie, gdy obciążenie jest największe, to właśnie te łącza stają się wąskim gardłem. To wyjaśnia, dlaczego prędkość do UE potrafi zauważalnie wahać się w ciągu doby, podczas gdy lokalny Speedtest pozostaje stale wysoki.

Dodatkowe czynniki techniczne

Poza głównymi przyczynami na prędkość do odległego serwera wpływa jeszcze kilka rzeczy.

MTU i fragmentacja. Jeśli MTU na trasie jest mniejsze, niż się spodziewano, pakiety ulegają fragmentacji, co obniża wydajność. Błędnie skonfigurowane PMTUD (wykrywanie MTU wzdłuż ścieżki) może prowadzić do "czarnych dziur" i zawieszania transmisji.

Bufferbloat (rozdęcie buforów). Przewymiarowane bufory na węzłach pośrednich podnoszą opóźnienie pod obciążeniem i dezorientują mechanizmy kontroli przepływu TCP, jeszcze bardziej obniżając realną prędkość.

Kształtowanie i priorytetyzacja (QoS). Część operatorów celowo dławi ruch międzynarodowy lub określony rodzaj ruchu albo obniża mu priorytet, co bezpośrednio wpływa na prędkość.

Narzut protokołów. Nagłówki TCP, IP i szyfrowania (TLS) zajmują część pasma. Na krótkiej trasie jest to niewidoczne, ale w połączeniu ze stratami i opóźnieniem na długiej trasie sumuje się.

Twoje środowisko lokalne. Wi-Fi zamiast kabla, przeciążony router domowy, antywirus lub VPN na urządzeniu również potrafią obniżyć realną prędkość, dlatego przy diagnozie warto je wykluczyć.

Dlaczego to nie wina sprzętu ani usługi

Wysoki wynik Speedtestu to jednoznaczny dowód, że Twój sprzęt, okablowanie i łącze lokalne działają prawidłowo i dostarczają należnej prędkości. Spadek podczas pracy z serwerami w UE bierze się z opóźnienia na długiej trasie, z ograniczenia okna pojedynczego połączenia TCP, z utraty pakietów i ze stanu łączy międzynarodowych operatora. Wszystkie te czynniki leżą poza naszą usługą i poza Twoim sprzętem: dotyczą odcinka sieci między operatorem a operatorami szkieletowymi.

Jak sprawdzić to samodzielnie

Aby potwierdzić przyczynę, wykonaj kilka prostych kontroli.

1. Uruchom Speedtest ręcznie i wybierz serwer w odpowiednim kraju UE (na przykład w Niemczech lub Holandii, gdzie znajdują się nasze serwery). Pokaże to realną prędkość dokładnie na tej trasie, która jest używana w praktyce, a nie do najbliższego serwera lokalnego.
2. Prześledź trasę. Polecenie tracert (Windows) lub traceroute (macOS, Linux) do naszego serwera pokazuje łańcuch węzłów i opóźnienie na każdym z nich. Do przejrzystej diagnozy strat i opóźnienia świetnie nadaje się narzędzie mtr (lub WinMTR w Windows), które najlepiej zostawić uruchomione przez kilka minut w godzinach szczytu.
3. Porównaj jedno połączenie z wieloma. Jeśli pobieranie wielostrumieniowe jest szybkie, a pojedynczy strumień wolny, potwierdza to wprost ograniczenie okna TCP na długiej trasie.
4. Jeśli masz możliwości techniczne, użyj iperf3, aby zmierzyć przepustowość do odległego węzła wprost, zarówno jednym, jak i wieloma strumieniami.

Co zrobić

Jeśli kontrole wykażą wysokie opóźnienie lub utratę pakietów na odcinku międzynarodowym, warto skontaktować się z operatorem z konkretnymi danymi: śladem trasy i pomiarem mtr z podaną porą dnia. Korekta trasy lub rozbudowa łączności międzynarodowej leży po stronie operatora. Z naszej strony chętnie udostępnimy adresy naszych serwerów do precyzyjnej diagnozy i pomożemy zinterpretować wyniki.

Podsumowanie

Wynik Speedtestu 600/700 Mb/s potwierdza, że łącze działa prawidłowo. Spadek do 20 Mb/s podczas pracy z serwerami w UE jest do przewidzenia i wynika z opóźnienia na długiej trasie, z ograniczenia okna pojedynczego połączenia TCP, z utraty pakietów oraz z obciążenia łączy międzynarodowych operatora. Nie ma to związku z Twoim sprzętem ani z naszą usługą, a dokładną przyczynę można ustalić prostą diagnozą trasy.

Aktualizowane na: 21/06/2026