Lista kontrolna rozwiązywania problemów z domeną niestandardową — DNS i SSL

Co zwykle oznacza „domena niestandardowa nie działa”

„Domena niestandardowa nie działa” to ogólny komunikat dotyczący kilku różnych awarii. Przeglądarka pokazuje objaw, nie przyczynę. Zanim cokolwiek zmienisz, nazwij dokładnie to, co widzisz.

Typowe symptomy to:

• Strona „domena nie znaleziona”
• Domena ładuje niewłaściwą stronę
• Ostrzeżenie o „niezabezpieczonym połączeniu”, mimo że HTTPS jest włączone
• Pętle przekierowań (odbijanie między http a https lub między root a www)

W większości przypadków problem jest jeden z następujących:

• DNS wskazuje w złe miejsce lub brak wymaganych rekordów
• Cel hostingu nie jest skonfigurowany dla tej nazwy hosta (serwer nie rozpoznaje domeny)
• SSL nie został jeszcze wydany, został wydany dla innej nazwy hosta lub nie może być wydany, bo DNS się nie zgadza
• Pamięć podręczna ukrywa zmiany (cache przeglądarki, resolvera DNS lub stare wartości TTL)

Zanim zaczniesz rozwiązywać problemy, upewnij się, że masz dostęp do dwóch miejsc: tam, gdzie edytujesz rekordy DNS (rejestrator lub dostawca DNS) oraz tam, gdzie podłączasz domenę po stronie hostingu. Na przykład, jeśli podłączasz wdrożoną aplikację na Koder.ai do domeny niestandardowej, potrzebujesz dostępu do DNS domeny i ustawień domeny w panelu hostingu aplikacji.

Niektóre poprawki są natychmiastowe (np. poprawa literówki). Inne wymagają czasu. Zmiany DNS mogą chwilę trwać, a SSL zwykle nie zostanie wystawiony, dopóki DNS nie będzie wskazywać poprawnie i domena będzie dostępna. Celem jest przestać zgadywać i potwierdzić każdą warstwę po kolei.

Małe koncepcje DNS, które mają znaczenie (bez żargonu)

Większość problemów z domenami sprowadza się do niezgodności między (1) nazwą hosta, którą testujesz, (2) miejscem, gdzie zarządzasz DNS, a (3) tym, na co rekord faktycznie wskazuje. Gdy te trzy elementy się zgadzają, SSL zwykle jest ostatnim krokiem.

Domeny mają dwie powszechne formy: domenę główną (root, apex) — example.com — i subdomeny (www.example.com, app.example.com). Są powiązane, ale mogą mieć różne rekordy DNS. Dlatego normalne jest, że www działa, a apex nie, lub odwrotnie.

Nameservery decydują, kto zarządza strefą DNS. Jeśli kupiłeś domenę u jednej firmy, ale nameservery wskazują na inną, musisz edytować DNS tam, gdzie wskazują nameservery. Wiele sytuacji typu „zaktualizowałem, ale nic się nie zmieniło” wynika z edycji rekordów w złym panelu.

Typy rekordów DNS prostym językiem

Oto do czego służą główne typy rekordów:

• A: wskazuje nazwę na adres IPv4 (np. 203.0.113.10)
• AAAA: wskazuje nazwę na adres IPv6
• CNAME: wskazuje nazwę na inną nazwę hosta (częste dla www)
• TXT: przechowuje tekst używany do weryfikacji i bezpieczeństwa (sprawdzanie własności, SPF i podobne)

TTL to „jak długo cachować tę odpowiedź”. Niższy TTL oznacza szybsze odświeżanie cache. Wyższy TTL oznacza, że możesz dłużej czekać, nawet po naprawieniu rekordu. Widzenie starej wartości przez jakiś czas może być normalne.

Krok po kroku: proste drzewko decyzyjne do izolowania przyczyny

