Jak naprawić błąd DNS_PROBE_FINISHED_NXDOMAIN w Google Chrome?

Podstawowe sposoby naprawy błędu DNS_PROBE_FINISHED_NXDOMAIN w Chrome

Błąd DNS_PROBE_FINISHED_NXDOMAIN w Google Chrome oznacza, że przeglądarka nie może znaleźć adresu IP przypisanego do domeny, którą próbujesz odwiedzić. Najczęściej problem leży po stronie ustawień DNS lub samego systemu operacyjnego. Na szczęście istnieje kilka podstawowych metod, które możesz zastosować samodzielnie. Poniżej znajdziesz poradnik krok po kroku, który pomoże Ci rozwiązać ten problem.

Sprawdź połączenie internetowe

Pierwszym krokiem jest upewnienie się, że Twoje połączenie internetowe działa poprawnie. Czasami błąd nie wynika z DNS, ale z chwilowych problemów dostawcy internetu.

1. Spróbuj otworzyć inną stronę internetową i sprawdź, czy działa.
2. Jeśli masz możliwość, przełącz się z Wi-Fi na kabel Ethernet.
3. Zrestartuj modem lub router i odczekaj kilka minut.

Uruchom ponownie komputer i przeglądarkę

Choć brzmi to banalnie, często pomaga. Restart systemu oraz ponowne uruchomienie Chrome pozwala odświeżyć konfigurację sieciową. Po restarcie spróbuj ponownie otworzyć stronę.

Wyczyść pamięć podręczną DNS

System operacyjny zapisuje w pamięci podręcznej DNS informacje o ostatnio odwiedzanych stronach. Jeśli te dane są uszkodzone lub nieaktualne, może wystąpić błąd DNS_PROBE_FINISHED_NXDOMAIN. Wyczyść pamięć podręczną zgodnie z instrukcją:

Windows:

1. Naciśnij Win + R, wpisz cmd i zatwierdź.
2. Wpisz komendę: ipconfig /flushdns i naciśnij Enter.
3. Poczekaj na komunikat „Successfully flushed the DNS Resolver Cache”.

macOS:

1. Otwórz Terminal.
2. Wpisz: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
3. Potwierdź hasłem administratora.

Zmień serwery DNS na publiczne

Czasem problem wynika z awarii serwerów DNS używanych przez Twojego dostawcę internetu. Możesz łatwo przełączyć się na serwery DNS od Google lub Cloudflare.

Windows 10/11:

1. Otwórz Ustawienia sieci i Internetu.
2. Wejdź w „Zmień opcje karty” i wybierz swoje połączenie.
3. Kliknij prawym przyciskiem myszy → „Właściwości”.
4. Zaznacz „Protokół internetowy w wersji 4 (TCP/IPv4)” i kliknij „Właściwości”.
5. Zaznacz „Użyj następujących adresów serwerów DNS”.
6. Wprowadź: 8.8.8.8 i 8.8.4.4 (Google) lub 1.1.1.1 i 1.0.0.1 (Cloudflare).
7. Zatwierdź i uruchom ponownie przeglądarkę.

macOS:

1. Wejdź w „Preferencje systemowe” → „Sieć”.
2. Wybierz swoje połączenie i kliknij „Zaawansowane”.
3. Przejdź do zakładki „DNS”.
4. Dodaj nowe adresy: 8.8.8.8, 8.8.4.4 lub 1.1.1.1, 1.0.0.1.
5. Zapisz zmiany i odśwież stronę.

Wyczyść pamięć podręczną przeglądarki

Uszkodzone pliki w pamięci podręcznej Chrome również mogą powodować ten błąd. Aby je usunąć:

1. Kliknij w menu Chrome (trzy kropki w prawym górnym rogu).
2. Wybierz „Ustawienia” → „Prywatność i bezpieczeństwo”.
3. Kliknij „Wyczyść dane przeglądania”.
4. Zaznacz „Obrazy i pliki w pamięci podręcznej” oraz „Pliki cookie”.
5. Potwierdź przyciskiem „Wyczyść dane”.

