To wbudowane polecenie Windows do śledzenia drogi pakietów przez kolejne routery, znane z narzędzia tracert. Najlepiej sprawdza się wtedy, gdy połączenie działa „mniej więcej”, ale konkretna strona, gra albo usługa ładuje się wolno, gubi odpowiedź albo przestaje być osiągalna na którymś etapie trasy. W praktyce pokazuje nie tylko samą ścieżkę, ale też miejsca, w których rośnie opóźnienie lub pojawiają się blokady.
Najważniejsze fakty o diagnostyce trasy pakietów
- To test oparty na ICMP i TTL, więc pokazuje kolejne skoki między routerami, a nie pełny obraz jakości usługi.
- Domyślnie narzędzie sprawdza do 30 hopów, a na odpowiedź czeka zwykle 4000 ms.
- Gwiazdki w wyniku nie zawsze oznaczają awarię, bo część routerów celowo nie odpowiada na takie pakiety.
- Opcja /d przyspiesza wynik, bo wyłącza reverse DNS, a /4 i /6 wymuszają odpowiednio IPv4 lub IPv6.
- Do szybkiej diagnozy trasy dobrze dołożyć ping, a przy podejrzeniu strat pakietów także pathping.
Jak działa mechanizm TTL i dlaczego widzisz kolejne hopy
Ja zwykle zaczynam od prostego założenia: każdy router po drodze zmniejsza wartość TTL o 1. TTL, czyli Time To Live, to licznik skoków, który ma zapobiegać nieskończonemu krążeniu pakietów po sieci. Gdy TTL spadnie do zera, router odsyła komunikat ICMP Time Exceeded, a właśnie na tej odpowiedzi opiera się cała diagnostyka trasy.
W efekcie nie dostajesz „magicznej mapy internetu”, tylko listę urządzeń, które odpowiedziały na kolejne pakiety testowe. To ważne rozróżnienie, bo wynik pokazuje drogę pakietu do celu, a nie pełną jakość całego łącza. Jeden przeskok może wyglądać świetnie, a połączenie nadal będzie niestabilne z powodów, których ten test nie ujawnia.
Gwiazdki pojawiają się wtedy, gdy router nie odsyła odpowiedzi albo czas oczekiwania minął. To częste w sieciach operatorskich, firmowych i chmurowych, gdzie ICMP bywa ograniczany lub traktowany nisko priorytetowo. Dlatego brak odpowiedzi na jednym hopie nie musi oznaczać problemu z ruchem dalej.
Ten mechanizm jest prosty, ale właśnie dlatego tak dobrze nadaje się do szybkiego zawężania problemu. Kiedy wiesz już, jak działa TTL, łatwiej przejść do praktyki i świadomie uruchomić test z odpowiednimi parametrami.
Jak uruchomić test i dobrać parametry
Najprostsze użycie jest banalne, ale w diagnostyce szczegóły robią różnicę. Jeśli zależy mi na szybkim wyniku, zwykle wyłączam rozwiązywanie nazw i sprawdzam tylko trasę. Dzięki temu odpada część opóźnień związanych z DNS.
C:\>tracert /d /h 20 /w 2000 www.microsoft.comW tym przykładzie najważniejsze są trzy parametry. /d pomija zamianę adresów IP na nazwy hostów, więc wynik pojawia się szybciej i czyściej. /h 20 ogranicza liczbę hopów do 20 zamiast domyślnych 30, a /w 2000 skraca czas oczekiwania na odpowiedź do 2000 ms, czyli 2 sekund.
| Parametr | Co robi | Kiedy ma sens |
|---|---|---|
| /d | Nie wykonuje reverse DNS | Gdy chcesz szybszy i bardziej techniczny wynik |
| /h | Ustawia maksymalną liczbę hopów | Gdy trasa jest długa albo chcesz ograniczyć test |
| /w | Określa timeout w milisekundach | Gdy łącze ma wysokie opóźnienia albo pakiety wracają wolno |
| /4 i /6 | Wymuszają IPv4 lub IPv6 | Gdy chcesz porównać zachowanie obu protokołów |
Jeśli pracujesz w PowerShellu, alternatywą bywa też test z route tracing w Test-NetConnection. Dla mnie to wygodne uzupełnienie, bo pozwala połączyć sprawdzenie trasy z innymi danymi diagnostycznymi bez przeskakiwania między kilkoma narzędziami.
Po ustawieniu parametrów ważniejsze staje się już nie samo uruchomienie testu, ale umiejętność czytania tego, co naprawdę pokazuje wynik.
Jak czytać wynik bez zgadywania
Wynik składa się z kilku powtarzalnych elementów i warto patrzeć na nie w tej samej kolejności. Pierwsza kolumna to numer hopa, czyli kolejny skok na trasie. Potem widzisz zwykle trzy czasy odpowiedzi w milisekundach, a na końcu adres IP albo nazwę hosta urządzenia, które odesłało pakiet.
Trzy czasy nie są średnią ani statystyką długoterminową. To trzy osobne próby, które często różnią się od siebie o kilka lub kilkanaście milisekund. Taka rozbieżność jest normalna, zwłaszcza w sieciach publicznych, gdzie opóźnienie zmienia się zależnie od obciążenia i trasy zwrotnej.
Najczęściej sprawdzam trzy rzeczy:
- czy opóźnienie rośnie stopniowo, czy nagle skacze na jednym z hopów,
- czy pojawiają się gwiazdki tylko po drodze, czy już przy pierwszym urządzeniu,
- czy nazwa hosta jest rozpoznawalna, czy wygląda na węzeł operatora, chmury albo sieci firmowej.
W praktyce najcenniejszy jest nie sam ostatni wynik, ale pierwszy moment, w którym zachowanie trasy zaczyna się zmieniać. Jeśli pierwszy router odpowiada szybko, a kolejne nagle milkną, problem najczęściej leży dalej niż lokalny komputer lub domowy router.
To prowadzi do ważnej części: kiedy taki wynik rzeczywiście pomaga, a kiedy lepiej sięgnąć po inne narzędzia.
Kiedy to narzędzie naprawdę pomaga, a kiedy lepiej użyć czegoś innego
Ja traktuję diagnostykę trasy jako narzędzie do odpowiedzi na pytanie: gdzie w sieci pojawia się opóźnienie albo przerwa. To świetny pierwszy krok, ale nie zawsze najlepszy końcowy dowód. Jeśli chcesz tylko sprawdzić, czy host odpowiada, wystarczy ping. Jeśli szukasz strat pakietów po drodze, lepszy bywa pathping. Gdy chcesz połączyć test trasy z dodatkowymi danymi o połączeniu, sensownie wypada Test-NetConnection.
| Narzędzie | Co pokazuje | Najlepsze zastosowanie | Ograniczenie |
|---|---|---|---|
| Ping | Odpowiedź hosta i podstawowe opóźnienie | Szybka kontrola, czy cel żyje | Nie pokazuje drogi przez sieć |
| Polecenie śledzące trasę | Kolejne routery i opóźnienia na hopach | Namierzenie miejsca, w którym ruch zwalnia | Nie mierzy strat pakietów tak dobrze jak pathping |
| Pathping | Trasę i statystyki utraty pakietów | Gdy podejrzewasz problem jakości po drodze | Działa wolniej i wymaga cierpliwości |
| Test-NetConnection z trasowaniem | Diagnostykę połączenia, DNS i trasę | Gdy chcesz jeden test zamiast kilku osobnych | To narzędzie PowerShell, więc wymaga innego nawyku pracy |
Z mojego doświadczenia wynika, że najlepszy zestaw to: najpierw sprawdzenie odpowiedzi hosta, potem trasa, a na końcu test strat pakietów. Taki układ oszczędza czas, bo nie zaczynasz od najcięższego narzędzia, tylko od najprostszej odpowiedzi na pytanie „czy coś w ogóle działa?”.
Równie ważne jest jednak to, czego nie wolno z takiego wyniku wyciągać zbyt pochopnie.
Najczęstsze pułapki w interpretacji wyników
Najczęstszy błąd to uznanie jednego wiersza z gwiazdkami za twardy dowód awarii. W rzeczywistości wiele routerów po prostu nie odpowiada na pakiety testowe albo odpowiada z niższym priorytetem. Gdy końcowy cel odpowiada, a po drodze widać kilka braków, sytuacja często jest całkiem normalna.
Druga pułapka to zakładanie, że trasa wyświetlana przez test jest identyczna w obie strony. Tak nie działa większość sieci. Ruch wychodzący i powrotny mogą iść inną ścieżką, więc czas z jednego hopa nie zawsze opisuje cały odcinek symetrycznie.
Warto też pamiętać o wpływie CDN-ów, NAT-u, VPN-ów i filtrów. Strona może odpowiadać z zupełnie innego punktu niż ten, którego się spodziewasz, a połączenie przez firmową sieć VPN może dodać kilka przeskoków, których wcześniej nie było. Jeśli wynik zmienia się po wyłączeniu VPN albo po przełączeniu na hotspot z telefonu, masz już bardzo konkretny trop.
Jest jeszcze jedna rzecz, którą często pomija się przy diagnozie domowej: opóźnienie ICMP nie musi odzwierciedlać opóźnienia HTTP, gier czy VoIP. Dostawca lub firewall może traktować te typy ruchu inaczej. Dlatego wynik najlepiej interpretować razem z tym, co dokładnie nie działa w aplikacji.
Kiedy te ograniczenia masz w głowie, łatwiej przejść od samego wyniku do realnych kroków naprawczych.
Co zrobić, gdy trasa urywa się przed celem
Gdy wynik przestaje być czytelny, idę zawsze tą samą ścieżką. Najpierw uruchamiam test jeszcze raz z wyłączonym rozwiązywaniem nazw, bo to usuwa część szumu. Potem sprawdzam, czy problem występuje do adresu IP, a nie tylko do nazwy hosta. Różnica bywa zaskakująco duża, szczególnie przy usługach korzystających z wielu serwerów.
- Porównaj wynik z i bez rozwiązywania nazw, żeby wykluczyć opóźnienia DNS.
- Sprawdź ping do ostatniego odpowiadającego hopa oraz do celu końcowego.
- Uruchom test z innej sieci, na przykład z LTE/5G, żeby odciąć wpływ lokalnego operatora lub routera.
- Jeśli kontrolujesz serwer, sprawdź firewall i reguły dla ICMP oraz ruchu zwrotnego.
- Jeśli problem leży po stronie dostawcy, przygotuj godzinę testu, numer hopa i pełny wynik, zamiast opisywać go ogólnikowo.
W praktyce to właśnie połączenie prostego testu trasy z pingiem i jednym dodatkowym narzędziem daje najbardziej użyteczny obraz sytuacji. Wtedy da się rozstrzygnąć, czy problem wynika z DNS, z samej trasy, czy z zachowania konkretnej usługi, a nie tylko z jednego punktu po drodze.