Gdy domena niestandardowa zawodzi, zwykle można to zaklasyfikować do jednej z czterech grup: DNS nie rozwiązuje się, DNS wskazuje w złe miejsce, SSL nie jest gotowy albo problem dotyczy tylko niektórych użytkowników z powodu cache.

Użyj tego drzewka decyzyjnego:

1. Czy domena w ogóle się rozwiązuje? Jeśli widzisz NXDOMAIN (lub „domain not found”), rekord jest brakujący, edytujesz złą strefę DNS lub nameservery nie są takie, jak myślisz.
2. Jeśli się rozwiązuje, czy wskazuje na właściwy cel? Jeśli strona się ładuje, ale to niewłaściwy serwis, strona parkingowa lub stary serwer, target A/AAAA/CNAME jest zły lub stary rekord ma priorytet.
3. Jeśli wskazuje poprawnie, czy problem dotyczy tylko HTTPS? Jeśli HTTP działa, ale HTTPS pokazuje ostrzeżenie o certyfikacie, SSL może się jeszcze wystawiać, nazwa hosta na certyfikacie może nie pasować lub platforma czeka aż DNS się ustabilizuje.
4. Czy działa na jednym urządzeniu lub sieci, a nie działa na innej? Traktuj to jako problem z cache lub propagacją.
5. Czy przekierowania się łamią (www vs apex)? Jeśli www działa, a domena główna nie (lub odwrotnie), prawdopodobnie skonfigurowałeś tylko jedną nazwę hosta lub masz sprzeczne reguły przekierowań.

Przyspiesz pracę, zapisując dokładną nazwę hosta, która zawodzi (apex vs www) oraz dokładny komunikat błędu. Na platformach hostingowych, które automatyzują domeny i certyfikaty, różnica między „nie można znaleźć hosta” a „certyfikat oczekuje” mówi ci, czy najpierw naprawić rekordy DNS, czy po prostu poczekać na SSL po tym, jak DNS stanie się widoczny.

Krok 1: potwierdź nazwę hosta i oczekiwany cel

Wiele problemów zaczyna się od prostego niezgodnego ustawienia: skonfigurowałeś DNS dla jednej nazwy hosta, a testujesz inną.

Najpierw zapisz dokładną nazwę hosta, którą chcesz mieć aktywną. Domena główna wygląda jak example.com. Subdomena to www.example.com lub app.example.com. To są oddzielne wpisy DNS, więc „www działa” nie oznacza, że apex też działa.

Następnie znajdź oczekiwany cel w panelu hostingu. Niektóre platformy podają adres IP (dla rekordów A lub AAAA). Inne podają nazwę docelową (dla CNAME). Jeśli host podaje wartość w ekranie konfiguracji domeny, traktuj ją jako źródło prawdy.

Zanim cokolwiek zmienisz, zapisz co jest aktualnie ustawione. Uprość:

• Skopiuj obecne rekordy DNS dla nazwy, którą zmieniasz
• Zanotuj istniejące rekordy A, AAAA, CNAME i TXT
• Zapisz TTL

Potwierdź też, że edytujesz właściwą strefę DNS. Łatwo zaktualizować złą domenę, złe środowisko lub konto u innego dostawcy.

Krok 2: wybierz właściwy typ rekordu DNS (A, AAAA, CNAME, TXT)

Wiele problemów to po prostu zły typ rekordu dla nazwy, którą chcesz podłączyć. Zacznij od rozróżnienia dwóch przypadków: domena główna (apex, example.com) i subdomena (www.example.com). U niektórych dostawców zachowują się inaczej.

Rekord A wskazuje nazwę na adres IPv4. Wiele konfiguracji używa rekordu A dla domeny głównej, ponieważ niektórzy dostawcy nie pozwalają na CNAME na apex. Jeśli host daje IP, rekord A zwykle jest poprawny.

AAAA to wersja IPv6. Błędny rekord AAAA wskazujący na stary cel może tworzyć mylące zachowanie „u mnie działa”, ponieważ część odwiedzających trafi po IPv6, a inni po IPv4. Jeśli host nie podał docelowego IPv6, usunięcie nieprawidłowego AAAA często naprawia niespójne błędy.

