Błąd dns_probe_finished_nxdomain zwykle oznacza, że przeglądarka nie potrafi zamienić nazwy domeny na adres IP, więc strona nie ma jak się otworzyć. W praktyce winny bywa nie tylko sam adres, ale też DNS operatora, cache przeglądarki, VPN, filtr sieciowy albo błędna konfiguracja domeny. Poniżej rozbijam ten problem na proste testy i pokazuję kolejność działań, która najszybciej prowadzi do rozwiązania.
Najkrótsza droga do diagnozy i naprawy
- Najpierw sprawdź, czy problem dotyczy jednej domeny, czy całego połączenia.
- Jeśli strona działa na LTE, a nie działa na Wi-Fi, szukaj winy w DNS sieci, routerze albo filtrach.
- Jeśli problem znika w trybie prywatnym lub innej przeglądarce, podejrzane są rozszerzenia, profil albo ustawienie Secure DNS.
- Na Windows najszybszy reset cache DNS to
ipconfig /flushdns. - Gdy to Twoja domena, sprawdź rekordy
A,AAAA,CNAMEi delegacjęNS, a po zmianach daj systemom czas na propagację.
Co oznacza błąd NXDOMAIN i dlaczego nie zawsze winna jest strona
Najprościej mówiąc, NXDOMAIN to odpowiedź DNS mówiąca, że dana nazwa nie istnieje albo nie ma dla niej poprawnej delegacji. W przeglądarce objawia się to zwykle komunikatem typu „site can’t be reached”, ale sam problem nie musi oznaczać, że strona faktycznie zniknęła. Czasem domena istnieje, tylko lokalny resolver ma stary wpis, czasem ktoś źle ustawił rekordy, a czasem sieć po drodze filtrowała odpowiedź.
Ja patrzę tu na prosty łańcuch: domena musi zostać poprawnie zarejestrowana, jej DNS musi wskazywać właściwe serwery, a dopiero potem przeglądarka dostaje adres IP i łączy się z witryną. Jeśli któryś z tych etapów pęknie, użytkownik widzi błąd DNS, choć prawdziwa przyczyna może leżeć kilka warstw niżej. Kiedy to rozumiesz, diagnoza przestaje być zgadywaniem i przechodzi w serię sensownych testów.
Warto też pamiętać, że Safari, Edge czy Firefox potrafią pokazywać podobny komunikat, tylko innymi słowami. Dlatego zamiast walczyć z nazwą błędu, lepiej szybko ustalić, gdzie dokładnie zawiódł mechanizm rozwiązywania domeny.

