DNS_PROBE_FINISHED_NXDOMAIN oznacza, że Chrome nie zdołał ustalić adresu IP strony, choć Twój DNS ogólnie działa. Jako odwiedzający sprawdź adres, wyczyść pamięć podręczną DNS i spróbuj innego serwera DNS. Jako właściciel strony uruchom dig i odczytaj status: NXDOMAIN, puste NOERROR i SERVFAIL wskazują na różne przyczyny, mimo że przeglądarka pokazuje dla wszystkich trzech ten sam kod.
Odtworzyliśmy typowe scenariusze w izolowanym laboratorium DNS i zapisaliśmy prawdziwe wyniki dig, nslookup, host i Chromium. Poniżej: co oznacza każda odpowiedź, jak długo trwa negatywne cache oraz tabela „co pokazuje dig -> przyczyna -> rozwiązanie”.
Jak testowaliśmy
Stanowisko testowe RichHost, izolowany kontener Ubuntu 24.04 (2 vCPU / 8 GB), październik 2026. Autorytatywne serwery BIND 9.18.39 z własnym „rootem”, strefą test. i jedną domeną na każdy scenariusz; rekurencyjny resolver Unbound 1.19.2 z walidacją DNSSEC; jako klienci DiG 9.18.39 i Chromium 141 (headless). Publiczny DNS jest z kontenera niedostępny, dlatego wszystkie nazwy są testowe (domena .test jest zarezerwowana w RFC 6761), a adresy pochodzą z zakresów dokumentacyjnych 192.0.2.0/24 i 198.51.100.0/24. To wyniki laboratoryjne, a nie dane z produkcyjnej infrastruktury RichHost.
Co naprawdę mówi DNS_PROBE_FINISHED_NXDOMAIN
Gdy nazwa się nie rozwiązuje, Chrome dostaje wewnętrzny błąd ERR_NAME_NOT_RESOLVED (kod -105, „The host name could not be resolved”) i uruchamia sondę: przez Twój obecny DNS rozwiązuje nazwę, która na pewno działa, czyli google.com. Jeśli to się uda, Chrome wnioskuje „DNS działa, więc domena nie istnieje” i pokazuje DNS_PROBE_FINISHED_NXDOMAIN. Tak opisuje to kod źródłowy Chromium (dns_probe_service_impl.cc, net_error_info.h). Kod opisuje więc stan Twojego DNS, a nie rodzaj odpowiedzi, którą dostała nazwa strony.
Sprawdziliśmy to w laboratorium, otwierając w Chromium 141 nazwy z różnymi usterkami.
| Co zepsuło się w DNS | Status w dig | Co pokazał Chromium 141 |
|---|---|---|
| Domena nie istnieje | NXDOMAIN | DNS_PROBE_FINISHED_NXDOMAIN |
| Nazwa istnieje, ale nie ma rekordu A | NOERROR, ANSWER: 0 | DNS_PROBE_FINISHED_NXDOMAIN |
| Serwer nazw domeny nie obsługuje strefy | SERVFAIL | DNS_PROBE_FINISHED_NXDOMAIN |
| Wygasłe podpisy DNSSEC | SERVFAIL, EDE 7 | DNS_PROBE_FINISHED_NXDOMAIN |
| To samo, ale sonda google.com też zawiodła | NXDOMAIN | ERR_NAME_NOT_RESOLVED |
| Nazwa wpisana w pliku hosts | NXDOMAIN | ERR_ADDRESS_UNREACHABLE (przeglądarka użyła IP z hosts) |
Wniosek: jeden kod przeglądarki może ukrywać cztery różne usterki. Zwykły ERR_NAME_NOT_RESOLVED zostaje na ekranie, gdy sonda nie daje jednoznacznego wyniku. Jeśli Twój DNS nie działa, ale Google DNS tak, Chrome pokazuje DNS_PROBE_FINISHED_BAD_CONFIG; jeśli Google DNS też jest niedostępny, DNS_PROBE_FINISHED_NO_INTERNET.
Odwiedzający: naprawa w 5 minut
- Sprawdź adres. Dodatkowa litera (wwww) lub zła końcówka domeny daje prawdziwe NXDOMAIN.
- Otwórz stronę na telefonie przez dane komórkowe. Jeśli tam działa, problem leży w Twoim cache, w DNS routera lub u dostawcy internetu. Jeśli nie, problem jest po stronie właściciela i możesz tylko poczekać albo się z nim skontaktować.
- Wyczyść cache Chrome: otwórz
chrome://net-internals/#dnsi kliknij Clear host cache (w Chromium 141 przycisk nazywa się dokładnie tak). - Wyczyść cache systemu poleceniami poniżej.
- Wyłącz VPN, filtry DNS i ochronę WWW w antywirusie albo ustaw inny serwer DNS (1.1.1.1, 8.8.8.8) w ustawieniach sieci. W Chrome sprawdź też Ustawienia -> Prywatność i bezpieczeństwo -> Bezpieczeństwo -> Używaj bezpiecznego DNS.
# Windows (Command Prompt as administrator) ipconfig /flushdns # macOS sudo killall -HUP mDNSResponder # Linux with systemd-resolved resolvectl flush-caches
Microsoft podaje, że ipconfig /flushdns usuwa też wpisy negatywnego cache (dokumentacja ipconfig). Polecenie dla macOS pochodzi z artykułu pomocy Apple.
Właściciele stron: jak czytać wynik dig
dig yourdomain A (w Windows nslookup) pokazuje status w linii HEADER. Poniżej prawdziwe wyniki z laboratorium, skrócone do istotnych linii.
1. NXDOMAIN: nazwa nie istnieje. AUTHORITY pokazuje, kto tak twierdzi
$ dig moi-sait-neisnuie.test ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36364 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; AUTHORITY SECTION: test. 3600 IN SOA ns1.test. hostmaster.test. 1 7200 3600 1209600 3600 $ nslookup moi-sait-neisnuie.test ** server can't find moi-sait-neisnuie.test: NXDOMAIN $ host moi-sait-neisnuie.test Host moi-sait-neisnuie.test not found: 3(NXDOMAIN) $ dig wwww.lab.test ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40202 ;; AUTHORITY SECTION: lab.test. 300 IN SOA ns1.lab.test. hostmaster.lab.test. 2026102501 7200 3600 1209600 300
Najcenniejsza wskazówka to rekord SOA w sekcji AUTHORITY. Jeśli to SOA domeny najwyższego poziomu (w praktyce com., ua., org.), rejestr informuje, że domena nie jest delegowana: nie jest zarejestrowana, wygasła albo ma status clientHold lub serverHold, które według definicji ICANN wyłączają domenę z DNS. Jeśli to SOA Twojej własnej strefy (jak lab.test. w drugim przykładzie), delegacja jest w porządku, ale w strefie brakuje tej konkretnej nazwy: zapomnianego www lub subdomeny.
2. NOERROR z pustą odpowiedzią: nazwa istnieje, rekord A nie
$ dig lab.test A ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10630 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; AUTHORITY SECTION: lab.test. 287 IN SOA ns1.lab.test. hostmaster.lab.test. 2026102501 ... $ nslookup lab.test *** Can't find lab.test: No answer $ host lab.test lab.test mail is handled by 10 mail.lab.test. $ dig +short www.lab.test 192.0.2.10
Typowy przypadek: rekord A utworzono tylko dla www, a o apeksie (@) zapomniano. NOERROR wprowadza w błąd: nie ma żadnego „błędu”, a mimo to ANSWER wynosi 0. host jest jeszcze bardziej podchwytliwy: bez podania typu wyświetlił tylko rekord MX, co wygląda na sukces. Zawsze podawaj typ: host -t A lab.test odpowiedział „lab.test has no A record”. Jak współgrają rekordy A, CNAME i MX, wyjaśniamy w poradniku o rekordach DNS i zarządzaniu domeną.
3. SERVFAIL: zepsuta delegacja lub DNSSEC
SERVFAIL oznacza, że resolver nie zdołał uzyskać wiarygodnej odpowiedzi. Odtworzyliśmy trzy przyczyny.
# The nameserver answers but does not host the zone (lame delegation) $ dig www.lame.test ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30167 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; Query time: 4 msec $ dig +norec @127.0.0.3 www.lame.test # straight to the domain's NS ;; ->>HEADER<<- opcode: QUERY, status: REFUSED # Expired DNSSEC signatures $ dig www.signed.test ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 13020 ; EDE: 7 (Signature Expired): (validation failure <www.signed.test. A IN>: signature expired from 127.0.0.2 for trust anchor signed.test. ...) $ dig +cd www.signed.test # validation disabled ;; ->>HEADER<<- opcode: QUERY, status: NOERROR www.signed.test. 3600 IN A 192.0.2.50 # The nameserver does not answer at all $ time dig +time=200 +tries=1 www.broken.test ;; communications error to 127.0.0.1#53: timed out ;; no servers could be reached real 3m20.124s $ dig www.broken.test # second query ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
REFUSED przy bezpośrednim zapytaniu oznacza, że domena jest delegowana na serwer, który nie ma dla niej strefy. Zwykle zdarza się to po przeprowadzce, gdy u rejestratora wciąż wpisane są serwery nazw starego hostingu. Zobacz jak zmienić serwery nazw domeny. Nowoczesne resolvery dodają linię EDE (Extended DNS Errors, RFC 8914), która często wprost podaje przyczynę. Jeśli z +cd jest odpowiedź, a zwykłe zapytanie zwraca SERVFAIL, łańcuch DNSSEC jest zerwany: nieaktualny rekord DS u rejestratora albo wygasłe podpisy. Niedziałający serwer nazw zachował się inaczej: pierwsze zapytanie do Unbound przez 200 sekund nie dostało odpowiedzi, a następne od razu zwróciło SERVFAIL, gdy resolver oznaczył serwer jako niedostępny.
4. Negatywne cache: dlaczego dopiero dodanego rekordu „nie ma”
Resolver zapisuje NXDOMAIN w cache tak samo jak zwykłą odpowiedź. RFC 2308 ustala czas na mniejszą z dwóch wartości: TTL samego rekordu SOA i pole MINIMUM w SOA (ostatnia liczba). Dla lab.test daje to min(3600, 300) = 300 sekund. Odpytaliśmy nieistniejącą nazwę, 20 sekund później dodaliśmy rekord, przeładowaliśmy strefę i odpytywaliśmy resolver co 5 sekund:
T+0 23:52:16 first query: status: NXDOMAIN
lab.test. 300 IN SOA ns1.lab.test. hostmaster.lab.test. 2026102503 7200 3600 1209600 300
T+21 23:52:37 record added, authoritative now says: 192.0.2.79
T+21 23:52:37 resolver: status: NXDOMAIN neg-TTL-left=279
T+152 23:54:48 resolver: status: NXDOMAIN neg-TTL-left=148
T+298 23:57:14 resolver: status: NXDOMAIN neg-TTL-left=2
T+303 23:57:19 resolver: status: NOERROR
novyi3.lab.test. 3600 IN A 192.0.2.79
Rekord był już na serwerze autorytatywnym, a resolver jeszcze przez 282 sekundy (od T+21 do T+303) twierdził, że nazwa nie istnieje: dokładnie do wygaśnięcia negatywnego TTL wynoszącego 300 sekund. Odliczanie zaczyna się w chwili, gdy resolver zapisał NXDOMAIN w cache, a nie wtedy, gdy dodajesz rekord. W drugim przebiegu z inną nazwą Unbound wykorzystał pozostały TTL już zapisanego SOA (258 sekund zamiast 300) i rekord pojawił się 241 sekund po dodaniu. Czas oczekiwania wynosi więc od zera do pełnego negatywnego TTL, zależnie od tego, kiedy ktoś pierwszy raz zapytał o nazwę. Po Twojej stronie jedynym skrótem jest wyczyszczenie cache resolvera: Google Public DNS ma formularz Flush Cache, Cloudflare stronę Purge Cache, a w przypadku resolvera dostawcy internetu pozostaje czekać. Dlatego nie testuj nowej subdomeny w przeglądarce, zanim rekord zostanie utworzony.
5. Plik hosts: dig i przeglądarka się nie zgadzają
$ tail -2 /etc/hosts 192.0.2.200 moi-sait-neisnuie.test 198.51.100.5 www.lab.test $ getent hosts moi-sait-neisnuie.test 192.0.2.200 moi-sait-neisnuie.test $ dig moi-sait-neisnuie.test | grep -oE "status: [A-Z]+" status: NXDOMAIN $ getent hosts www.lab.test 198.51.100.5 www.lab.test $ dig +short www.lab.test 192.0.2.10 $ curl -v http://www.lab.test/ * Trying 198.51.100.5:80...
dig, nslookup i host odpytują serwer DNS bezpośrednio i ignorują plik hosts. Przeglądarki, curl i inne programy najpierw czytają hosts (w Windows to C:\Windows\System32\drivers\etc\hosts). Linia pozostawiona po testach migracji daje efekt „widzę starą stronę, a dig pokazuje nowe IP”. Testuj tak, jak rozwiązuje przeglądarka: getent hosts w Linuksie, ping w Windows i macOS.
Tabela decyzyjna: co pokazuje dig -> przyczyna -> rozwiązanie
| Co widzisz | Przyczyna | Rozwiązanie |
|---|---|---|
| NXDOMAIN, SOA domeny najwyższego poziomu (com., ua.) w AUTHORITY | Domena niezarejestrowana, wygasła lub zawieszona (hold) | Sprawdzić whois, odnowić, zweryfikować NS u rejestratora |
| NXDOMAIN, SOA Twojej strefy w AUTHORITY | W strefie brakuje nazwy (www, subdomena) | Dodać rekord A lub CNAME |
| NXDOMAIN, AUTHORITY: 0, Query time 0 ms, nawet dla google.com | Odpowiedź generuje filtr, VPN, antywirus lub sieć | Sprawdzić przez inny resolver, wyłączyć filtr |
| NOERROR, ANSWER: 0 | Nazwa istnieje, ale nie ma A/AAAA (często apeks @) | Dodać rekord A dla tej nazwy |
| SERVFAIL, bezpośrednie zapytanie do NS zwraca REFUSED | Serwer nazw nie obsługuje strefy | Utworzyć strefę na serwerze DNS lub poprawić NS u rejestratora |
SERVFAIL, odpowiedź z +cd, EDE 6-10 |
Zepsuty DNSSEC | Zaktualizować lub usunąć DS u rejestratora, ponownie podpisać strefę |
| timed out, no servers could be reached | NS domeny lub Twój resolver nie odpowiada | Odpytać NS bezpośrednio, sprawdzić serwer i port 53 UDP/TCP |
| NXDOMAIN po dodaniu rekordu | Negatywne cache resolvera | Odczekać min(TTL SOA, MINIMUM) lub wyczyścić cache resolvera |
| dig pokazuje właściwe IP, przeglądarka trafia gdzie indziej | Wpis w hosts lub cache systemu albo przeglądarki | Sprawdzić getent hosts i plik hosts, wyczyścić cache |
Jeszcze jeden przypadek złapaliśmy w samym kontenerze: dig @8.8.8.8 google.com zwrócił NXDOMAIN w 0 ms bez niczego w AUTHORITY, bo wychodzący ruch DNS był przechwytywany. Prawdziwe NXDOMAIN z rejestru zawsze zawiera SOA strefy. Jeśli go brak, a nawet google.com „nie istnieje”, szukaj filtra między sobą a internetem.
Naprawa po stronie domeny
- Odnów domenę, jeśli WHOIS pokazuje minioną datę wygaśnięcia albo statusy clientHold, serverHold, redemptionPeriod. Delegacja wraca po opłaceniu, ale resolvery, które już zapisały NXDOMAIN w cache, trzymają je do wygaśnięcia negatywnego TTL domeny najwyższego poziomu, w granicach własnego limitu (Unbound 1.19.2 domyślnie ma
cache-max-negative-ttl: 3600, czyli godzinę). Rejestracja i odnowienie są na stronie domeny w RichHost. - Utwórz strefę na serwerze, na który delegowana jest domena. W panelu sterowania hostingu otwórz sekcję DNS i dodaj strefę; panel zwykle tworzy standardowe rekordy, w tym rekord A kierujący domenę na IP serwera.
- Dodaj brakujące rekordy: A dla @, A lub CNAME dla www i subdomen.
- Przed zmianą dostawcy DNS przy włączonym DNSSEC najpierw usuń stary DS u rejestratora, odczekaj jego TTL, a dopiero potem zmień NS.
- Sprawdź bezpośrednim zapytaniem do serwera nazw (
dig +norec @ns1.your-dns yourdomain) oraz przez 2-3 publiczne resolvery.
FAQ
Czy ERR_NAME_NOT_RESOLVED i DNS_PROBE_FINISHED_NXDOMAIN to różne błędy?
Nie, przyczyna jest ta sama: nazwa się nie rozwiązała. Chrome przełącza się na kod NXDOMAIN, gdy jego sonda potwierdzi, że Twój DNS działa. Jeśli wynik sondy jest niejednoznaczny, zostaje ERR_NAME_NOT_RESOLVED; dokładnie to widzieliśmy w laboratorium, dopóki nazwa sondy google.com też się nie rozwiązywała.
Dlaczego strona otwiera się koledze, a mnie nie?
Różne resolvery i różne cache. Resolver kolegi nigdy nie pytał o nazwę, zanim rekord powstał, a Twój trzyma negatywną odpowiedź do wygaśnięcia jej TTL. Albo jeden resolver waliduje DNSSEC, a drugi nie.
Ile czekać po dodaniu rekordu?
Dla nazwy, o którą nikt jeszcze nie pytał, wcale. Dla nazwy, która dostała już NXDOMAIN, do min(TTL SOA, MINIMUM) Twojej strefy; dla świeżo odnowionej domeny do wartości SOA domeny najwyższego poziomu, ograniczonej przez resolver.
Czy odwiedzający może to naprawić, jeśli domena wygasła?
Nie. Gdy AUTHORITY pokazuje SOA domeny najwyższego poziomu, domena jest wyłączona w rejestrze i naprawić to może tylko właściciel, odnawiając ją.