CNAME wskazuje subdomenę na inną nazwę hosta (często stosowane dla www). Jest użyteczny, gdy host chce, by cel wskazywał na nazwany endpoint, który może się zmieniać za kulisami.

TXT to miejsce na weryfikację i wyzwania (w tym niektóre sprawdzenia SSL). Częste błędy to umieszczanie TXT na złej nazwie (root vs _acme-challenge vs subdomena), dodawanie dodatkowych spacji lub wklejenie złej wartości.

Przed przejściem dalej poszukaj konfliktów. To one powodują najwięcej problemów:

• CNAME na nazwie, która ma też inne typy rekordów
• Wiele rekordów A lub AAAA dla tej samej nazwy, gdy chciałeś tylko jednego
• Stare rekordy pozostałe dla www lub domeny głównej
• Rekordy TXT utworzone na niewłaściwej nazwie

Krok 3: zweryfikuj nameservery, aby edytować we właściwym miejscu

Wiele przypadków „domena niestandardowa nie działa” nie dotyczy wartości rekordu. Dzieje się tak, bo rekord został dodany u złego dostawcy. Jeśli domena używa nameserverów Dostawcy A, zmiana rekordów w panelu Dostawcy B nic nie da, nawet jeśli rekordy tam wyglądają poprawnie.

Potwierdź autorytatywne nameservery

Sprawdź, jakich nameserverów faktycznie używa domena. Zwykle widać to w ustawieniach domeny u rejestratora pod „Nameservers”. Dla drugiej opinii zapytaj DNS bezpośrednio ze swojego komputera:

dig NS example.com

Nameservery zwrócone przez to polecenie to serwery autorytatywne.

Szybkie sprawdzenie zdrowego rozsądku:

• Jeśli twój host DNS podaje nameservery typu ns1... i ns2..., te dokładne wartości muszą pojawić się u rejestratora.
• Jeśli niedawno zmieniłeś dostawcę DNS, potwierdź, że przełączenie jest zakończone przed dalszą edycją rekordów.
• Jeśli platforma pokazuje „sugerowane rekordy DNS”, to zwykle wskazówka. Nadal musisz dodać rekordy u autorytatywnego dostawcy DNS.

Dlaczego „zaktualizowałem, ale nic się nie zmieniło” się zdarza

Jeśli zaktualizujesz rekordy u złego dostawcy, często zobaczysz dwa panele, które się nie zgadzają. Tylko autorytatywne nameservery mają znaczenie.

Uważaj też na opóźnienia po zmianie nameserverów u rejestratora. W oknie przejścia wyniki mogą wyglądać niespójnie w zależności od miejsca, z którego testujesz. Jeśli nameservery wciąż się zmieniają, wstrzymaj dalsze zmiany rekordów, aż zestaw nameserverów będzie stabilny.

Krok 4: sprawdzenia propagacji i cache, które naprawdę pomagają

„Propagacja” nie jest jednym przełącznikiem. To łańcuch cache DNS (ISP, operator sieci komórkowej, publiczne resolvery i twoje urządzenia), które aktualizują się w różnym tempie. Dlatego domena może działać u współpracownika, a u ciebie nie.

TTL (time to live) mówi, jak długo cache mogą trzymać odpowiedź. Jeśli stary TTL wynosił 1 godzinę, niektórzy będą widzieć starą wartość przez prawie godzinę. Obniżenie TTL pomaga tylko wtedy, gdy zrobisz to przed zmianą.

Aby oddzielić opóźnienia propagacji od rzeczywistych błędów, wykonaj kilka szybkich testów:

• Przetestuj na domowym lub firmowym Wi‑Fi, a potem na danych mobilnych
• Poproś kogoś w innej sieci o sprawdzenie
• Użyj trybu prywatnego w przeglądarce (żeby wykluczyć cache przekierowań)
• Uruchom ponownie urządzenie lub opróżnij lokalny cache DNS, jeśli wiesz jak
• Sprawdź dokładną nazwę hosta (apex vs www)