Jak szybko ustalić, czy problem jest lokalny czy leży po stronie domeny
Najpierw odróżniam problem lokalny od błędu po stronie domeny. To oszczędza czas, bo inaczej łatwo w kółko resetować rzeczy, które nie mają wpływu na wynik.
| Objaw | Co to zwykle oznacza | Co sprawdzić najpierw |
|---|---|---|
| Nie działa tylko jedna domena | Problem z rekordami DNS, delegacją albo samą nazwą hosta | Sprawdź literówkę, wersję www i rekordy A/AAAA
|
| Nie działa na jednym urządzeniu, a na innym tak | Lokalny cache, profil przeglądarki, hosts albo filtr bezpieczeństwa | Uruchom stronę w trybie prywatnym i porównaj z innym urządzeniem |
| Działa na LTE, nie działa na Wi-Fi | DNS routera, filtr operatora, proxy albo problem z siecią domową | Wyłącz VPN, zmień DNS i zrestartuj router |
| Nie działa w jednej przeglądarce, a w innej tak | Secure DNS, rozszerzenie albo uszkodzony profil | Sprawdź tryb incognito i ustawienia DNS w przeglądarce |
| Nie działa wszędzie i dla wszystkich | Poważniejszy problem po stronie domeny lub jej serwerów DNS | Zweryfikuj nameservery, rekordy i status domeny u operatora |
Jeśli chcesz mieć jeszcze szybszy obraz sytuacji, otwórz tę samą stronę na telefonie przez komórkowy internet i w prywatnym oknie przeglądarki. Gdy wynik się zmienia, masz już mocną wskazówkę, czy szukać winy w lokalnej sieci, czy w samej domenie. Po takim teście przechodzę zawsze do napraw, zaczynając od rzeczy najmniej inwazyjnych.
Najskuteczniejsze kroki naprawy, od najprostszych do najbardziej technicznych
-
Sprawdź adres i wariant domeny. Literówka, brak
wwwalbo odwrotnie, a czasem zły subdomena, to banalny błąd, który wygląda jak awaria DNS. To pierwszy test, bo kosztuje najmniej czasu. -
Wyłącz VPN, proxy i filtry DNS. Programy ochronne, firmowe bramy i aplikacje do blokowania reklam potrafią przejąć zapytanie DNS albo zwrócić lokalnie fałszywy wynik. Jeśli strona zaczyna działać po wyłączeniu takiej warstwy, masz odpowiedź.
-
Odśwież cache DNS systemu. Na Windows najprostszy krok to
ipconfig /flushdns. To nie naprawi błędnej domeny, ale usuwa lokalny, stary wpis, który mógł blokować poprawny wynik. Na Macu możesz też sprawdzić ustawienia DNS w Network > DNS i przełączyć się na inny resolver, jeśli podejrzewasz problem z obecnym. -
Przetestuj publiczny DNS. Zmiana na resolver taki jak
1.1.1.1albo8.8.8.8to dobry ruch diagnostyczny, bo od razu oddziela problem operatora od problemu domeny. Ja traktuję to jako test, a nie obowiązkową konfigurację na stałe. -
Uruchom stronę w trybie prywatnym albo w czystym profilu. Jeśli tam działa, winne bywają rozszerzenia, zapisane dane profilu albo ustawienia przeglądarki. To szczególnie ważne, gdy problem występuje tylko w jednej aplikacji.
-
Zrestartuj router i urządzenie. To proste, ale bywa skuteczne, zwłaszcza gdy router trzyma stary DNS lub chwilowo źle obsługuje połączenie z dostawcą internetu. Taki restart nie jest magią, tylko sposobem na odświeżenie warstwy sieciowej.
-
Sprawdź plik
hosts, jeśli ktoś wcześniej go modyfikował. To rzadziej spotykane, ale bardzo istotne w środowiskach technicznych. Jeden wpis może przekierować domenę na zły adres albo zablokować ją lokalnie, przez co przeglądarka będzie zachowywać się tak, jakby domena nie istniała.
Jeżeli podstawowe ruchy nie pomagają, patrzę już na samą przeglądarkę, bo to tam często siedzi ostatnia, trudna do zauważenia przeszkoda. Właśnie wtedy największą różnicę robią ustawienia Secure DNS i rozszerzenia.
Ustawienia przeglądarki, które najczęściej mieszają w DNS
Chrome i przeglądarki oparte na Chromium
W Chrome Secure DNS jest domyślnie włączony w trybie automatycznym. Jeśli używasz własnego dostawcy DNS i pojawia się komunikat o braku adresu IP, najpierw sprawdzam właśnie ten punkt: czy provider działa poprawnie, czy nie trzeba chwilowo przełączyć go na domyślny albo całkiem wyłączyć Secure DNS. To ważne, bo własny resolver bywa szybszy i bezpieczniejszy, ale gdy ma awarię lub filtruje zbyt agresywnie, psuje cały efekt.
W Edge, Brave i Operze logika jest podobna, bo te przeglądarki korzystają z tego samego silnika. Jeśli prywatne okno działa, a zwykły profil nie, podejrzewam rozszerzenie, lokalny cache lub uszkodzone ustawienie profilu. Nie resetuję wszystkiego od razu, bo często wystarczy wyłączyć jeden dodatek albo przywrócić ustawienia DNS do automatu.
Tryb prywatny i profile użytkownika
Tryb prywatny nie naprawia sieci, ale omija część danych zapisanych w profilu, więc świetnie nadaje się do testu. Jeśli strona działa tylko tam, wina zwykle nie leży w domenie, tylko w stanie przeglądarki. Wtedy zamiast szukać problemu po stronie hostingu, szybciej dojdziesz do rozszerzenia, cache albo ustawienia, które blokuje ruch.
Przeczytaj również: Jak zaktualizować aplikację Sklep Play i uniknąć problemów z aktualizacjami
Firefox i inne wyjątki
W Firefoxie warto uruchomić tryb rozwiązywania problemów i porównać wynik z normalnym profilem. Gdy zachowanie się zmienia, wiadomo już, że problem jest po stronie dodatków lub lokalnej konfiguracji, a nie w samej domenie. To dobra metoda, bo oszczędza czas i nie wymaga zgadywania, czy awaria leży po stronie przeglądarki czy DNS.
Jeżeli jednak problem dotyczy nie jednego urządzenia, lecz całej domeny, trzeba zajrzeć do DNS po stronie właściciela. W praktyce właśnie tam najczęściej zaczyna się prawdziwa naprawa.
Gdy to Twoja domena, sprawdź rekordy, delegację i czas propagacji
Gdy zarządzam własną domeną, zaczynam od rekordów i delegacji, nie od przeglądarki. To właśnie tutaj najczęściej leży błąd, zwłaszcza po migracji hostingu albo świeżej rejestracji.
| Element | Rola | Typowy problem |
|---|---|---|
A |
Wskazuje adres IPv4 serwera | Rekord prowadzi na stary serwer albo w ogóle go brak |
AAAA |
Wskazuje adres IPv6 | IPv6 jest źle skonfigurowane, a część klientów próbuję najpierw jego |
CNAME |
Tworzy alias dla subdomeny |
www działa, ale domena główna nie ma odpowiedniego wpisu |
NS |
Pokazuje, kto obsługuje strefę DNS | Po zmianie hostingu nadal wskazuje stary panel |
Po zmianach nie oczekuj efektu w sekundę. Propagacja DNS, czyli rozchodzenie się nowych informacji do kolejnych resolverów, zwykle trwa od kilku minut do 24 godzin, a czasem dłużej, jeśli po drodze były stare cache albo wysoki TTL. TTL to czas życia wpisu w pamięci podręcznej, więc przy wartości 300 sekund zmiana rozchodzi się szybciej niż przy 3600 sekundach.
Jeśli domena właśnie wygasła, jest w holdzie albo nameservery wskazują na stary panel, przeglądarka nie ma czego rozwiązać i komunikat będzie powracał bez względu na to, co zrobisz lokalnie. W takich sytuacjach kontakt z rejestratorem lub hostingiem jest po prostu szybszy niż kolejne próby w przeglądarce.
Jak ograniczyć powrót problemu po kolejnej zmianie DNS
Najwięcej problemów widzę po szybkich migracjach i chaotycznych zmianach rekordów. Da się to ograniczyć kilkoma nawykami, które są prostsze niż późniejsze gaszenie pożaru.
- Przed planowaną zmianą obniż TTL do 300 sekund, a po stabilizacji przywróć wartość docelową, na przykład 3600 sekund.
- Trzymaj DNS w jednym, jasno opisanym panelu. Rozproszenie między rejestratorem, hostingiem i CDN-em kończy się pomyłkami.
- Po wdrożeniu sprawdź domenę z dwóch niezależnych sieci, najlepiej z domowego Wi-Fi i z LTE.
- Jeśli używasz firmowego filtra DNS, zapisz, jaki resolver obsługuje użytkowników. Bez tego trudno odróżnić awarię od blokady.
- Przy nowych domenach zakładaj, że część resolverów będzie pamiętała stare odpowiedzi jeszcze przez jakiś czas.
W praktyce to właśnie porządek w DNS, a nie kolejny „magiczny” reset przeglądarki, najczęściej decyduje o tym, czy błąd wróci po kilku dniach. Jeśli po tych krokach problem nadal dotyczy tylko jednej domeny, mam już twardy sygnał, że trzeba wrócić do konfiguracji po stronie właściciela albo operatora sieci.