Podsumowanie

Błąd DNS_PROBE_FINISHED_NXDOMAIN w Google Chrome najczęściej wynika z błędnych ustawień DNS lub uszkodzonej pamięci podręcznej. Sprawdzenie połączenia internetowego, restart systemu, czyszczenie cache DNS oraz zmiana serwerów DNS na publiczne to podstawowe kroki, które w większości przypadków rozwiązują problem. Jeśli mimo to błąd nadal występuje, warto przejść do metod zaawansowanych – w tym edycji pliku hosts lub resetowania konfiguracji sieciowej całego systemu.

Zaawansowane metody rozwiązania problemu DNS_PROBE_FINISHED_NXDOMAIN

Gdy podstawowe wskazówki nie pomagają, czas sięgnąć po metody zaawansowane. Błąd DNS_PROBE_FINISHED_NXDOMAIN zwykle oznacza, że resolver nie znajduje rekordu dla żądanej nazwy. Jednak przyczyną mogą być: błędna propagacja strefy, uszkodzone podpisy DNSSEC, pętle CNAME, konflikt między IPv4 i IPv6, reguły filtrujące na brzegu sieci, a nawet tzw. split‑horizon DNS. Poniższe kroki pomagają jednoznacznie ustalić źródło i trwale usunąć problem – na stacji roboczej, w routerze, a także po stronie domeny, jeśli to Twoja witryna.

W każdym etapie testuj po zmianach w trybie Incognito i na alternatywnym resolverze (np. 1.1.1.1 lub 8.8.8.8). To pozwoli odróżnić problemy lokalne od błędów globalnych. Pamiętaj, aby po operacjach odświeżyć cache systemowy oraz bufory przeglądarki, ponieważ stary wynik NXDOMAIN potrafi „utknąć” na kilkanaście minut.

Diagnostyka ekspercka: dig, nslookup, traceroute i DoH

Najpierw sprawdź, gdzie znika nazwa. Zbierz krótkie, ale decydujące artefakty. Dzięki temu łatwo wskażesz administratorowi dokładne miejsce awarii lub wykluczysz swoje środowisko. Poniżej przykładowe sekwencje dla różnych systemów.

Linux/macOS (dig) – uruchom: dig +trace domena.tld. Jeśli śledzenie kończy się na serwerach autorytatywnych błędem NXDOMAIN lub SERVFAIL, źródło jest w strefie. Gdy odpowiedź pojawia się poprawnie, ale Chrome wciąż zwraca NXDOMAIN, winny jest resolver lub cache lokalny.

Windows (nslookup) – wykonaj: nslookup -type=A domena.tld 1.1.1.1 oraz nslookup -type=AAAA domena.tld 1.1.1.1. Porównaj wyniki z własnym DNS (bez drugiego parametru). Rozbieżność oznacza błąd w lokalnym resolverze lub na routerze. Ponadto sprawdź subdomeny: www.domena.tld, cdn.domena.tld, aby wykryć pętle CNAME.

DoH w przeglądarce – przetestuj zapytanie przez HTTPS: otwórz https://1.1.1.1/dns-query?name=domena.tld&type=A w narzędziu curl lub przez rozszerzenie DNS‑over‑HTTPS. Jeśli wynik istnieje w DoH, a nie w zwykłym DNS, coś po drodze filtruje port 53/853.

Głęboki reset stosu sieci (Windows/macOS/Linux)

Jeśli wątpisz w integralność konfiguracji, resetuj warstwy niżej niż zwykłe czyszczenie cache. Te kroki przywracają domyślne sterowniki, odświeżają rejestr TCP/IP oraz restartują usługi odpowiedzialne za rozwiązywanie nazw.

Windows 10/11 – Uruchom PowerShell jako administrator i wykonaj kolejno: netsh winsock reset, netsh int ip reset, ipconfig /flushdns, ipconfig /release, ipconfig /renew. Następnie w „Ustawienia → Sieć i Internet → Zaawansowane ustawienia sieci” kliknij „Resetuj sieć”. Komputer uruchomi się ponownie i odinstaluje/ponownie zainstaluje adaptery.