Jeśli gdziekolwiek sprawdzisz i rekord jest zły (zły IP, brak www, stary CNAME), napraw to. Jeśli rekordy wyglądają poprawnie w większości miejsc, ale jedna sieć nadal pokazuje starą wartość, to zwykle opóźnienie cache.

Krok 5: czas wystawiania SSL i dlaczego „poczekaj chwilę” czasem jest właściwe

Certyfikaty SSL zwykle nie powiodą się z jednej podstawowej przyczyny: wystawca certyfikatu nie może zweryfikować domeny, dopóki DNS nie wskazuje konsekwentnie na właściwe miejsce.

Normalna sekwencja jest prosta:

1. Ustaw poprawne rekordy DNS.
2. Poczekaj, aż będą rozwiązywać się poprawnie z różnych miejsc.
3. Ukończ wymaganą weryfikację (często rekord TXT).
4. Poczekaj na zakończenie wydawania certyfikatu.

Typowe blokery są łatwe do przeoczenia. Zły rekord A lub CNAME wysyła sprawdzenia walidacyjne na niewłaściwy serwer. Przestarzały rekord AAAA może nadpisać działający rekord A dla części odwiedzających, więc HTTPS zawodzi tylko dla niektórych. Brak wymaganej wartości TXT może uniemożliwić platformie wydanie certyfikatu.

Użyj objawów, żeby odróżnić „ciągle wydawany” od „źle skonfigurowany”:

• Ciągle wydawany: HTTP może działać, ale HTTPS pokazuje tymczasowy certyfikat domyślny lub komunikat „not valid yet”.
• Źle skonfigurowany: widzisz inną stronę, stronę parkingową ISP albo zapytanie DNS kończy się NXDOMAIN.

Podczas oczekiwania nie zmieniaj nieustannie rekordów. Każda zmiana resetuje zegar i może stworzyć rozbieżny stan, w którym różne sieci widzą różne odpowiedzi. Ustaw poprawne rekordy raz, potem ponawiaj sprawdzenia rozwiązywania i weryfikacji, aż certyfikat zostanie wydany.

Jeśli używasz platformy takiej jak Koder.ai, najbezpieczniejszy przebieg jest taki sam: potwierdź, że DNS wskazuje oczekiwany cel, usuń błędne rekordy AAAA, jeśli istnieją, i daj SSL czas po ustabilizowaniu DNS.

Jak zweryfikować każdy krok (bez zgadywania)

Dobre rozwiązywanie problemów to w większości porównanie: co widzisz vs czego oczekujesz. Nie polegaj na „ładuje mi się na telefonie”. Używaj powtarzalnych kontroli.

Sprawdź odpowiedzi DNS względem oczekiwanego celu

Użyj narzędzia do zapytań DNS (jak nslookup lub dig) i potwierdź, że zwrócona wartość zgadza się z tym, co zamierzałeś (IP dla A/AAAA, nazwa hosta dla CNAME, token dla TXT).

# Apex (root) domain
dig example.com A

dig example.com AAAA

# www subdomain
dig www.example.com CNAME

# TXT (często używane do weryfikacji)
dig example.com TXT

Sprawdź obie nazwy, których możesz używać: apex (example.com) i www (www.example.com). Częste jest, że jedna jest poprawna, a druga wciąż wskazuje stare miejsce.

Sprawdź zachowanie przeglądarki (HTTP, HTTPS i przekierowania)

Otwórz zarówno http://, jak i https:// dla apex i www. Chcesz jednego klarownego „domu” i jednego czystego przekierowania.

• Wybierz jedną kanoniczną domenę (apex lub www) i przekieruj drugą na nią.
• Unikaj „ping‑ponga” przekierowań (A przekierowuje do B, potem B przekierowuje z powrotem do A).
• Jeśli HTTP działa, a HTTPS zawodzi, SSL albo wciąż się wystawia, albo DNS wskazuje gdzie indziej.

