19 lis 2025·7 min
Lista kontrolna rozwiązywania problemów z domeną niestandardową — DNS i SSL
Użyj tej listy kontrolnej, aby diagnozować problemy z rekordami DNS, opóźnienia propagacji i czas wystawiania SSL — z prostymi krokami weryfikacji.
Użyj tej listy kontrolnej, aby diagnozować problemy z rekordami DNS, opóźnienia propagacji i czas wystawiania SSL — z prostymi krokami weryfikacji.
„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:
W większości przypadków problem jest jeden z następujących:
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.
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.
Oto do czego służą główne typy rekordów:
www)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.
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:
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.
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ść:
Potwierdź też, że edytujesz właściwą strefę DNS. Łatwo zaktualizować złą domenę, złe środowisko lub konto u innego dostawcy.
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:
www lub domeny głównejWiele 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.
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:
ns1... i ns2..., te dokładne wartości muszą pojawić się u rejestratora.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.
„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:
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.
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:
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”:
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.
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.
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.
Otwórz zarówno http://, jak i https:// dla apex i www. Chcesz jednego klarownego „domu” i jednego czystego przekierowania.
www) i przekieruj drugą na nią.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ś.
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.
Małe, spokojne zmiany biją ciągłe majstrowanie.
www działa, a domena główna nieUruchamiasz 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:
example.com nie ma rekordu (lub wskazuje gdzie indziej)? Napraw rekord apex.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.
Gdy konfiguracja domeny zawodzi, większość poprawek wynika z kilku szybkich kontroli. Przeprowadź je zanim zrobisz cokolwiek innego.
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ę.
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.
Trzymaj to w dokumentach projektu i wypełnij przed dotknięciem DNS:
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ę.
Jeśli potwierdziłeś, że DNS jest poprawny i nadal widzisz błędy, przestań zgadywać i eskaluj z dowodami:
Gdy eskalujesz, dołącz nazwę hosta, oczekiwane rekordy, aktualne wyniki resolvera i znaczniki czasu. To zamienia długie wymiany w szybkie naprawy.
Zwykle oznacza to, że coś na jednym z poziomów się nie zgadza: DNS nie rozwiązuje nazwy, DNS wskazuje na niewłaściwy cel, serwer/hosting nie rozpoznaje Twojej nazwy hosta lub proces wydawania certyfikatu HTTPS/SSL jeszcze się nie zakończył. Zacznij od spisania dokładnego komunikatu błędu oraz dokładnej nazwy hosta, którą wpisałeś (apex vs www).
example.com (apex) i www.example.com to osobne nazwy hostów z oddzielnymi rekordami DNS. Często www jest poprawnie ustawione jako CNAME, podczas gdy apex nie ma rekordu A, ma błędny rekord A lub konfiguracja u dostawcy DNS nie pozwala na CNAME na poziomie apex.
Sprawdź nameservery domeny w panelu rejestratora i porównaj je z dostawcą DNS, w którym edytujesz rekordy. Tylko dostawca wskazany przez aktywne nameservery jest autorytatywny — zmiany w innym panelu niczego nie zmienią publicznie.
Użyj rekordu A, gdy hosting podaje adres IPv4; AAAA tylko jeśli host podał adres IPv6; CNAME, gdy host podaje nazwę docelową (częste dla www). Rekordy TXT służą do weryfikacji i wyzwań i muszą być utworzone dokładnie na nazwie wskazanej przez hosta.
Stary lub błędny rekord AAAA może wysyłać część użytkowników po IPv6 na stary serwer, podczas gdy inni trafiają poprawnie po IPv4, co powoduje efekt „u mnie działa”. Jeśli hosting nie podał docelowego IPv6, usunięcie niepoprawnego AAAA często rozwiązuje problem.
Zwykle oznacza to, że na hostingu skonfigurowano tylko jedną nazwę hosta (tylko apex lub tylko www) lub istnieją sprzeczne reguły przekierowań, które powodują odbijanie między HTTP a HTTPS albo między apex a www. Wybierz jedną kanoniczną nazwę i zapewnij tylko jedną czystą ścieżkę przekierowania.
Tak. Wydawanie certyfikatu zwykle nie zakończy się, dopóki domena nie będzie spójnie rozwiązywać się do oczekiwanego celu z wielu miejsc. Po upewnieniu się, że DNS jest poprawny z różnych lokalizacji, cierpliwe oczekiwanie jest często właściwym krokiem — ciągłe zmiany DNS będą tylko resetować proces.
TTL (time to live) mówi resolverom, jak długo mogą pamiętać odpowiedź. Nawet po naprawie rekordu niektóre sieci mogą serwować starą wartość do wygaśnięcia TTL. Testuj z dwóch sieci (np. Wi‑Fi i dane mobilne) i unikaj dokonywania nowych zmian DNS co kilka minut, żeby móc obserwować propagację.
Użyj powtarzalnych narzędzi, takich jak dig lub nslookup, aby potwierdzić, że odpowiedzi A/AAAA/CNAME/TXT zgadzają się z oczekiwanym celem, a następnie sprawdź zarówno http://, jak i https:// dla apex i www. Jeśli jedna sieć pokazuje inne odpowiedzi DNS niż inna, to zwykle kwestia cache; jeśli wszystkie sieci pokazują nieprawidłowe odpowiedzi, to błąd konfiguracji.
Na Koder.ai traktuj ekran konfiguracji domeny aplikacji jako źródło prawdy dla oczekiwanego celu DNS, a następnie dopasuj rekordy dokładnie u dostawcy autorytatywnego. Po zmianie DNS daj czas na stabilizację przed ponowną weryfikacją SSL i używaj snapshotów/rollback, jeśli zmieniasz routing na żywo, żeby szybko wrócić do poprzedniego stanu.