macOS – Zresetuj konfigurację interfejsu: Usuń i dodaj ponownie usługę sieciową (Wi‑Fi/Ethernet) w „Preferencje systemowe → Sieć”. Potem wyczyść cache: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Dodatkowo usuń preferencje: /Library/Preferences/SystemConfiguration/ pliki com.apple.airport.preferences.plist, preferences.plist (zachowaj kopię), zrestartuj system.

Linux – Zrestartuj resolver i menedżer sieci: sudo systemctl restart systemd-resolved NetworkManager. W systemach bez resolved odtwórz /etc/resolv.conf do prostej postaci z wybranym serwerem: nameserver 1.1.1.1. Następnie sudo systemd-resolve --flush-caches lub stosowny odpowiednik.

DNS w routerze, DHCP i split‑horizon

Wiele awarii wynika z błędnych adresów DNS rozdawanych przez DHCP. Router często wskazuje sam siebie jako resolver i przekazuje zapytania dalej. Gdy funkcja ta się zawiesi, wszystkie urządzenia w sieci dostaną NXDOMAIN. Sprawdź, co dystrybuuje DHCP oraz upewnij się, że router przekazuje zapytania do zdrowych serwerów nadrzędnych.

W panelu routera ustaw jawnie serwery 1.1.1.1/1.0.0.1 lub 8.8.8.8/8.8.4.4. Następnie zrestartuj router i odłącz/podłącz Wi‑Fi w urządzeniach. Jeżeli w firmie działa DNS wewnętrzny, rozważ tzw. split‑horizon: ta sama domena ma inne rekordy „w środku” i „na zewnątrz”. Spróbuj rozwiązać nazwę z sieci komórkowej – jeśli działa, winny jest lokalny DNS korporacyjny.

W środowiskach z filtracją treści (rodzicielską lub korporacyjną) DNS może być przekierowywany na bramie. Gdy sygnatura strony jest błędna, resolver zwraca NXDOMAIN. Tymczasowo wyłącz filtr, przełącz protokół na DoH/DoT albo dodaj domenę do listy wyjątków.

IPv6 vs IPv4, MTU i pętle CNAME

NXDOMAIN bywa skutkiem mieszanych konfiguracji, w których domena posiada AAAA, ale trasa IPv6 jest niestabilna. Czasowo wyłącz IPv6 w adapterze i sprawdź, czy sytuacja się poprawia. Jeśli tak, pozostaw IPv6 wyłączone lub napraw trasowanie u operatora. Dodatkowo zweryfikuj parametry MTU – zbyt niskie może powodować błędy przy wymianie DNS przez DoH.

Pętle CNAME są zdradliwe: www wskazuje na app, a app znowu na www. Dig pokaże to natychmiast (dig www.domena.tld). Usuń cykl w panelu DNS. Pamiętaj, że niektóre CDN wymagają CNAME na strefę apex – wtedy używaj ALIAS/ANAME jeśli dostawca wspiera.

Testuj także rekordy MX/TXT, jeśli problem obejmuje tylko pocztę lub weryfikacje domeny. Błędy w SPF/DKIM nie dają NXDOMAIN, lecz w trakcie diagnozy ujawniają niespójności strefy, które warto poprawić od razu.

DNSSEC, delegacje, glue i propagacja

Źródłem wielu „niewyjaśnionych” NXDOMAIN są podpisy DNSSEC lub niepoprawne delegacje. Gdy rekord DS u rejestru wskazuje zły klucz, resolver zwróci SERVFAIL lub NXDOMAIN w zależności od implementacji. Sprawdź ciąg zaufania: dig +dnssec domena.tld oraz walidację w narzędziach on‑line. Jeśli domena jest Twoja, tymczasowo wyłącz DNSSEC, popraw klucze KSK/ZSK i ponownie włącz po publikacji nowej strefy.