Jeśli wyniki różnią się w zależności od sieci, prawdopodobnie widzisz cache lub propagację. Prowadź krótką notatkę: co zmieniłeś, gdzie to zrobiłeś, czas i co zaobserwowałeś.

Typowe błędy, które kosztują godziny

Większość problemów z DNS i SSL nie jest tajemnicą. To drobne błędy, które zmuszają do sprawdzania złej rzeczy lub ciągłego zmieniania ustawień, zanim będzie można wyciągnąć wnioski.

Najczęstszy pożeracz czasu to edycja DNS w dwóch miejscach. Często dzieje się to po zmianie nameserverów: aktualizujesz rekordy u rejestratora, ale DNS jest faktycznie hostowany gdzie indziej (lub odwrotnie). Wszystko wygląda poprawnie w jednym panelu, ale publicznie nic się nie zmienia.

Inny klasyczny błąd to próba ustawienia CNAME na domenie głównej u dostawcy, który tego nie obsługuje. Może być potrzebny rekord A, albo rekord typu ALIAS/ANAME, jeśli dostawca DNS to oferuje.

IPv6 także może robić kłopoty. Pozostawienie starego AAAA może wysyłać część użytkowników do złego serwera, podczas gdy inni trafiają poprawnie po IPv4.

Uważaj na rekordy „na zapas”. Wiele rekordów A może działać jak przypadkowe równoważenie obciążenia, jeśli jeden z celów jest zły, zwłaszcza przy podłączaniu domeny do hostowanej aplikacji.

Jedna ostatnia zasada: przestań resetować zegar.

• Nie zmieniaj rekordów co kilka minut.
• Nie mieszaj starych i nowych celów jednocześnie.
• Poczekaj, aż cache się uspokoi, zanim ocenisz wynik.

Małe, spokojne zmiany biją ciągłe majstrowanie.

Realistyczny przykład: www działa, a domena główna nie

Uruchamiasz nową aplikację i konfigurujesz example.com i www.example.com. Po kilku minutach www.example.com ładuje się poprawnie, ale domena główna pokazuje błąd DNS, ładuje starą stronę lub HTTPS pozostaje w stanie oczekiwania. Ten wzorzec jest powszechny i zwykle ma małą przyczynę.

Zacznij od nudnego pytania: czy edytujesz DNS we właściwym miejscu? Jeśli domena jest zarejestrowana u jednej firmy, a DNS hostowany u innej, możesz cały dzień zmieniać rekordy i nic się nie stanie. Najpierw sprawdź nameservery, potem otwórz panel DNS dostawcy, na którego wskazują.

Następnie porównaj obie nazwy hostów. www to zwykle CNAME. Domena główna jest trudniejsza: wielu dostawców nie pozwala na CNAME na apex, więc często potrzebuje rekordu A do IP lub rekordu ALIAS/ANAME, jeśli dostawca to obsługuje.

Ścieżka decyzyjna, która działa w praktyce:

• Nameservery są złe lub nieoczekiwane? Napraw to najpierw.
• Nameservery poprawne, ale example.com nie ma rekordu (lub wskazuje gdzie indziej)? Napraw rekord apex.
• Rekordy wyglądają poprawnie, ale zachowanie różni się w zależności od urządzenia lub sieci? Poczekaj na propagację i wyczyść cache.
• DNS rozwiązuje poprawnie, ale HTTPS zawodzi lub utknął? SSL czeka na stabilny DNS.

Poprawny końcowy stan jest nudny: zarówno example.com, jak i www.example.com prowadzą do tej samej aplikacji, jedna domena jest kanoniczna (druga przekierowuje) i HTTPS jest ważny.

Szybka lista kontrolna, którą możesz przeprowadzić w 5 minut

Gdy konfiguracja domeny zawodzi, większość poprawek wynika z kilku szybkich kontroli. Przeprowadź je zanim zrobisz cokolwiek innego.

