Po migracji hostingu strona przestaje działać, poczta nie dochodzi, a w przeglądarce widzisz komunikat o DNS? To jeden z najczęstszych i najbardziej frustrujących problemów po przenosinach. Na pierwszy rzut oka wygląda jak awaria nowego serwera, ale w praktyce bardzo często winny jest nie hosting, tylko warstwa DNS: domena nadal wskazuje na stary adres IP, rekordy zostały przeniesione niekompletnie, a zmiana serwerów nazw jeszcze się nie rozpropagowała.
W tym artykule pokazuję, jak odróżnić zwykłe opóźnienie propagacji od realnej błędnej konfiguracji, jak krok po kroku zdiagnozować problem i co zrobić, żeby przywrócić działanie strony bez powielania błędów. Tekst jest napisany z perspektywy realnego scenariusza: domena już została przeniesiona albo hosting zmieniony, a witryna nadal zwraca błąd, przekierowuje na starą wersję albo nie wysyła poczty.
Jeśli zależy Ci na szybkim efekcie, najważniejsza myśl brzmi: błąd DNS po migracji hostingu najczęściej naprawia się przez sprawdzenie serwerów nazw, rekordów A/AAAA/CNAME/MX oraz poprawność wpisów dla poczty i SSL. Sam restart serwera nic nie da, jeśli domena nadal „patrzy” w złe miejsce.
Szybka odpowiedź
Jeżeli po migracji hostingu strona nie działa, zacznij od trzech rzeczy:
- sprawdź, czy domena ma ustawione właściwe serwery DNS u rejestratora,
- sprawdź rekordy A i AAAA dla domeny oraz CNAME dla www,
- zweryfikuj pocztę: MX, SPF, DKIM i DMARC.
Jeśli zmiana DNS była wykonana niedawno, problem może wynikać z propagacji i cache. W praktyce może to trwać od kilku minut do 24–48 godzin, rzadziej dłużej. Jeśli jednak po tym czasie nadal widzisz starą stronę, błąd NXDOMAIN, komunikaty o braku serwera, pętle przekierowań albo brak poczty, to najpewniej konfiguracja DNS jest niepełna albo błędna.
Ważne bezpieczeństwo: nie usuwaj pochopnie rekordów pocztowych i nie zmieniaj kilku rzeczy naraz, jeśli na domenie działa strona firmowa i skrzynki e-mail. Jedna zła zmiana może odciąć pocztę albo spowodować, że witryna zniknie z sieci także dla części użytkowników.
Diagnoza problemu
Najpierw trzeba ustalić, co dokładnie jest zepsute. Sam komunikat „błąd DNS” bywa mylący, bo obejmuje kilka różnych sytuacji. Inaczej wygląda problem, gdy:
- strona nie otwiera się w ogóle i przeglądarka pokazuje błąd typu DNS_PROBE_FINISHED_NXDOMAIN,
- otwiera się stara wersja strony,
- otwiera się nowa strona tylko u części osób,
- poczta nie działa po przenosinach,
- po wpisaniu domeny działa tylko wersja bez www albo tylko z www,
- strona ładuje się, ale pojawia się ostrzeżenie o certyfikacie SSL.
Każdy z tych objawów wskazuje trochę inny poziom problemu. DNS to warstwa, która tłumaczy nazwę domeny na adres IP lub inną usługę. Jeśli ten „tłumacz” ma błędne dane, użytkownik trafia nie tam, gdzie trzeba. Dlatego po migracji hostingu diagnoza powinna przebiegać od góry do dołu:
- czy domena wskazuje na właściwe serwery nazw,
- czy strefa DNS zawiera poprawne rekordy,
- czy nowy serwer odpowiada pod właściwym IP,
- czy SSL i przekierowania nie dokładają własnego problemu,
- czy poczta ma kompletną konfigurację.
Dobrym punktem startowym jest porównanie stanu przed migracją i po migracji. Jeżeli wcześniej domena działała bez www, a po przenosinach przekierowanie ustawia się na starą lokalizację, problem często nie leży w samej stronie, tylko w konfiguracji strefy DNS lub regułach przekierowań na nowym hostingu.
Możliwe przyczyny
Po migracji hostingu błędy DNS zwykle mają jedną z poniższych przyczyn. Warto przejść przez nie po kolei, bo często występują łącznie.
1. Propagacja DNS jeszcze się nie zakończyła
To najczęstszy scenariusz. Zmiana serwerów nazw, rekordów A czy CNAME nie jest widoczna natychmiast wszędzie. Część resolverów zapamiętuje stare odpowiedzi zgodnie z TTL. W praktyce jeden użytkownik widzi nową stronę, drugi jeszcze starą, a trzeci wcale jej nie widzi. To normalne przez pewien czas, ale tylko wtedy, gdy konfiguracja docelowa jest poprawna.
2. Domenę wskazano na niewłaściwe serwery nazw
Jeśli po migracji hosting się zmienił, ale serwery nazw nadal prowadzą do starego panelu DNS, rekordy w nowym hostingu nie będą miały znaczenia. Domena „słucha” tych serwerów nazw, które są ustawione u rejestratora. To częsty błąd po przenosinach, gdy ktoś aktualizuje rekordy w nowym panelu, a domena nadal korzysta z DNS starego dostawcy.
3. Rekord A wskazuje na stary adres IP
Rekord A mapuje domenę na konkretny adres IPv4. Po migracji hosting zmienia IP i rekord trzeba zaktualizować. Jeśli nie, domena dalej prowadzi do poprzedniego serwera. To samo dotyczy rekordu AAAA dla IPv6, który bywa pomijany. Jeśli rekord AAAA wskazuje stary serwer, część przeglądarek i sieci może próbować użyć właśnie tej ścieżki, powodując pozornie losowe błędy.
4. Rekord CNAME dla www jest błędny lub nie istnieje
Często domena główna działa, ale www już nie. Powód? www może mieć CNAME do domeny głównej, ale po migracji ktoś zmienił tylko jedną stronę konfiguracji. Zdarza się też odwrotnie: rekord www wskazuje na stary host, a domena bez www już na nowy.
5. Poczta została przeniesiona bez poprawnych rekordów MX
Migracja hostingu nie zawsze oznacza tylko stronę. Jeśli na tej samej domenie działa skrzynka e-mail, trzeba sprawdzić rekordy MX. Ich brak, niezgodność albo wskazanie na stary serwer powodują, że wiadomości nie dochodzą. Dodatkowo bez SPF, DKIM i DMARC wiadomości mogą trafiać do spamu lub być odrzucane.
6. Zbyt agresywny cache na komputerze, routerze albo u dostawcy internetu
Nawet przy poprawnej konfiguracji możesz widzieć stary stan przez pamięć podręczną systemu operacyjnego, przeglądarki, routera, lokalnego DNS operatora albo firmowej sieci. To szczególnie częste w biurach, gdzie wiele urządzeń korzysta z jednego resolvera.
7. Błędne przekierowania i mieszanie problemów DNS z SSL
Po migracji strona może być poprawnie wskazywana przez DNS, ale nadal nie działać przez pętlę przekierowań, wymuszenie https bez certyfikatu albo konflikt między ustawieniami domeny w panelu hostingu i aplikacją CMS. Użytkownik widzi wtedy „problem z domeną”, choć źródło leży niżej albo wyżej niż sam DNS.
8. Niepełne przeniesienie strefy DNS
Wielu administratorów kopiuje tylko rekord A i MX, a pomija TXT, SRV, CAA, DNSSEC lub rekordy potrzebne do usług zewnętrznych. Po migracji przestają działać nie tylko strona i poczta, ale też weryfikacje Google, formularze, integracje marketingowe, subdomeny czy certyfikaty SSL.
9. DNSSEC skonfigurowany niezgodnie z nową strefą
DNSSEC potrafi skutecznie blokować domenę, jeśli podpisy albo rekordy DS nie pasują do nowej konfiguracji. To problem bardziej zaawansowany, ale po migracji hostingu występuje częściej, niż się wydaje. Objawem bywa sytuacja, w której domena „jest poprawna”, ale walidacja DNS kończy się błędem.
Rozwiązanie krok po kroku
Poniższa procedura zakłada, że chcesz wrócić do działania strony bez zgadywania. Wykonuj kolejne kroki po kolei i nie zmieniaj wszystkiego naraz. Jeśli prowadzisz sklep, serwis z ruchem lub pocztę firmową, każdą zmianę zapisuj.
Krok 1. Ustal, co dokładnie nie działa
Sprawdź osobno:
- domenę główną bez www,
- wersję z www,
- subdomeny, jeśli istnieją,
- pocztę przychodzącą i wychodzącą,
- działanie strony z różnych sieci: LTE, Wi-Fi domowe, ewentualnie firmowe.
Jeśli problem dotyczy tylko jednej sieci, winny może być lokalny cache. Jeśli problem dotyczy wszystkich, trzeba analizować konfigurację DNS lub serwer.
Krok 2. Sprawdź, gdzie zarządzana jest strefa DNS
Ustal, czy DNS obsługuje rejestrator domeny, stary hosting czy nowy hosting. Najważniejsze pytanie brzmi: który serwer nazw jest aktywny? W panelu rejestratora powinno być widać aktualne NS. Jeśli domena wskazuje na stare DNS, to właśnie tam należy poprawiać rekordy albo zmienić delegację na nowe serwery.
Krok 3. Porównaj rekordy z docelową konfiguracją
Zweryfikuj, czy w strefie DNS znajdują się poprawne wpisy:
- A dla domeny głównej,
- AAAA, jeśli korzystasz z IPv6,
- CNAME dla www,
- MX dla poczty,
- TXT dla SPF, weryfikacji i DMARC,
- DKIM, jeśli dostawca poczty tego wymaga,
- CAA, jeśli używasz dodatkowych ograniczeń certyfikatów,
- rekordy dla subdomen i aplikacji zewnętrznych.
Jeśli migracja dotyczyła tylko strony, a nie poczty, nie usuwaj pochopnie rekordów MX i TXT. Są one często zależne od usług, które nadal mają działać.
Krok 4. Sprawdź adres IP nowego hostingu
Upewnij się, że rekord A wskazuje dokładnie na nowy adres IP. Czasami hosting podaje kilka adresów lub osobny IP dla www i dla strony głównej. Błędne przepisanie jednej cyfry wystarczy, by domena kierowała do nieistniejącego miejsca. W przypadku AAAA sprawdź także, czy IPv6 jest aktywny po stronie hostingu. Jeśli nie masz pewności, czasowo usuń rekord AAAA tylko wtedy, gdy wiesz, że nowy serwer nie obsługuje IPv6 lub jest ono błędnie skonfigurowane. To ważne, bo źle ustawiony AAAA potrafi powodować problemy mimo poprawnego rekordu A.
Krok 5. Zweryfikuj www i domenę główną
Ustal jedną wersję kanoniczną: z www albo bez www. Potem ustaw spójne przekierowanie 301. Jeśli domena główna pokazuje nową stronę, a www nie działa, dodaj poprawny rekord CNAME albo A zgodnie z wymaganiami hostingu. Jeśli problem dotyczy tylko jednej wersji, nie szukaj go od razu w aplikacji CMS.
Krok 6. Sprawdź pocztę oddzielnie od strony
To bardzo ważne. Migracja hostingu strony nie może zniszczyć poczty. Weryfikacja obejmuje:
- rekordy MX i ich priorytety,
- rekord SPF,
- rekord DKIM,
- rekord DMARC,
- czy skrzynki są tworzone w nowym panelu, jeśli poczta też zmieniła serwer,
- czy aplikacje, formularze i systemy automatyczne korzystające z SMTP mają aktualne dane logowania.
Jeżeli poczta przestała działać po migracji, nie zakładaj, że „samo przejdzie”. Wiadomości mogą ginąć albo być odrzucane przez serwery odbiorców jeszcze długo po naprawie strony.
Krok 7. Wyczyść cache lokalny i sprawdź propagację
Po poprawieniu DNS wyczyść pamięć podręczną przeglądarki, sprawdź domenę w trybie incognito i przetestuj z kilku sieci. Jeśli to możliwe, odśwież cache DNS systemu. W firmie warto sprawdzić, czy problem nie dotyczy tylko jednego routera lub jednego resolvera. Jeśli po zmianie konfiguracji część osób nadal widzi starą stronę, to najpewniej wciąż trwa propagacja albo lokalny cache pamięta dawną odpowiedź.
Krok 8. Zweryfikuj SSL i przekierowania
Gdy DNS już wskazuje dobrze, sprawdź certyfikat SSL oraz reguły przekierowań. Częsty scenariusz: domena po migracji trafia na właściwy serwer, ale serwer nie ma jeszcze aktywnego certyfikatu, przez co przeglądarka pokazuje ostrzeżenie. Inny przypadek to pętla przekierowań, gdzie CMS, panel hostingu i reguły .htaccess wzajemnie się nadpisują. Wtedy DNS jest tylko początkiem problemu, a nie jego końcem.
Krok 9. Poczekaj na pełną propagację, ale kontroluj sytuację
Jeśli wszystkie ustawienia są poprawne, a tylko część użytkowników nadal widzi stary stan, pozostaje czas i propagacja. TTL mówi resolverom, jak długo mogą trzymać starą odpowiedź. Nie warto wtedy co chwilę zmieniać rekordów, bo każda kolejna zmiana wydłuża chaos diagnostyczny. Lepiej mieć jedną stabilną konfigurację i monitorować sytuację.
Krok 10. Zrób zapis finalnej konfiguracji
Po naprawie zapisz docelowe wartości: serwery nazw, rekordy A/AAAA/CNAME/MX/TXT oraz ustawienia przekierowań. Przy kolejnej migracji lub awarii zaoszczędzi to godzin szukania problemu. To prosta, ale bardzo skuteczna praktyka administracyjna.
Ostrzeżenie bezpieczeństwa: jeśli na domenie działają formularze kontaktowe, sklep, panele klienta lub integracje z API, nie wyłączaj na ślepo wszystkich rekordów TXT i CNAME. Możesz przypadkiem zatrzymać weryfikację usług, logowanie, wysyłkę wiadomości lub płatności.
Najczęstsze błędy
Przy naprawie błędu DNS po migracji hostingu powtarzają się niemal zawsze te same pomyłki:
- edytowanie rekordów w niewłaściwym panelu – zmiany są robione w nowym hostingu, ale domena korzysta ze starych serwerów DNS,
- pomijanie rekordu AAAA – IPv4 jest poprawny, ale IPv6 nadal wskazuje stare miejsce,
- usuwanie rekordów pocztowych – strona wraca do życia, a poczta przestaje działać,
- zbyt szybkie wnioski po kilku minutach – propagacja jeszcze trwa, ale ktoś już wykonuje kolejne zmiany,
- brak kopii konfiguracji – trudno odtworzyć poprawny stan,
- mieszanie problemów DNS z problemami aplikacji – wina leży w CMS, certyfikacie albo przekierowaniach, a naprawia się DNS,
- niezgodność wersji www i bez www – jedna wersja działa, druga nie,
- ignorowanie DNSSEC – wszystko wygląda dobrze, ale walidacja blokuje domenę,
- zmiana kilku parametrów naraz – po godzinie nie wiadomo już, co faktycznie pomogło albo zaszkodziło.
W praktyce największy błąd to pośpiech. DNS wymaga cierpliwości, ale też metody. Jeśli działasz bez planu, łatwo doprowadzić do sytuacji, w której nowa strona działa tylko częściowo, a poczta przestaje dochodzić przez pół dnia lub dłużej.
Kiedy nie robić tego samodzielnie
Są sytuacje, w których samodzielna naprawa jest ryzykowna. Nie warto działać na własną rękę, jeśli:
- na domenie działa sklep internetowy i każda godzina przestoju oznacza straty,
- poczta firmowa jest krytyczna dla obsługi klientów i zamówień,
- na serwerze są liczne subdomeny, integracje i rekordy dla zewnętrznych usług,
- korzystasz z DNSSEC i nie masz pewności, jak wygląda łańcuch podpisów,
- migracja obejmowała jednocześnie hosting, pocztę i certyfikaty,
- po zmianach pojawiają się błędy losowo u różnych użytkowników,
- nie masz pewności, który panel jest źródłem prawdy dla strefy DNS,
- obawiasz się utraty dostępu do panelu domeny lub poczty administracyjnej.
W takich przypadkach jedna zła edycja może kosztować więcej niż pomoc specjalisty. Szczególnie niebezpieczne jest samodzielne wyłączanie rekordów MX lub zmiana serwerów nazw bez pełnego zrozumienia, kto obsługuje pocztę, a kto stronę.
Kiedy zgłosić się do specjalisty
Warto skorzystać z pomocy fachowca, jeśli problem trwa dłużej niż 24–48 godzin mimo poprawnych ustawień, jeśli domena wraca do starego IP tylko u części użytkowników albo jeśli na stronie i poczcie zaczynają się nakładać kolejne awarie. Specjalista przyda się również wtedy, gdy:
- masz podejrzenie błędnego DNSSEC,
- potrzebujesz bezpiecznej migracji bez przestoju,
- na domenie działa środowisko produkcyjne, którego nie można zatrzymać,
- nie masz pewności co do stanu rekordów i zależności między usługami,
- po migracji przestały działać formularze, certyfikaty lub zewnętrzne integracje,
- pojawiły się błędy tylko w określonych krajach, sieciach lub u części klientów.
Profesjonalna pomoc jest szczególnie wskazana wtedy, gdy problem dotyka nie tylko strony, lecz także poczty, subdomen i uwierzytelniania domeny. Im więcej usług zależy od DNS, tym łatwiej o efekt domina.
Podsumowanie
Błąd DNS po migracji hostingu nie musi oznaczać awarii całej infrastruktury. Najczęściej jest skutkiem niedopilnowanej delegacji domeny, błędnego rekordu A lub AAAA, niepełnej strefy DNS, opóźnienia propagacji albo pozostawienia poczty bez właściwych rekordów MX i TXT. Dobra diagnoza polega na rozdzieleniu kilku warstw: domeny, DNS, serwera, SSL i poczty. Dopiero wtedy widać, co naprawdę wymaga naprawy.
Jeśli działasz ostrożnie, masz kopię konfiguracji i sprawdzasz zmiany pojedynczo, większość problemów da się odtworzyć i usunąć bez dużego przestoju. Jeśli jednak domena obsługuje ważny biznes, sklep lub pocztę firmową, nie warto ryzykować metodą prób i błędów. DNS to nie miejsce na przypadkowe klikanie.
CTA do kontaktu
Jeżeli po migracji hostingu nadal widzisz błąd DNS, strona nie otwiera się poprawnie albo poczta przestała działać, warto zlecić diagnostykę osobie, która szybko odróżni propagację od realnej błędnej konfiguracji. Skontaktuj się ze specjalistą R99.PL, jeśli chcesz przywrócić działanie domeny, strony i poczty bez dalszego ryzyka przestoju.
