Te 4 komendy, które uruchamiam w PowerShell, rozwiązują najczęstsze problemy z siecią w systemie Windows, na które natrafiam

Zidentyfikuj problemy z połączeniem internetowym w Windows, używając PowerShell. Proste polecenia pomogą znaleźć źródło problemów i przywrócić stabilność sieci.

Internet w zeszłym tygodniu zaczął działać jak ślimak. Strony ciągnęły się niemożliwie powoli, a spotkania wideo? Totalna klapa. Zrestartowałem modem i sieć mesh, ale problem wracał jak bumerang. Czas było poszukać głębszej przyczyny.

Tu wkracza PowerShell. Te polecenia potrafią zawęzić pole poszukiwań – czy winny jest komputer, sieć, DNS, czy coś innego. Nie trzeba być ekspertem; często wystarczy skopiować polecenie, rzucić okiem na wyniki i wyciągnąć wnioski.

Czy problem lokalny, czy daleko stąd?

Test-Connection – skąd zaczyna się błąd?

Od tego właśnie zaczynam. Chcę wiedzieć, czy problem tkwi w mojej sieci, czy poza nią. Polecenie Test-Connection działa jak ping: posyła pakiety do innego urządzenia i pokazuje, czy wróciły, z czasem odpowiedzi w komplecie.

Otwieram PowerShell, odpalam ipconfig i sprawdzam Default Gateway. To adres routera, zwykle uruchomiony na 192.168.1.1. Wprowadzam:

Test-Connection 192.168.1.1 -Count 10

Zamieniam IP na swoją bramę, 192.168.4.1. Ten test nie opuszcza mojej sieci, stąd oczekuję szybkich odpowiedzi. Jeśli czasami zdarzy się opóźnienie, to jeszcze nie katastrofa. Obserwuję, czy pojawiają się powtarzające się wyłączenia, utracone odpowiedzi lub skoki w czasie odpowiedzi z kilku milisekund do setek.

Gdy wygląda to na zielono, sprawdzam coś spoza domowej sieci:

Test-Connection 8.8.8.8 -Count 10

To kieruje test do serwera DNS Google’a. Porównuję wyniki. Jeśli brama działa normalnie, ale zewnętrzny test pokazuje problemy, to widać, że błąd nie leży między komputerem a routerem. Jeśli oba wyniki są słabe, szukam dalej - przy komputerze, Wi-Fi, routerze czy sieci mesh. Koncentruję się na oczywistych niespójnościach: zgubionych pakietach, czasowych wyłączeniach i niestabilnych odpowiedziach.

Jaki serwer DNS wybrał Windows?

Get-DnsClientServerAddress ujawnia tajemnice DNS

Następny krok: DNS. Kilka miesięcy temu zmieniałem je podczas badań do innego artykułu. Testowałem różnych dostawców DNS i z ciekawością sprawdzam, czy Windows nie pozostał przy jednym z nich przypadkiem. Powolne ładowanie stron może sugerować, że DNS wciąż może być problemem.

W PowerShell uruchamiam:

Get-DnsClientServerAddress

To polecenie wyświetla przypisane serwery DNS dla adapterów sieciowych w moim komputerze. Nie trzeba uruchamiać PowerShell jako administrator. Szukam adaptera, którego używam; w moim przypadku Wi-Fi. Sprawdzam kolumnę ServerAddresses. Tu widzę aktualne adresy serwerów DNS.

Ważne, by znać te liczby. Google to 8.8.8.8 i 8.8.4.4, Cloudflare – 1.1.1.1 i 1.0.0.1. Może jednak lekko się zdziwisz, bo niektóre osoby korzystają ze swoich dostawców ISP. Akurat ja potrzebowałem upewnić się, czy przypadkiem jedna z usług DNS testowanych wcześniej nie została. Get-DnsClientServerAddress ujawnia, że wciąż mam DNS Google’a. I tak wracam do...

Adres DNS mojego dostawcy internetu podziałał częściowo, ale problemy sieciowe wciąż się utrzymywały.

Jak Windows skonfigurował połączenie?

Get-NetIPConfiguration - pełen obraz w jednym miejscu

Po zerknięciu na DNS, chciałem sprawdzić pełną konfigurację połączenia w Windows.

Get-NetIPConfiguration przynosi wszystkie kluczowe informacje w jednym kawałku. Zamiast marnować czas na żmudne sprawdzanie każdego ustawienia, to polecenie dostarcza szczegóły dla każdego adaptera: adres IP, domyślną bramę, serwery DNS, które wykorzystuje Windows.

Uruchomiłem Get-NetIPConfiguration, skupiając się na połączeniu Wi-Fi. Sprawdziłem IPv4Address, żeby upewnić się, że Windows zgarnął właściwy lokalny adres IP – zazwyczaj coś w stylu 192.168 lub 10.x. Zajrzałem też do IPv4DefaultGateway, aby sprawdzić, czy Windows wie, gdzie wysyłać ruch. Na końcu potwierdziłem adresy DNS.

Szukam niejasności. Brak domyślnej bramy? Żaden sensowny adres IP? Jeśli Windows dostaje coś zaczynającego się od 169.254, to sygnał, że konfiguracja sieciowa od routera nie działa. To polecenie pomaga mi też upewnić się, że pracuję na właściwym adapterze. Windows może pokazywać Ethernet, Wi-Fi, VPN-y i inne połączenia – łatwo zgubić czas na rozwiązywanie problemów z tym, co nie tak.

Resetowanie Winsock w przypadku zatorów

netsh winsock reset – moja ostatnia nadzieja

Po sprawdzeniu wszystkiego, co wyglądało normalnie, zrestartowałem modem, sieć mesh, przetestowałem połączenie i przeanalizowałem konfigurację Windows. Nic nie było wyraźnie nie tak, ale połączenie nie działało właściwie. Postanowiłem zresetować Winsock.

Otworzyłem PowerShell jako administrator i wpisałem:

netsh winsock reset

Winsock to komponent Windows odpowiedzialny za komunikację aplikacji przez sieć. Resetowanie go może usunąć problemy z błędnymi konfiguracjami. Po wykonaniu polecenia PowerShell poinformuje, że katalog Winsock został zresetowany i trzeba restartować komputer.

Po restarcie sprawdziłem połączenie, ładując strony internetowe i dołączając do spotkań wideo. Na szczęście wszystko znowu działało stabilnie. Wynik polecenia nie jest zbyt rozbudowany – głównie chodzi o potwierdzenie, że reset się udał. Prawdziwy test następuje po ponownym uruchomieniu; wtedy widać, czy problemy ustąpiły.

PowerShell ułatwił diagnozowanie problemu

Dobrą stroną tych poleceń jest to, że są szybkie, a razem potrafią dać jasny obraz źródła problemów z siecią w Windows. W moim przypadku nie było jednego oczywistego wskazania, ale przegląd połączenia, weryfikacja DNS, analiza konfiguracji i reset Winsock pomogły bez zgadywania. Po restarcie połączenie ponownie stało się stabilne, a przeglądanie stron i spotkania wideo wróciły do normy.

Jeśli ciekawią Cię artykuły podobne do Te 4 komendy, które uruchamiam w PowerShell, rozwiązują najczęstsze problemy z siecią w systemie Windows, na które natrafiam, zajrzyj do kategorii Windows i odkryj jeszcze więcej interesujących treści.