• Potwierdź, że edytujesz DNS we właściwym miejscu (dopasuj panel do autorytatywnych nameserverów domeny).
• Zweryfikuj, że nazwa hosta i cel są dokładne (brak brakującej subdomeny, brak dodatkowych kropek). Porównaj typ rekordu (A, AAAA, CNAME, TXT) z tym, czego oczekuje host.
• Usuń konflikty (CNAME plus inne rekordy na tej samej nazwie, lub stare rekordy A/AAAA, których już nie potrzebujesz).
• Sprawdź z dwóch punktów widzenia (dane mobilne i Wi‑Fi). Jeśli jedna sieć działa, a druga nie, to zwykle cache lub propagacja.
• Szanuj TTL. Jeśli TTL wynosi 300 sekund, poczekaj 5–10 minut przed oceną. Jeśli TTL to 3600, spodziewaj się bliżej godziny.

Po tym, jak DNS jest ewidentnie poprawny, sprawdź SSL. Wiele platform wystawi certyfikat dopiero po tym, jak domena będzie konsekwentnie rozwiązywać się do oczekiwanego celu. Jeśli sprawdzasz za wcześnie, możesz pomylić normalne opóźnienie z prawdziwym błędem.

Jeśli dodajesz domenę niestandardową do wdrożonej aplikacji na Koder.ai, traktuj ekran konfiguracji domeny jako odniesienie dla oczekiwanego celu DNS, a następnie ponownie sprawdzaj status dopiero po tym, jak DNS miał czas na propagację.

Następne kroki: jak uczynić konfigurację domen powtarzalną przy każdym wdrożeniu

Najszybszy sposób, by nie powtarzać błędów DNS i SSL, to trzymać krótką „notatkę konfiguracji domeny” dla każdego projektu. To wielokrotnego użytku runbook, który możesz skopiować przy następnym wdrożeniu.

Prosty szablon notatki konfiguracji domeny

Trzymaj to w dokumentach projektu i wypełnij przed dotknięciem DNS:

• Domeny i nazwy hostów (root, www i subdomeny)
• Oczekiwane typy rekordów i cele (A, CNAME, TXT) i skąd pochodzą
• Gdzie edytowany jest DNS (który dostawca) i aktywne nameservery
• Oczekiwania dotyczące SSL (kto wystawia, jak wygląda „gotowe”)
• Kroki weryfikacji, które wykonasz (narzędzie i oczekiwany rezultat)

Podczas wdrożenia wyznacz jedną osobę jako właściciela DNS. DNS psuje się najczęściej, gdy dwie osoby jednocześnie „naprawiają” różne rzeczy (np. jedna zmienia nameservery, a druga edytuje rekordy).

Po stronie hostingu zaplanuj bezpieczne odwrócenia zmian. Jeśli platforma obsługuje snapshoty lub rollback, zrób snapshot przed zmianą routingu, żeby szybko wrócić do ostatniego znanego dobrego stanu. Jeśli budujesz na Koder.ai, możesz użyć Planning Mode, by zapisać kroki domeny, wykonać je po kolei i cofnąć, jeśli zmiana zepsuje produkcję.

Kiedy eskalować (i do kogo)

Jeśli potwierdziłeś, że DNS jest poprawny i nadal widzisz błędy, przestań zgadywać i eskaluj z dowodami:

• Rejestrator pokazuje zablokowane nameservery albo nie możesz ich zmienić
• Edycje DNS nie pojawiają się publicznie po oczekiwanym oknie TTL
• SSL nadal zawodzi długo po tym, jak DNS rozwiązuje poprawnie (licz godziny, nie minuty)
• Widzisz sprzeczne rekordy, których nie możesz usunąć (błąd UI dostawcy lub split DNS)

Gdy eskalujesz, dołącz nazwę hosta, oczekiwane rekordy, aktualne wyniki resolvera i znaczniki czasu. To zamienia długie wymiany w szybkie naprawy.