Sytuacja z życia: „Internet muli”, czyli skąd w ogóle zacząć diagnozę
Wieczór, serial w 4K buforuje, rozmowa na Teams rwie się co chwila, a dzieci krzyczą z pokoju obok, że „ping do serwera gry skacze jak szalony”. Modem świeci normalnie, router „jak zwykle”, w telefonie LTE śmiga, tylko domowy internet „muli”. Pytanie nie brzmi „czy coś jest nie tak”, tylko gdzie dokładnie jest problem.
Właśnie w takich scenariuszach narzędzia ping, traceroute i mtr robią największą robotę. Pozwalają przejść od ogólnego narzekania „internet nie działa” do konkretu: czy problem leży w domowej sieci Wi‑Fi, kablu do routera, w łączu operatora, w trasie między operatorami, czy już po stronie serwera docelowego. Dają dane, które można samemu zinterpretować albo przekazać administratorowi czy supportowi dostawcy internetu zamiast ogólnego „coś nie działa”.
Odróżnienie problemu lokalnego od zewnętrznego
Na samym początku dobrze jest przyjąć prostą logikę: najpierw wyklucza się własne podwórko, potem dopiero „obwinia się” operatora czy serwer. Lokalny problem to na przykład:
- słaby sygnał Wi‑Fi (duża odległość, kilka ścian po drodze),
- wadliwy lub za długi, marny kabel Ethernet,
- stary router, który dusi się przy większym ruchu,
- jedno urządzenie w sieci generuje ogromny upload (np. backup w chmurze) i zapycha łącze.
Problem zewnętrzny to już kwestia, której nie naprawi się samym restartem routera: awaria w sieci operatora, przeciążenie węzłów tranzytowych, błędny routing między operatorami, problemy z serwerem w innym kraju czy kontynencie. Ping, traceroute i mtr pomagają zobaczyć, gdzie po drodze rośnie opóźnienie, gdzie pojawia się utrata pakietów i na którym odcinku trasy występują zjawiska typu przeciążenie łącza lub niestabilny routing.
Dlaczego ping, traceroute i mtr to pierwsza linia diagnostyki
Domowe „magiczne” rytuały typu restart routera czasem przypadkiem rozwiązują problem, ale nie dają żadnej wiedzy. Z kolei prosta sekwencja testów na bazie ping i traceroute daje w kilka minut odpowiedzi, które pozwalają:
- zawęzić obszar problemu: lokalnie, u operatora, po stronie zewnętrznego serwera,
- zobaczyć, czy chodzi o opóźnienia (wysoki RTT), czy o utratę pakietów,
- zidentyfikować, czy problem występuje stale, czy tylko okresowo (szczególnie mtr),
- sprawdzić, czy DNS działa i nie jest dodatkowym źródłem kłopotów.
Ping daje szybki wgląd w czy coś odpowiada i jak długo. Traceroute pokazuje jaką drogą to idzie. Mtr łączy oba podejścia, aktualizując dane w czasie rzeczywistym i pokazując stabilność trasy. Razem tworzą solidny zestaw do diagnostyki sieci krok po kroku, zanim ktokolwiek podniesie słuchawkę do BOK operatora.
Bez danych nie ma sensownej diagnozy
Najczęstszy błąd: zgłoszenie „internet działa wolno” bez jakichkolwiek pomiarów. Administrator i tak zacznie od tych samych testów: ping do bramy, traceroute do problematycznego hosta, analiza opóźnień i utraty pakietów, często mtr diagnostyka w czasie rzeczywistym. Mając zrobione te kroki samodzielnie, można:
- kulturalnie, ale konkretnie rozmawiać z supportem („ping do waszej bramy 100 ms i 20% loss, do 1.1.1.1 też źle”),
- odróżnić problem globalny od lokalnego błędu w konfiguracji sieci,
- uniknąć pochopnych wniosków w stylu „serwer jest zły”, gdy winny jest router Wi‑Fi za ścianą.
Przyjęcie zasady „najpierw pomiary, potem opinie” drastycznie skraca czas dochodzenia do źródła kłopotów, a ping, traceroute i mtr są najprostszymi narzędziami, żeby te pomiary wykonać w domowych warunkach.
Podstawy protokołu IP i ICMP – co tak naprawdę mierzą ping i traceroute
Żeby poprawnie zinterpretować wyniki diagnostyki sieci, trzeba z grubsza rozumieć, co dzieje się z pakietem po drodze. Bez tego nietrudno o błędne wnioski: „ten router ma ping 200 ms, więc jest zepsuty” albo „tu są gwiazdki, więc ten hop nie działa”, podczas gdy wszystko może być w normie.
Pakiety IP, TTL i rola routerów
Transport w internecie odbywa się na poziomie pakietów IP. Każdy taki pakiet ma adres źródłowy, adres docelowy, a w nagłówku między innymi pole TTL (Time To Live) w IPv4 lub Hop Limit w IPv6. Ten parametr jest kluczowy dla działania traceroute.
TTL to liczba „skoków” (hopów), które pakiet może pokonać, zanim zostanie odrzucony. Każdy router po drodze zmniejsza TTL o 1. Gdy wartość TTL spadnie do zera, router odrzuca pakiet i – jeśli jest tak skonfigurowany – wysyła nadawcy komunikat ICMP „Time Exceeded”. Dzięki temu internet nie zatyka się pakietami krążącymi wiecznie w pętli routingu.
Routery nie zaglądają w dane użytkownika (np. zawartość strony WWW), ale na podstawie tablic routingu decydują, w którą stronę przesłać kolejny pakiet. Każdy taki przeskok między urządzeniami warstwy 3 (routerami, czasem firewallami) to osobny hop widoczny w traceroute/mtr. Zrozumienie tej „sztafety” pozwala lepiej odczytywać analizę trasy i problemy z routingiem.
ICMP – komunikaty diagnostyczne
ICMP (Internet Control Message Protocol) to protokół pomocniczy wobec IP, używany głównie do komunikatów błędów oraz diagnostyki. Najważniejsze typy komunikatów ICMP z punktu widzenia ping i traceroute to:
- Echo Request / Echo Reply – na tym opiera się ping; host otrzymuje żądanie, ma odpowiedzieć odpowiedzią z powrotem,
- Time Exceeded – wysyłany, gdy pakietowi IP skończy się TTL / Hop Limit zanim dotrze do celu; na tym opiera się traceroute,
- Destination Unreachable – informacja, że pakiet nie może być dostarczony (np. host nieosiągalny, usługa portu zablokowana, sieć niedostępna).
To właśnie na ICMP opiera się większość klasycznych narzędzi linii komend do sieci. Warto mieć z tyłu głowy, że ICMP nie jest protokołem „aplikacyjnym” jak HTTP, tylko niskopoziomowym, informacyjnym.
Dlaczego nie każdy host musi odpowiadać na ICMP
Coraz częściej administratorzy ograniczają ruch ICMP albo w ogóle blokują odpowiedzi pingowe z serwerów i routerów. Powody są różne: względy bezpieczeństwa, ochrona przed skanowaniem, ochrona przed atakami typu ping flood. Efekt uboczny jest taki, że w wynikach pojawiają się:
- brak odpowiedzi na ping (100% utraty pakietów),
- gwiazdki w traceroute/mtr dla części hopów,
- komunikaty o przekroczonym czasie oczekiwania, mimo że usługa (np. WWW) działa poprawnie.
To nie zawsze oznacza błąd czy awarię. Często jest to po prostu polityka firewalli. Dlatego sam fakt braku odpowiedzi ICMP nie jest jednoznaczny – kluczowe jest, czy końcowa usługa działa i czy wcześniejsze hopy zachowują się sensownie. ICMP to narzędzie diagnostyczne, ale nie jest gwarantowane ani wymagane do działania większości usług sieciowych.
Różnice między IPv4 i IPv6 w kontekście ping i traceroute
W IPv6 zamiast TTL używa się nazwy Hop Limit, ale logika działania pozostaje praktycznie ta sama: wartość jest dekrementowana na każdym hopie, a po jej wyzerowaniu router generuje ICMPv6 „Time Exceeded”. Różnią się numery typów i kodów ICMP, ale idea jest identyczna.
W praktyce przy diagnostyce:
- w systemach uniksowych używa się zwykle poleceń
pingiping6(lubping -6), - dla traceroute istnieją warianty
tracerouteitraceroute6(lub flaga-6), - adresy IPv6 mogą wyglądać „strasznie” (długie ciągi hex), ale interpretacja opóźnień i utraty pakietów jest taka sama jak w IPv4.
Znajomość podstaw ICMP i mechanizmu TTL/hop limit chroni przed najczęstszą pułapką: utożsamianiem każdego braku odpowiedzi lub wysokiego RTT na pojedynczym hopie z awarią. Wyższy ping do konkretnego routera w traceroute nie musi oznaczać, że pakiety użytkownika są tam opóźniane – router może po prostu priorytetyzować ruch produkcyjny ponad ruch diagnostyczny.
Ping – nie tylko „czy działa internet”, ale jak działa
Ping kojarzy się wielu osobom z prostym „sprawdzę, czy jest internet”. W praktyce to narzędzie potrafi dużo więcej: pozwala ocenić jakość łącza, stabilność opóźnień, obecność utraty pakietów, a nawet wskazać możliwe przeciążenie łącza lub problem z buforbloatem.
Składnia i podstawowe opcje ping w systemach Linux, macOS, Windows
Ping w Linux i macOS
W systemach uniksowych (Linux, macOS, BSD) ping działa domyślnie w trybie ciągłym, wysyłając pakiety do momentu przerwania (Ctrl+C). Podstawowe użycie:
ping 1.1.1.1
ping google.com
Przydatne opcje (mogą się nieznacznie różnić między dystrybucjami):
-c <liczba>– ile pakietów wysłać (np.-c 20),-s <rozmiar>– wielkość danych w bajtach, bez nagłówków (np.-s 1400),-i <sekundy>– odstęp między pakietami (np.-i 0.2),-W <sekundy>– timeout na odpowiedź jednego pakietu,-4lub-6– wymuszenie IPv4 lub IPv6.
Na macOS składnia jest bardzo podobna, choć niektóre flagi mogą mieć inne nazwy lub ograniczenia. Kluczowy jest jednak rezultat: czasy RTT (round-trip time) i statystyki utraty pakietów.
Ping w Windows
W Windows ping domyślnie wysyła 4 pakiety i kończy działanie. Trzeba o tym pamiętać, bo krótkie jednorazowe testy mogą „nie złapać” okresowych problemów z łączem.
ping 1.1.1.1
ping google.com
Przydatne przełączniki w Windows:
-n <liczba>– liczba wysyłanych pakietów (np.ping -n 50 1.1.1.1),-l <rozmiar>– rozmiar bufora (np.-l 1400),-w <czas>– czas oczekiwania na odpowiedź (ms),-4/-6– wymuszenie IPv4/IPv6 (nowsze wersje Windows).
Na Windows brak jest domyślnego trybu „ciągłego” bez limitu, ale można użyć bardzo dużej liczby pakietów lub uruchamiać polecenie wielokrotnie, aby uzyskać podobny efekt obserwacji w czasie.
Jak czytać wyniki ping – RTT, statystyki, utrata pakietów
RTT: min/avg/max i odchylenie
RTT (round-trip time) to czas, jaki pakiet potrzebuje, żeby dotrzeć do celu i wrócić z odpowiedzią. Na końcu działania ping w Linuxie zwykle pojawia się linia w stylu:
rtt min/avg/max/mdev = 10.123/12.456/20.789/3.210 ms
Interpretuje się to następująco:
- min – najniższy zmierzony czas; pokazuje, jak szybko może być w najlepszym wypadku,
- avg – średni RTT; kluczowy wskaźnik opóźnienia,
- max – najwyższy zmierzony czas; wskazuje na możliwe „piki”,
- mdev – „rozrzut” (z grubsza odchylenie); im niższy, tym stabilniejsze łącze.
Dla połączeń lokalnych (w obrębie tej samej sieci operatora) oczekuje się zwykle RTT rzędu pojedynczych–kilkunastu ms. Dla połączeń krajowych – kilkanaście–kilkadziesiąt. Dla międzykontynentalnych – dziesiątki–ponad 100 ms. Wzrost tych wartości sam w sobie nie musi oznaczać awarii, jeśli jest stabilny i uzasadniony odległością oraz trasą.
Utrata pakietów i jitter
Na końcu statystyk ping pojawia się zwykle informacja typu:
Statystyki utraty pakietów
Typowy wynik ping kończy się czymś takim:
10 packets transmitted, 10 received, 0% packet loss, time 9009ms
Ta linia bywa ważniejsza niż same czasy RTT. Kluczowe elementy:
- transmitted – ile pakietów wysłano,
- received – ile z nich wróciło z odpowiedzią,
- packet loss – procent utraconych pakietów (różnica między wysłanymi a odebranymi),
- time – łączny czas trwania testu.
Niewielkie sporadyczne straty (np. 1–2% przy jednorazowym teście) jeszcze nie przesądzają o dramacie, ale regularne 5–10% i więcej przy dłuższym pomiarze to już sygnał problemu. Im dłużej trwa pomiar, tym lepiej widać, czy straty są incydentalne (np. chwilowe przeciążenie Wi‑Fi), czy stałe (np. kiepskie łącze radiowe lub problem po stronie operatora).
W codziennej pracy często widać sytuację, gdzie ping do serwera gier pokazuje 40 ms i 0% strat, ale gracz skarży się na „teleportowanie”. Po wydłużeniu testu do kilkuset pakietów wychodzi na jaw, że co kilkadziesiąty pakiet ginie – przy krótkim pomiarze takie zjawisko łatwo przeoczyć.
Jitter – zmienność opóźnień
Jitter to różnica między kolejnymi czasami RTT, czyli „roztrzęsienie” opóźnień. Nie każdy ping wprost go liczy, ale można go ocenić patrząc na mdev (Linux) albo po prostu obserwując skoki w kolejnych liniach.
Jeśli kolejne odpowiedzi mieszczą się w wąskim zakresie (np. 15–18 ms), łącze jest stabilne. Gdy część odpowiedzi ma 20 ms, a co kilka sekund pojawia się 150–200 ms, pojawia się odczuwalne „szarpanie”. W rozmowach VoIP, wideokonferencjach i grach jitter jest często bardziej dokuczliwy niż sama wartość średniego RTT.
Typowe wzorce w wynikach ping i co z nich wyczytać
Czasem wystarczy kilkanaście sekund patrzenia w ping, żeby z grubsza ocenić, gdzie leży problem. Dobrze jest nauczyć się rozpoznawać kilka powtarzalnych wzorców.
Stały, niski ping bez strat
Wynik w stylu:
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=11.2 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=11.4 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=11.1 ms
...
10 packets transmitted, 10 received, 0% packet loss, time 9000ms
rtt min/avg/max/mdev = 11.1/11.3/11.6/0.2 ms
To wzorcowa sytuacja – stabilne łącze, mały rozrzut czasów, brak strat. Jeśli mimo takiego wyniku „internet muli”, problem zwykle leży albo po stronie konkretnej usługi (np. wolny serwer WWW), albo w lokalnym urządzeniu (przeglądarka, dysk, przeładowany system).
Niskie RTT, ale sporadyczne straty
64 bytes from 8.8.8.8: icmp_seq=5 ttl=116 time=35.4 ms
Request timeout for icmp_seq 6
64 bytes from 8.8.8.8: icmp_seq=7 ttl=116 time=36.1 ms
...
100 packets transmitted, 97 received, 3% packet loss
Takie okresowe „dziury” często pojawiają się na niestabilnym Wi‑Fi, przy przeciążonych punktach dostępowych lub przy lekkich problemach na łączu radiowym/kablowym. Strumieniowanie wideo zwykle to „przełyka”, ale gry online czy zdalny pulpit już nie.
Dobrym testem jest wtedy powtórzenie ping do lokalnego routera (np. 192.168.1.1). Jeśli tam też widać straty – problem jest „u siebie”, a nie w internecie.
Rośnięcie RTT przy większym rozmiarze pakietu
Przydatny test w razie podejrzenia buforbloatu lub problemów z MTU to zmiana rozmiaru pakietu:
ping -c 50 -s 1400 1.1.1.1
ping -c 50 -s 32 1.1.1.1
Jeśli przy małym rozmiarze RTT jest niskie i stabilne, a przy większym wyraźnie rośnie i staje się niestabilne, często oznacza to mocno buforyzujące urządzenie po drodze (np. tani router z domyślnymi ustawieniami QoS albo łącze mobilne). Objawem w życiu codziennym jest nagły skok pingu, gdy ktoś w domu zaczyna wysyłać duże pliki lub odpala aktualizacje gier.
Praktyczne scenariusze użycia ping
Diagnoza: czy problem jest w LAN, czy w internecie
Gdy „internet muli”, pierwsza rzecz to sprawdzić trzy poziomy:
- Ping do lokalnego routera – np.
ping 192.168.1.1lub adres bramy domyślnej zipconfig/ip addr. - Ping do DNS operatora lub publicznego – np.
ping 1.1.1.1,8.8.8.8. - Ping do nazwy domenowej – np.
ping google.com.
Jeśli:
- już do routera są wysokie opóźnienia lub straty – problem jest w LAN (Wi‑Fi, okablowanie, router),
- do routera jest dobrze, ale do 1.1.1.1 źle – problem na łączu do operatora,
- do 1.1.1.1 jest dobrze, a do google.com nie – kłopot z DNS (lokalnym lub operatora).
Taka prosta sekwencja testów pozwala zawęzić miejsce kłopotu, zanim zacznie się dłuższe rozmowy z pomocą techniczną.
Monitorowanie chwilowych „przycinek”
Czasem użytkownik narzeka, że „raz na jakiś czas wszystko staje na kilka sekund”. Wtedy krótki, czteropakietowy ping nic nie pokaże. Przydatne jest dłuższe monitorowanie, np.:
ping -i 0.5 1.1.1.1
W tle można obserwować, czy odpowiadające czasy idą równym rytmem, czy co jakiś czas pojawiają się time‑outy albo 10-krotnie większe wartości. Gdy jednocześnie widać przycinkę w przeglądarce i jednocześnie w konsoli „dziurę” w ping, mamy dowód na problem w łączności, a nie wyłącznie w przeglądarce.
Analiza trasy pakietu za pomocą traceroute
Typowy scenariusz: ping do serwera gier pokazuje nagle 150 ms zamiast 30 ms. Użytkownik zmienia serwer, wyłącza Wi‑Fi, przełącza się na kabel, a ping nadal wysoki. W tym momencie przydaje się zobaczyć, którędy pakiety faktycznie wędrują i gdzie pojawia się dodatkowe opóźnienie.
Podstawowe użycie traceroute / tracert
Traceroute w systemach uniksowych
Klasyczna składnia na Linux/macOS:
traceroute google.com
traceroute 8.8.8.8
Najważniejsze opcje, które przydają się w praktyce:
-n– nie próbuj rozwiązywać nazw DNS (pokazuj tylko adresy IP); przyspiesza i czytelniej pokazuje trasę,-4/-6– wymuszenie IPv4/IPv6,-w <sekundy>– czas oczekiwania na odpowiedź z danego hopu,-m <liczba>– maksymalna liczba hopów (domyślnie zwykle 30).
Przykładowe wywołanie do szybkiej diagnozy:
traceroute -n -4 8.8.8.8
Tracert w Windows
Na Windows odpowiednikiem jest tracert:
tracert google.com
tracert 8.8.8.8
Przydatne przełączniki:
-d– nie rozwiązuj nazw DNS (tylko IP),-h <liczba>– maksymalna liczba skoków,-w <czas>– czas oczekiwania na odpowiedź w milisekundach.
Standardowy test bez zbędnych opóźnień DNS:
tracert -d 8.8.8.8
Jak czytać pojedynczą linię traceroute
Uproszczony przykład z Linux:
1 192.168.1.1 1.123 ms 0.987 ms 1.045 ms
2 10.10.0.1 8.321 ms 7.876 ms 8.012 ms
3 203.0.113.5 15.234 ms 15.567 ms 15.890 ms
4 * * * *
5 8.8.8.8 25.678 ms 25.432 ms 25.345 ms
Co widać w takim fragmencie:
- pierwsza kolumna – numer hopu (kolejny router po drodze),
- druga kolumna – adres IP (czasem również nazwa hosta, jeśli nie użyto
-n/-d), - kolejne kolumny – czasy odpowiedzi na trzy kolejne pakiety wysłane do tego hopu.
Trzy próby na hop pozwalają ocenić nie tylko opóźnienie, ale i jego stabilność. Gdyby np. czas raz był 10 ms, raz 200 ms, a raz zupełny brak odpowiedzi, sugerowałoby to przeciążenie lub filtrację ruchu.
W powyższym przykładzie gwiazdki w wierszu 4 oznaczają, że dany router nie odpowiedział na żaden z trzech pakietów z określonym TTL. Może to wynikać z polityki firewall (blokada ICMP), z przeciążenia lub po prostu braku odpowiedzi ICMP z tej maszyny, mimo że nadal przekazuje ona ruch dalej. Skoro host docelowy (8.8.8.8) odpowiada, ten „ciemny” hop nie jest jeszcze dowodem awarii.
Typowe wzorce w traceroute i co za nimi stoi
Stabilny wzrost opóźnień
Dla zdrowej trasy czasy RTT rosną stopniowo:
1 192.168.1.1 1 ms 1 ms 1 ms
2 10.10.0.1 8 ms 8 ms 9 ms
3 198.51.100.1 15 ms 16 ms 15 ms
4 203.0.113.5 25 ms 24 ms 25 ms
5 8.8.8.8 27 ms 26 ms 27 ms
Każdy kolejny hop dodaje kilka milisekund. Taki obraz pasuje do typowej trasy przez sieć operatora i dalej do innego AS. Jeżeli jednocześnie ping do celu jest stabilny, trudno tu doszukiwać się problemu z routingiem.
Nagły skok czasów na konkretnym hopie
Często pojawia się coś takiego:
1 192.168.1.1 1 ms 1 ms 1 ms
2 10.10.0.1 8 ms 8 ms 9 ms
3 198.51.100.1 80 ms 90 ms 85 ms
4 203.0.113.5 81 ms 82 ms 80 ms
5 8.8.8.8 82 ms 83 ms 81 ms
Skok między hopem 2 a 3 sugeruje, że opóźnienie pojawia się na odcinku łącza między tymi routerami. Może to być np. przejście z sieci lokalnego operatora do sieci szkieletowej, połączenie do innego miasta lub kraju. Jeżeli ping do celu jest stabilny (tu ~80 ms), to jest po prostu fizyczny koszt odległości lub wyboru trasy, a nie awaria.
Dopiero gdy w zmianie trasy występuje duży rozrzut (raz 20 ms, raz 200 ms) albo dodatkowe straty na tym odcinku, można podejrzewać przeciążone łącze lub problem z QoS.
Gwiazdkowe hopy po drodze
Układ typu:
1 192.168.1.1 1 ms 1 ms 1 ms
2 10.10.0.1 8 ms 8 ms 9 ms
3 * * * *
4 203.0.113.5 25 ms 25 ms 24 ms
5 8.8.8.8 27 ms 27 ms 26 ms
Oznacza router, który nie odsyła ICMP „Time Exceeded” albo odpowiada tak rzadko, że traceroute nie złapał odpowiedzi dla żadnej z prób. Kluczowe jest tutaj zachowanie kolejnych hopów: jeśli późniejsze routery odpowiadają stabilnie, a host docelowy działa, gwiazdki można uznać za kosmetyczne.
Gorzej, gdy gwiazdkowe hopy zaczynają się od jakiegoś miejsca i nie ma odpowiedzi z dalszej trasy ani z hosta docelowego – wtedy jest duża szansa, że pakiety faktycznie nie dochodzą (np. problem w sieci innego operatora, odcięta trasa, błąd konfiguracji).
Zmiana trasy w czasie
Zmiana trasy w ciągu dnia
Czasem gracz zauważa, że rano do ulubionego serwera ma 35 ms, a wieczorem nagle 80–100 ms. Router w domu ten sam, operator ten sam, a odczucie „lagu” zupełnie inne. Źródłem bywa zmiana trasy w sieci operatora, zwykle związana z obciążeniem lub przełączeniem łączy międzywęzłowych.
Typowy obraz w logach z kolejnych traceroute wykonanych co kilka minut:
# 18:05
1 192.168.1.1 1 ms 1 ms 1 ms
2 10.10.0.1 7 ms 8 ms 7 ms
3 198.51.100.1 15 ms 16 ms 15 ms
4 203.0.113.5 25 ms 24 ms 25 ms
5 203.0.113.9 34 ms 35 ms 34 ms
6 192.0.2.10 35 ms 35 ms 35 ms
# 20:20
1 192.168.1.1 1 ms 1 ms 1 ms
2 10.10.0.1 8 ms 8 ms 8 ms
3 198.51.100.2 40 ms 42 ms 41 ms
4 198.51.100.50 70 ms 71 ms 72 ms
5 203.0.113.20 82 ms 83 ms 82 ms
6 192.0.2.10 84 ms 85 ms 83 ms
W pierwszym pomiarze trasa jest krótka, w drugim – ruch przeskakuje przez inne węzły. Nie musi oznaczać to awarii. Sieci szkieletowe dynamicznie równoważą ruch pomiędzy wieloma łączami, a protokoły routingu (np. BGP) podejmują decyzje według złożonych polityk biznesowo‑technicznych.
Jeśli taka zmiana trasy utrzymuje się tygodniami, dochodzą jeszcze kwestie umów między operatorami (peering, tranzyt). Z punktu widzenia użytkownika jest to po prostu „internet dziś wolniej reaguje”, mimo że żadna pojedyncza maszyna nie jest uszkodzona.
„Zły” hop z wysokim RTT, ale dobrym celem
Niejedna osoba wpada w pułapkę reinterpretacji: widzi w środku traceroute hop z 300 ms, a dalej – 40 ms, więc zgłasza awarię na „uszkodzonym routerze”. Przykład:
1 192.168.1.1 1 ms 1 ms 1 ms
2 10.10.0.1 7 ms 7 ms 8 ms
3 198.51.100.1 300 ms 310 ms 305 ms
4 203.0.113.5 28 ms 27 ms 28 ms
5 8.8.8.8 30 ms 31 ms 30 ms
W takim układzie opóźnienie do celu jest prawidłowe. Wyjaśnienie zwykle jest proste: dany router priorytetyzuje przekazywanie ruchu (forwarding) nad odpowiadanie na pakiety ICMP. Odpowiedzi ICMP „Time Exceeded” są generowane z niższym priorytetem lub z ograniczeniem liczby na sekundę (rate limiting). Z punktu widzenia ścieżki danych wszystko jest w porządku, a „wysoki ping” do tego hopu jest efektem ubocznym polityki QoS, a nie problemem na łączu.
Gdy ocenia się traceroute, sens ma obserwowanie opóźnienia do kolejnych hopów, szczególnie końcowego, a nie pojedynczego punktu „po drodze”. Skok w połowie trasy, który natychmiast „znika” na następnym routerze, to praktycznie zawsze fałszywy alarm.
Asymetryczna trasa – tamtędy, z powrotem inaczej
Ktoś uruchamia traceroute ze swojego domu do serwera i z serwera do domu. Wyniki różnią się mocno – po stronie użytkownika 6 hopów, po stronie serwera 12, do tego inne kraje i inne AS‑y. Tak wygląda klasyczna asymetria trasy.
Internet na poziomie międzyoperatorskim jest z natury asymetryczny. BGP ustala trasy na podstawie polityk każdego autonomicznego systemu niezależnie dla każdego kierunku. Pakiet wysyłany od A do B może lecieć zupełnie inną drogą niż pakiet wracający z B do A. Opóźnienie, jitter czy straty, które widać w jedną stronę, nie muszą powtarzać się w drugą.
W praktyce oznacza to, że jeśli:
- użytkownik widzi wysokie opóźnienie, ale traceroute z serwera do niego wygląda dobrze,
- ping z obu stron pokazuje różne wartości w tym samym czasie,
to problem może leżeć na odcinku „wychodzącym” z sieci jednego z operatorów. Narzędzia typu Looking Glass (dostępne u większych operatorów) pozwalają czasem spojrzeć na trasę „od drugiej strony” bez logowania się na sam serwer.
MTR – ciągły podgląd trasy i jakości połączenia
Admin patrzy w pojedynczy traceroute, wszystko wygląda poprawnie, a użytkownik nadal zgłasza „lagi”. Po kilku godzinach okazuje się, że problem pojawia się tylko co parę minut – wtedy pojedynczy zrzut trasy łatwo go przegapia. Tu przydaje się mtr, który łączy funkcje ping i traceroute w ciągłym pomiarze.
Uruchomienie mtr w praktyce
Na systemach uniksowych (Linux, BSD, często także na routerach z OpenWrt) składnia jest prosta:
mtr google.com
mtr -n -4 8.8.8.8
Najczęściej używane opcje:
-n– bez rozwiązywania nazw, tylko IP,-4/-6– wymuszenie IPv4/IPv6,-r– tryb raportu (jednorazowy raport tekstowy zamiast interaktywnego ekranu),-c <liczba>– ile pakietów wysłać w trybie raportu,-i <sekundy>– odstęp między kolejnymi pakietami.
Jeśli trzeba wysłać operatorowi twarde dane, przydaje się tryb raportu:
mtr -n -4 -r -c 200 8.8.8.8 > mtr-8.8.8.8.txt
Powstaje wtedy tekstowy raport zawierający średnie i maksymalne opóźnienie, odchylenie standardowe oraz procent strat dla każdego hopu – na podstawie 200 próbek.
Odczytywanie raportu mtr
Przykładowy raport z mtr -n -r -c 100 8.8.8.8 może wyglądać tak:
HOST: laptop Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 100 1.1 1.0 0.8 2.0 0.2
2.|-- 10.10.0.1 0.0% 100 7.8 8.0 7.1 10.5 0.6
3.|-- 198.51.100.1 0.0% 100 15.2 15.5 14.8 19.3 0.7
4.|-- 203.0.113.5 2.0% 100 25.1 26.0 24.5 60.2 6.5
5.|-- 8.8.8.8 2.0% 100 27.0 27.5 25.9 63.4 6.8
Kluczowe kolumny:
- Loss% – procent utraconych pakietów na danym hopie (z perspektywy klienta),
- Last – czas ostatniego pakietu,
- Avg – średnie RTT,
- Best / Wrst – najlepszy i najgorszy czas,
- StDev – odchylenie standardowe (czyli miara „rozrzutu” wartości).
Tutaj widać, że niewielkie straty (2%) pojawiają się od hopu 4 wzwyż, wraz z rosnącym rozrzutem czasów. Interpretacja: problem leży gdzieś na lub za routerem 203.0.113.5. Ponieważ host docelowy ma identyczny poziom strat co hop 4, bardzo prawdopodobne, że winne jest łącze lub urządzenie pomiędzy hopami 3 a 4 lub sam hop 4.
W odróżnieniu od statycznego traceroute, mtr pokazuje, jak trasa zachowuje się w czasie. Pozwala to wychwycić okresowe skoki opóźnień, które dla pojedynczego pomiaru byłyby tylko „fotką w spokojnym momencie”.
Fałszywe straty i priorytetyzacja ICMP w mtr
Bywa też odwrotna sytuacja: mtr raportuje 50% strat na drugim hopie, ale host docelowy ma 0% strat. Przykład:
HOST: laptop Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 100 1.1 1.0 0.8 2.0 0.2
2.|-- 10.10.0.1 50.0% 100 7.8 8.0 7.1 10.5 0.6
3.|-- 198.51.100.1 0.0% 100 15.2 15.5 14.8 19.3 0.7
4.|-- 8.8.8.8 0.0% 100 27.0 27.5 25.9 31.4 1.1
Taki wynik zwykle oznacza, że router 10.10.0.1 ogranicza liczbę odpowiedzi ICMP do siebie (rate limiting) lub dropuje pakiety z konkretnym TTL, ale wciąż przekazuje ruch dalej bez problemu. Gdyby fizycznie gubił co drugi pakiet, straty byłyby widoczne również na kolejnych hopach – szczególnie na ostatnim.
Przy interpretacji kolumny Loss% trzeba więc patrzeć, czy „strata” jest dziedziczona w dół trasy. Jeżeli Loss% rośnie lub utrzymuje się od pewnego hopu aż do celu, dopiero wtedy jest mocny argument, że na tym odcinku faktycznie giną pakiety.
Łączenie ping, traceroute i mtr w jednym scenariuszu
Domowa sieć działa „jako tako”, ale użytkownik raz za razem słyszy w słuchawkach „urwany” głos, a w grach ma nagłe skoki pingu. Jednorazowy ping wygląda poprawnie, traceroute też – dopiero sekwencja narzędzi ułożonych w sensowną procedurę pokazuje, gdzie się coś kruszy.
Prosty schemat diagnostyczny krok po kroku
Przy powtarzalnym problemie można zastosować logiczny zestaw testów:
- Ping do routera – dłuższy, np. 200–500 pakietów, w odstępach 0,2–0,5 s:
ping -i 0.2 -c 300 192.168.1.1Jeśli widać straty lub regularne skoki czasu – problem w LAN (Wi‑Fi, kabel, router).
- Ping do stabilnego hosta w internecie (1.1.1.1, 8.8.8.8).
ping -i 0.2 -c 300 1.1.1.1Gdy tu pojawiają się przycięcia, a do routera jest dobrze – kłopot leży na łączu do operatora lub dalej.
- Traceroute do tego samego hosta – kilka powtórzeń w odstępach kilku minut.
traceroute -n -4 1.1.1.1To pozwala zobaczyć, czy trasa jest stabilna, czy co chwilę się przełącza.
- MTR przez dłuższą chwilę – np. 300–500 pakietów:
mtr -n -4 -r -c 500 1.1.1.1Raport pokaże, od którego hopu zaczyna się jitter lub straty.
Takie zestawienie zamienia subiektywne „internet mi rwie” na konkretne liczby i miejsca w sieci. Zwykle po tym etapie wiadomo już, czy trzeba poprawić własne Wi‑Fi, domowy router, czy zebrać raporty i pójść z nimi do operatora.
Przykład: problemy tylko w godzinach szczytu
U jednego z użytkowników dało się zaobserwować, że rano i w nocy połączenie działa idealnie, ale między 18:00 a 22:00 pojawiają się skoki pingów w grach i gubione ramki w rozmowach wideo. Ping do routera pozostawał wtedy czysty.
Seria testów pokazała:
- ping do 1.1.1.1 – stabilny rano, wieczorami sporadyczne skoki do kilkuset ms,
- traceroute – rano trasa krótsza, bez większych skoków; wieczorami regularny wzrost RTT na jednym z międzyoperatorskich hopów,
- mtr na 30 minut wieczorem – rosnące jitter i pojedyncze straty od konkretnego routera w sieci operatora wzwyż.
Wyniki zebrane w raportach z mtr i traceroute pozwoliły wsparciu technicznemu podnieść sprawę do działu sieciowego zamiast zamykać zgłoszenie na poziomie „proszę zrestartować router w domu”. Bez twardych danych byłoby to dużo trudniejsze.
Kiedy ICMP (ping/traceroute/mtr) nie wystarcza
Najczęściej zadawane pytania (FAQ)
Jak zacząć diagnozę, gdy „internet muli” albo ping w grach skacze?
Najpierw usuń z równania własną sieć. Podłącz komputer kablem Ethernet bezpośrednio do routera, wyłącz na chwilę inne urządzenia (konsole, TV, backupy w chmurze) i zobacz, czy problem nadal występuje. Jeśli po kablu jest dobrze, a po Wi‑Fi źle – winne jest raczej Wi‑Fi, nie operator.
Kolejny krok to prosta sekwencja testów: ping do bramy domowej (np. 192.168.1.1), potem ping do zewnętrznego, „pewnego” adresu (np. 1.1.1.1 lub 8.8.8.8), a na końcu ping/traceroute do konkretnego serwera, z którym masz kłopot (gra, Teams, serwer WWW). Na tej podstawie widzisz, na którym odcinku trasy zaczyna się problem.
Jak odróżnić problem z moją siecią domową od problemu u operatora?
Wyobraź sobie, że sprawdzasz kolejne odcinki łańcucha. Jeśli ping do bramy domowej (routera) ma niskie opóźnienia i zero utraty pakietów, ale ping do zewnętrznego adresu jest zły – kłopot zaczyna się poza Twoją siecią, czyli zwykle u operatora lub dalej w internecie. Jeśli już ping do routera jest niestabilny lub z dużym opóźnieniem, szukaj winy u siebie (Wi‑Fi, kabel, przeciążony router).
Traceroute i mtr pomagają to doprecyzować. Gdy pierwsze hop-y (dom, pierwszy router operatora) wyglądają dobrze, a problemy zaczynają się w środku trasy albo tuż przed serwerem docelowym, masz mocny argument, że to nie Twoja infrastruktura szwankuje.
Co dokładnie mierzy ping i kiedy „wysoki ping” naprawdę jest problemem?
Kiedy uruchamiasz ping, wysyłasz pakiety ICMP Echo Request do wybranego hosta i mierzysz czas odpowiedzi (Echo Reply). Ten czas to RTT (Round Trip Time) – ile milisekund trwa podróż tam i z powrotem. Ping pokazuje też utratę pakietów, czyli procent pakietów, które w ogóle nie docierają z powrotem.
Wysoki ping jest problemem, gdy jest wyraźnie większy niż zwykle i/lub mocno skacze w czasie, co w grach czy wideokonferencjach objawia się „lagami”. Jednorazowy skok jednego pakietu w ping nie musi nic znaczyć, ale seria opóźnień i straty pakietów już tak – szczególnie gdy dotyczy pingu do bramy lub pierwszych hopów u operatora.
Jak czytać wyniki traceroute i mtr, żeby nie wyciągać błędnych wniosków?
Częsty scenariusz: widzisz w traceroute, że jeden z routerów ma wysoki czas odpowiedzi i od razu pada diagnoza „ten hop jest zepsuty”. Routery jednak często zaniżają priorytet odpowiedzi na ICMP, więc mogą odpowiadać wolno na ping, a jednocześnie przekazywać zwykły ruch (HTTP, gry, VPN) bez opóźnień. Kluczowe jest, czy wysoki czas utrzymuje się także na kolejnych hopach.
W mtr patrzysz przede wszystkim na:
- czy rosną opóźnienia i utrata pakietów od danego hopa w dół trasy (realny korek/problem),
- czy „straty” widoczne na jednym hopie znikają na następnym (to zwykle tylko brak odpowiedzi ICMP, nie realna utrata ruchu).
Jeśli problem pojawia się na którymś routerze i wszystkie kolejne też mają gorsze statystyki – właśnie tam szukaj przyczyny.
Dlaczego w traceroute pojawiają się gwiazdki i czy to oznacza awarię?
Często użytkownik widzi gwiazdki w traceroute i zakłada, że „ten router nie działa”. W praktyce oznacza to zwykle tylko tyle, że dany hop nie odpowiedział na pakiet ICMP w wyznaczonym czasie – bo jest zablokowany przez firewall, ogranicza ICMP albo jest po prostu mocno obciążony i nie „ma czasu” na odpowiedź diagnostyczną.
Awarię podejrzewaj dopiero wtedy, gdy od momentu pojawienia się gwiazdek nie odpowiadają też kolejne hop-y, a na końcu host docelowy jest nieosiągalny. Jeśli część trasy nie odpowiada, a mimo to ostatni host ma stabilny ping i usługa działa, gwiazdki są jedynie efektem polityki bezpieczeństwa lub priorytetyzacji ruchu, a nie realnym problemem.
Czemu serwer nie odpowiada na ping, a strona albo aplikacja działa normalnie?
Z perspektywy użytkownika wygląda to dziwnie: ping pokazuje 100% utraty pakietów, ale przeglądarka bez problemu otwiera stronę. To efekt tego, że ICMP (na którym działa ping) nie jest wymagany do działania HTTP, gier czy VPN – wielu administratorów po prostu blokuje odpowiedzi ICMP ze względów bezpieczeństwa lub żeby utrudnić skanowanie sieci.
W takiej sytuacji bardziej miarodajne jest obserwowanie wcześniejszych hopów w traceroute/mtr i testowanie samej usługi (np. czas ładowania strony, stabilność połączenia w grze). Brak odpowiedzi na ping do ostatniego hosta nie jest sam w sobie dowodem na problem sieciowy.
Jakie testy wykonać przed zgłoszeniem problemu do operatora lub administratora?
Zamiast dzwonić z komunikatem „internet działa wolno”, lepiej zebrać kilka prostych danych. Wykonaj:
- ping do bramy domowej (np. 192.168.1.1) – stabilność własnej sieci,
- ping do znanego zewnętrznego adresu (np. 1.1.1.1, 8.8.8.8),
- traceroute lub mtr do konkretnego problematycznego hosta (serwer gry, serwer firmowy).
Zapisz wyniki lub zrób zrzuty ekranu, szczególnie gdy widać duże opóźnienia lub straty od konkretnego hopa.
Z takim kompletem łatwo pokazać: „do mojej bramy jest ok, od waszej bramy dalej mam 20% utraty i skoki pingu”. To oszczędza czas obu stron i zwiększa szansę, że sprawa trafi od razu do właściwego działu technicznego, zamiast utknąć na poziomie ogólnikowych porad w stylu „proszę zrestartować router”.
