W praktyce polecenie flush dns jest pierwszym ruchem, gdy po zmianie domeny albo rekordu DNS strona nadal kieruje na stary adres. W tym tekście pokazuję, kiedy takie odświeżenie ma sens, jak zrobić je na Windows, macOS i Linux oraz jak odróżnić lokalny cache od problemu w samej strefie DNS. Dzięki temu nie będziesz tracić czasu na poprawki, które nie mają szans zadziałać.
Najważniejsze rzeczy, które warto zapamiętać
- Odświeżasz lokalny cache DNS, a nie zmieniasz rekordów w internecie.
- Najczęściej pomaga po zmianie adresu IP domeny, migracji hostingu albo błędnym wpisie, który utknął w pamięci komputera.
- Na Windows używa się zwykle
ipconfig /flushdns, na macOS komendy zmDNSResponder, a na współczesnym Linuxieresolvectl flush-caches. - Jeśli problem występuje na wielu urządzeniach, źródło zwykle leży w DNS strefy, TTL albo po stronie dostawcy, a nie na jednym komputerze.
- Po czyszczeniu cache dobrze jest ponownie otworzyć przeglądarkę i sprawdzić domenę z innej sieci albo przez narzędzie typu
nslookuplubdig.
Kiedy odświeżenie lokalnego cache DNS ma sens
Najprościej mówiąc, lokalny resolver pamięta odpowiedzi DNS, żeby szybciej otwierać strony i mniej obciążać sieć. Gdy zmieniasz rekord A lub AAAA, przenosisz stronę na nowy serwer albo poprawiasz błędnie ustawioną domenę, komputer może jeszcze przez chwilę trzymać stary adres IP w pamięci. Właśnie wtedy takie odświeżenie bywa pierwszym, sensownym krokiem.
Patrzę na to tak: jeśli problem dotyczy jednego urządzenia, a inne komputery w tej samej sieci widzą już poprawny adres, winny jest zwykle cache. Jeśli błąd widzi każdy, nawet po zmianie sieci, to podejrzenie powinno paść na strefę DNS, propagację lub TTL rekordu. To rozróżnienie oszczędza dużo czasu, bo nie każda awaria domeny jest lokalna.
Warto też pamiętać, że DNS nie działa w próżni. Przeglądarka, system operacyjny, aplikacja VPN i sam dostawca internetu mogą mieć własne warstwy pamięci podręcznej, więc objaw „domena nadal wskazuje stary serwer” nie zawsze ma jedną przyczynę. Z tego powodu najpierw ustalam, gdzie dokładnie zapisał się stary adres, a dopiero potem czyszczę odpowiednią warstwę.
Skoro wiadomo, kiedy warto reagować, dobrze jest zrozumieć, co właściwie usuwa to polecenie i czego nie naprawi.
Co dokładnie czyści to polecenie
Komenda nie zmienia rekordu DNS w panelu domeny ani nie przyspiesza globalnej propagacji. Usuwa wyłącznie wpisy z lokalnego cache resolvera, czyli pamięci, z której korzysta Twój komputer podczas tłumaczenia nazwy domeny na adres IP. To cache przyspiesza pracę, ale czasem przez tę samą optymalizację trzyma już nieaktualne dane.
W praktyce oznacza to trzy ważne rzeczy. Po pierwsze, odświeżenie nie pomoże, jeśli w strefie domeny wpisano zły adres IP. Po drugie, nie wyczyści cache na routerze ani u innych użytkowników. Po trzecie, nie zmieni czasu życia rekordu, czyli TTL, które decyduje o tym, jak długo odpowiedź może być przechowywana po drodze. TTL bywa ustawiony na 300, 900 albo 3600 sekund, ale konkret zależy od konfiguracji domeny.
Jeśli więc rekord został zmieniony dopiero przed chwilą, a poprzedni adres miał krótkie TTL, lokalne odświeżenie może pomóc szybciej zobaczyć nową wartość. Jeżeli jednak problem siedzi w samej strefie, komenda tylko ukryje objaw na chwilę. Z takim ograniczeniem najłatwiej przejść do konkretów i sprawdzić, jak wykonać operację na najpopularniejszych systemach.
Jak wykonać odświeżenie DNS w Windows, macOS i Linux
Najczęstszy błąd to szukanie jednego uniwersalnego polecenia dla wszystkich systemów. W praktyce każdy system ma własny mechanizm cache, więc warto znać właściwą komendę dla swojej platformy. Poniżej zestawiam najczęściej używane warianty, które sprawdzają się w bieżących środowiskach.
| System | Polecenie | Co warto wiedzieć |
|---|---|---|
| Windows | ipconfig /flushdns |
Najprostszy i najczęściej używany wariant; zwykle wystarczy w wierszu polecenia lub PowerShell. |
| Windows PowerShell | Clear-DnsClientCache |
To równoważna komenda w PowerShell, wygodna w automatyzacji i skryptach administracyjnych. |
| macOS | sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder |
Na współczesnym macOS to najbezpieczniejszy punkt wyjścia; komenda czyści lokalny cache i odświeża usługę odpowiedzialną za rozwiązywanie nazw. |
| Linux z systemd-resolved | resolvectl flush-caches |
To obecnie preferowany wariant w dystrybucjach korzystających z systemd-resolved. |
| Starsze środowiska Linux | systemd-resolve --flush-caches |
Spotykane na starszych konfiguracjach; jeśli system nie używa lokalnego resolvera, może nie być czego czyścić. |
- Zamknij przeglądarkę, jeśli jest otwarta, żeby nie trzymała własnej sesji podglądu.
- Uruchom terminal, wiersz polecenia albo PowerShell zależnie od systemu.
- Wpisz właściwą komendę i poczekaj na powrót do promptu.
- Otwórz domenę ponownie albo sprawdź ją narzędziem typu
nslookuplubdig.
Na ekranie zwykle nie zobaczysz efektu w stylu „sukces”, bo komenda po prostu czyści cache. Jeśli działasz na firmowym laptopie z ograniczeniami, może się zdarzyć, że potrzebujesz uprawnień administratora albo że lokalny resolver działa inaczej niż na domowym komputerze. To normalne i nie oznacza, że sama metoda jest zła.
Jeśli sam terminal nie rozwiąże sprawy, zazwyczaj problem nie siedzi już w pamięci podręcznej komputera, tylko głębiej w samej domenie albo w drodze do niej.
Dlaczego domena nadal pokazuje stary adres
Najczęściej winny jest jeden z pięciu scenariuszy. Pierwszy to propagacja zmian, czyli czas potrzebny na odświeżenie danych w różnych resolverach po drodze. Drugi to TTL ustawiony zbyt wysoko jak na dynamikę zmian. Trzeci to lokalny cache przeglądarki lub aplikacji, który nie został odświeżony razem z cache systemowym. Czwarty to wpis w pliku hosts, który ręcznie nadpisuje DNS. Piąty to pomyłka w samej strefie, na przykład błędny rekord A, AAAA albo CNAME.
W domenach szczególnie mylące jest to, że zmiana może wyglądać poprawnie w panelu, a mimo to odwiedzający nadal trafiają na stary serwer. Dzieje się tak wtedy, gdy część resolverów ma już nowy rekord, a część nadal korzysta ze starej odpowiedzi. Właśnie dlatego czasem warto sprawdzić domenę z dwóch różnych sieci lub porównać odpowiedź lokalną z publicznym resolverem. Jeśli wyniki się różnią, problem jest raczej po stronie cache lub propagacji niż w aplikacji na komputerze.
To również moment, w którym nie warto ufać jedynie temu, co pokazuje przeglądarka. Dla porządku sprawdzam wtedy domenę narzędziem typu nslookup albo dig, bo daje mi to prostszy obraz tego, który adres faktycznie zwraca resolver. Taki test często szybciej wskazuje źródło błędu niż wielokrotne odświeżanie strony.
Gdy przyczyna jest już znana, łatwiej uniknąć kilku powtarzalnych pomyłek, które tylko wydłużają diagnozę.
Najczęstsze błędy przy czyszczeniu cache
Największy błąd, jaki obserwuję, to oczekiwanie, że jedna komenda naprawi każdą awarię domeny. To nie działa. Jeśli rekord jest błędny w panelu DNS, komputer tylko pobierze błędną odpowiedź od nowa. Jeśli problem dotyczy całej firmy albo całego hostingu, lokalne odświeżenie niczego nie zmieni.
- Mylenie cache DNS z cache przeglądarki. To dwie różne warstwy i czasem trzeba odświeżyć obie.
- Uruchamianie złej komendy dla danego systemu.
ipconfig /flushdnsdotyczy Windows, a nie Linuxa. - Zakładanie, że odnowienie adresu IP czy połączenia Wi-Fi to to samo co czyszczenie resolvera.
- Pomijanie pliku hosts, który potrafi ręcznie wskazać konkretny adres i całkowicie ominąć DNS.
- Sprawdzanie domeny zaraz po zmianie, bez uwzględnienia TTL i czasu propagacji.
W firmowych środowiskach dochodzi jeszcze jeden problem: VPN albo firmowy resolver może trzymać własną warstwę pamięci i dawać inne wyniki niż lokalna karta sieciowa. Wtedy test wykonany poza siecią firmową bywa bardziej miarodajny niż kolejne próby na tym samym łączu. Dopiero po wykluczeniu tych pułapek warto iść krok dalej i zrobić pełną kontrolę konfiguracji domeny.
Gdy domena nadal kieruje na stary adres
Kiedy odświeżenie lokalnego cache nie pomaga, zaczynam od prostego checklistu. Najpierw porównuję aktualny rekord A lub AAAA z tym, co widzą zewnętrzne resolvery. Potem sprawdzam TTL, bo przy krótkich wartościach zmiana powinna się pojawić szybciej, a przy dłuższych trzeba po prostu poczekać. Na końcu patrzę na rekord CNAME, serwer DNS autorytatywny i ewentualny wpis w hosts.- Jeśli domena ma nowy hosting, potwierdzam, czy rekord wskazuje dokładnie ten adres, który powinien.
- Jeśli zmieniałeś nameservery, sprawdzam, czy delegacja została już poprawnie podniesiona po stronie rejestratora.
- Jeśli problem dotyczy tylko jednej przeglądarki, testuję ją osobno, bo aplikacje potrafią mieć własny cache.
- Jeśli problem dotyczy jednej sieci, testuję tę samą domenę przez hotspot lub inne łącze, żeby odciąć lokalnego operatora.
To podejście jest bardziej skuteczne niż samo powtarzanie tej samej komendy. W praktyce lokalne odświeżenie jest szybkim narzędziem diagnostycznym, ale nie zastępuje sprawdzenia konfiguracji domeny, TTL i propagacji. Jeśli po tych testach wszystko nadal wskazuje na stary adres, zwykle warto wrócić do panelu DNS lub zgłosić sprawę dostawcy hostingu, bo problem leży już poza komputerem.