Zweryfikuj delegację NS i tzw. glue u rejestru. Różne zestawy NS w rejestrze i w strefie potrafią generować losowe błędy. Upewnij się, że wszystkie serwery autorytatywne serwują identyczną strefę i mają świeży serial SOA. Jeśli migrowałeś DNS do nowego dostawcy, podnieś numer SOA i zmniejsz TTL na czas propagacji.

Chrome i warstwa aplikacyjna: bufory, profil, polityki

Jeżeli inne przeglądarki działają, a Chrome nie, źródło leży w warstwie aplikacyjnej. Zresetuj bufory: chrome://net-internals/#dns → Clear host cache oraz chrome://net-internals/#sockets → Flush socket pools. Stwórz czysty profil użytkownika i wyłącz rozszerzenia blokujące treści. W wersjach zarządzanych (praca/szkoła) polityki mogą wymuszać filtrację DNS – poproś administratora o weryfikację konfiguracji DNSOverHttpsMode oraz list wyjątków.

W razie potrzeby przełącz Chrome na „Używaj bezpiecznego DNS” z dostawcą wspierającym DoH. To często omija błędy routera lub ISP. Jeżeli organizacja przechwytuje ruch TLS (SSL inspection), DoH może wymagać dodania wyjątków certyfikatów.

Urządzenia mobilne: Android i iOS

Na telefonach łatwo odróżnić błąd lokalny od problemu operatora. Włącz dane komórkowe i wyłącz Wi‑Fi. Jeżeli strona zaczyna działać, przyczyna tkwi w routerze lub DNS sieci lokalnej. Z kolei jeśli na LTE błąd trwa, sprawdź prywatny DNS (Android: Ustawienia → Sieć i internet → Zaawansowane → Prywatny DNS) i przełącz na dns.google lub 1dot1dot1dot1.cloudflare-dns.com. Na iOS wejdź w Wi‑Fi → (i) → Konfiguruj DNS → Ręcznie i ustaw publiczne adresy.

W aplikacjach z wbudowanym resolverem (niektóre przeglądarki, VPN) wyłącz własne DNS aplikacji, aby uniknąć konfliktów. Aplikacje bezpieczeństwa potrafią przechwytywać zapytania – zdezaktywuj ich „bezpieczny DNS”, jeśli diagnoza to sugeruje.

Gdy domena należy do Ciebie: szybka checklista właściciela

Jeśli zarządzasz domeną, przejdź przez krótką listę kontrolną i wdróż poprawki w panelu DNS. To najpewniejsza droga do szybkiego usunięcia NXDOMAIN dla Twoich użytkowników. Po każdej zmianie podnieś serial SOA i obserwuj odpowiedzi z wielu resolverów.

1. Sprawdź delegację NS u rejestru i zgodność z NS w strefie.
2. Zweryfikuj rekordy A/AAAA dla apex i www; usuń pętle CNAME.
3. Obniż TTL do 300–600 s na czas naprawy; po stabilizacji podnieś.
4. Wyłącz DNSSEC, jeśli podpisy są niespójne; po naprawie włącz ponownie.
5. Potwierdź identyczną strefę na wszystkich serwerach autorytatywnych.
6. Jeśli używasz CDN, sprawdź „orange/grey cloud” lub tryb bypass.

Ostateczne obejścia i stabilizacja

Gdy źródło leży po stronie operatora lub domeny, możesz tymczasowo zastosować obejścia. Skonfiguruj alternatywnego dostawcę DNS globalnie w routerze, użyj aplikacji 1.1.1.1/Cloudflare WARP lub skonfiguruj DoH/DoT w systemie. Nie edytuj trwale /etc/hosts dla domen produkcyjnych – to utrudnia późniejszą diagnozę i maskuje rzeczywisty problem.

Po naprawie przywróć standardowe ustawienia, podnieś TTL i monitoruj odpowiedzi za pomocą okresowych testów dig/nslookup. Wprowadź alerty na SERVFAIL/NXDOMAIN spike w narzędziach obserwowalności. Dzięki temu kolejne incydenty wykryjesz, zanim użytkownicy zauważą awarię.