Konfiguracja własnej domeny dla aplikacji webowych — jasne kroki dotyczące rekordów DNS, wydawania certyfikatów SSL, przekierowań oraz planu przełączenia o niskim ryzyku, aby uniknąć przestojów i problemów z ciasteczkami.
Własna domena to więcej niż ładniejszy adres URL. W chwili, gdy przechodzisz z adresu platformy (np. aplikacji hostowanej na Koder.ai pod subdomeną platformy) na własną domenę, przeglądarki i sieci traktują to jako inną stronę. To wpływa na routing, bezpieczeństwo i zachowanie sesji użytkowników.
Po przełączeniu na własną domenę kilka rzeczy zmienia się od razu:
www czy na domenie apex, oraz musisz ustalić spójne reguły HTTP → HTTPS.old-platform.example nie zadziała automatycznie na app.yourdomain.com.Krótko trwające przestoje zwykle wynikają z czasu. DNS może zacząć wysyłać ruch do nowego hosta zanim certyfikat SSL będzie gotowy — wtedy pojawiają się ostrzeżenia przeglądarki. Albo odwrotnie: SSL jest gotowy, ale wielu użytkowników wciąż trafia na stare miejsce z powodu nieodświeżonego cache’u DNS.
Przekierowania też potrafią subtelnie zepsuć logowania. Przekierowanie zmieniające hostname (apex ↔ www) może spowodować utratę ciasteczek, jeśli były ustawione dla innego hosta. Dostawcy tożsamości mogą zawieść, jeśli ich callback URL wciąż wskazuje starą domenę.
Przełączenie o niskim ryzyku oznacza planowanie nakładającego się okresu: utrzymaj działanie starego adresu, postaw nową domenę równolegle, przesuń ruch w przewidywalnym momencie i przygotuj prosty rollback polegający na przywróceniu DNS.
Zanim cokolwiek zmienisz, zapisz dokładnie, jakie nazwy mają wpisywać użytkownicy i które nazwy mają cicho przekierowywać. Większość problemów typu „dlaczego to działa tylko częściowo?” bierze się z braku zgody w zespole co do jedynego prawdziwego hostname’u.
Zacznij od dużej decyzji: apex (example.com) czy www (www.example.com) jako główny. Oba warianty działają, ale wybierz jeden i traktuj drugi jako przekierowanie. To będzie ważne później dla ciasteczek: sesje są najprostsze, gdy aplikacja żyje na jednym spójnym hoście.
Następnie zdecyduj, jakie subdomeny są potrzebne teraz, a które mogą poczekać. Powszechny schemat to app.example.com dla aplikacji webowej i api.example.com dla API, z admin.example.com lub assets.example.com dodawanymi później. Jeśli konfigurujesz własną domenę na platformie takiej jak Koder.ai, wybory te mapują się bezpośrednio na to, co potwierdzisz dla SSL i co wskażesz w DNS.
Wiele osób kupuje domenę u rejestratora, ale DNS może być hostowany gdzie indziej. Potwierdź, gdzie dziś edytuje się rekordy, kto ma dostęp i czy zmiany są automatyzowane (IT firmy, agencja lub zarządzany dostawca DNS). Jeśli nie możesz się zalogować i zobaczyć aktualnych rekordów, zatrzymaj się i napraw to najpierw.
Przeprowadź też audyt tego, co już korzysta z domeny. Poczta to klasyczna pułapka: możesz przerwać dostarczanie, usuwając lub nadpisując rekordy.
Zanim pójdziesz dalej, zapisz te decyzje:
www) i kierunek przekierowaniaJeśli marketing już obsługuje pocztę na example.com, pozostaw rekordy pocztowe bez zmian i dodaj tylko to, czego aplikacja potrzebuje.
Większość ryzyka przy przenoszeniu domeny nie dotyczy samej aplikacji. To jeden zły zapis DNS, który wysyła ruch donikąd, psuje pocztę lub uniemożliwia walidację SSL.
A record wskazuje nazwę na adres IP. Mówiąc prościej: „wysyłaj ludzi do tego serwera”. Często używa się go dla domeny apex (example.com), gdy dostawca daje stałe IP.
CNAME record wskazuje jedną nazwę na inną nazwę. Mówiąc prościej: „traktuj tę nazwę jako alias tamtej nazwy”. Często używa się go dla www.example.com wskazującego na hostname platformy.
Wielu dostawców DNS oferuje też ALIAS/ANAME dla apex. Zachowuje się jak CNAME, ale działa dla example.com. Jeśli dostawca to wspiera, zarządzanie może być łatwiejsze, bo cel może się zmieniać bez ręcznej edycji IP.
Prosty model mentalny:
Często dodasz TXT do weryfikacji własności domeny (wymagane przez platformy) oraz dla walidacji certyfikatu SSL (niektóre CA walidują przez token w TXT). TXT służy też do polityk pocztowych, jak SPF. Przez przypadek usunięte lub nadpisane SPF TXT może zepsuć dostarczanie poczty.
TTL kontroluje, jak długo inne systemy cache’ują odpowiedź DNS. Na dzień przed przełączeniem obniż TTL rekordów, które zamierzasz zmieniać (powszechnie 300–600 sekund). Po stabilizacji podnieś go znów, aby zmniejszyć obciążenie.
Zanim edytujesz, wyeksportuj lub zrób zrzut ekranu strefy DNS. Zapisz każdy rekord, który zmienisz: jego starą wartość, nową wartość i TTL. Jeśli coś pójdzie nie tak, rollback to przywrócenie poprzednich wartości.
To ma największe znaczenie, gdy domena już ma MX, DKIM lub inne TXT dla poczty.
SSL (kłódka) szyfruje ruch między przeglądarką a aplikacją. Współczesne przeglądarki i wiele API oczekuje HTTPS domyślnie. Bez tego możesz mieć ostrzeżenia, zablokowane żądania i brak działania pewnych funkcji (service workers, geolokalizacja, płatności).
Aby wystawić certyfikat, urząd certyfikacji musi potwierdzić, że masz kontrolę nad domeną. Typowe metody walidacji to HTTP i DNS TXT:
Walidacja przez DNS jest często łatwiejsza, gdy używasz CDN lub gdy aplikacja nie jest jeszcze osiągalna na nowej domenie.
Gdzie certyfikat jest wydawany zależy od twojego układu: niektórzy wystawiają certyfikaty w stacku hostingu, inni w CDN, a platformy obsługujące custom domains (np. Koder.ai) robią to za ciebie. Ważne jest, by wiedzieć, kto zarządza życiem certyfikatu, łącznie z odnawianiem.
Wydawanie certyfikatu nie zawsze jest natychmiastowe. Propagacja DNS, sprawdzenia walidacji i limity żądań mogą spowolnić proces. Zaplanuj ponowne próby i nie ustawiaj przełączenia na ostatnią chwilę.
Praktyczny plan czasowy:
Certyfikat musi obejmować każdy hostname, na który użytkownicy będą trafiać. Sprawdź listę SAN (Subject Alternative Names). Jeśli aplikacja ma być dostępna zarówno na example.com, jak i www.example.com, certyfikat musi obejmować oba.
Wildcardy (np. *.example.com) pomagają dla wielu subdomen, ale nie obejmują domeny apex (example.com).
Konkretny przykład: jeśli wydasz certyfikat tylko dla www.example.com, użytkownicy wpisujący example.com zobaczą ostrzeżenia, chyba że przekierujesz je na warstwie, która ma ważny certyfikat dla example.com.
Przekierowania brzmią prosto, ale tutaj pojawia się większość problemów domenowych: pętle, mixed content i wylogowania użytkowników z powodu odbijania między hostami.
Wybierz jeden host kanoniczny i trzymaj się go: www.example.com albo example.com (apex). Drugi punkt wejścia powinien przekierowywać na host kanoniczny, by ciasteczka, sesje i SEO pozostały spójne.
Bezpieczne domyślne ustawienia:
http:// na https:// dla każdego żądaniaDla HTTP -> HTTPS unikaj reguł, które odbijają użytkowników w kółko. Najprostszy sposób na uniknięcie pętli to podejmowanie decyzji na podstawie faktycznego żądania. Jeśli aplikacja stoi za proxy lub CDN-em, skonfiguruj go, aby respektował przekazywane nagłówki (np. nagłówek informujący, że oryginalny schemat był HTTP). W przeciwnym razie aplikacja może myśleć, że każde żądanie jest HTTP i ciągle przekierowywać.
Podczas migracji utrzymuj stare ścieżki przy życiu. Jeśli zmieniasz trasy (np. /login -> /sign-in), dodaj explicite przekierowania dla tych ścieżek. Nie polegaj na zbiorczym przekierowaniu do strony głównej — złamie to zakładki i linki.
Wstrzymaj się z HSTS na początku. Jeśli włączysz go za wcześnie, a potem będziesz musiał serwować HTTP dla walidacji lub debugowania, przeglądarki mogą odmówić połączenia. Poczekaj, aż HTTPS będzie stabilny i potwierdź pokrycie subdomen.
Aby przetestować przekierowania bez wpływu na wszystkich, użyj tymczasowego testowego hostname’a, sprawdź kilka głębokich linków (w tym strony auth) i uruchom żądanie z linii poleceń, które pokaże każdy krok przekierowania i finalne miejsce docelowe.
Bezpieczne przełączenie to w dużej mierze kwestia czasu. Chcesz, aby nowa domena była gotowa i przetestowana zanim trafi do niej prawdziwy ruch, oraz aby zmiany DNS rozchodziły się szybko, żeby nie czekać w trakcie incydentu.
Obniż TTL rekordów, które zmienisz, z wyprzedzeniem. Zrób to dzień wcześniej, jeśli możesz, i poczekaj aż minie poprzedni okres TTL, żeby cache’y zdążyły się zaktualizować.
Dodaj najpierw domenę w hostingu/dostawcy i wykonaj wymaganą weryfikację. Jeśli używasz platformy takiej jak Koder.ai, dodaj domenę tam najpierw, aby platforma mogła potwierdzić własność i przygotować routing.
Wystaw SSL wcześniej. Certyfikaty mogą trwać kilka minut lub dłużej w zależności od metody walidacji i ograniczeń.
Zanim udostępnisz domenę publicznie, zrób prywatny test: trafić na nowy endpoint w sposób niezależny od publicznego DNS (np. wpisując tymczasowy wpis w /etc/hosts) i potwierdzić, że strona ładuje się przez HTTPS z właściwym certyfikatem.
Stosuj podejście etapowe, aby móc szybko zatrzymać się, jeśli coś pójdzie nie tak:
Jeśli nie możesz wykonać prawdziwego canary na poziomie DNS, możesz etapować przez zmianę tylko jednego hostname’u najpierw (np. www), a domenę apex zostawić, dopóki nie nabierzesz pewności.
Zapisz dokładnie, co przywrócisz (które rekordy, jakie wartości) i kto to zrobi. Rollback to z reguły przywrócenie DNS do poprzedniego stanu.
Upewnij się, że stary setup jest nadal ważny (łącznie z SSL), aby użytkownicy mogli wrócić bezproblemowo, podczas gdy naprawiasz nową ścieżkę.
Zmiana domeny to nie tylko DNS. Dla wielu aplikacji „bycie zalogowanym” zależy od ciasteczek przypisanych do konkretnego hostname’u. Jeśli zmienisz hostname, przeglądarka może przestać wysyłać stare ciasteczka i aplikacja będzie wyglądać, jakby wszystkich wylogowała.
Ustawienia ciastek to zwykle przyczyna:
app.old.com nie zostanie wysłane do app.new.com. Ciasteczko ustawione dla .example.com zadziała między app.example.com i www.example.com./api), UI może go nie widzieć.Lax często wystarcza, ale niektóre SSO lub płatności wymagają None i Secure.Aby zmniejszyć ryzyko, zaplanuj krótki okres przejściowy, w którym oba hosty działają. Trzymaj stary hostname odpowiadający i przekierowujący, ale pozwól sesjom odświeżyć się na nowej domenie. Jeśli to możliwe, użyj współdzielonego store’a sesji, żeby użytkownik trafiający na którykolwiek hostname był rozpoznawany.
Jeśli korzystasz z SSO lub OAuth, zaktualizuj ustawienia przed przełączeniem: callback URLs, dozwolone pochodzenia i allowlisty redirect URI. W przeciwnym razie logowania mogą się powieść u providera tożsamości, ale zbankrutować przy powrocie do aplikacji.
Przetestuj przepływy, które zwykle zawodzą jako pierwsze: rejestrację (i weryfikację mailową), logowanie/wylogowanie, reset hasła, powrót z płatności i sesje w wielu kartach.
Przykład: jeśli przekierowujesz www.example.com na example.com, upewnij się, że ciasteczka są ustawione dla .example.com (albo używaj konsekwentnie jednego hostname’u). W przeciwnym razie użytkownicy będą odbijani między hostami i tracili sesję.
Większość problemów domenowych to nie „tajemnicze błędy internetu”. To drobne niezgodności między DNS, certyfikatami i regułami przekierowań, które wychodzą na jaw, gdy prawdziwi użytkownicy trafiają na serwis.
Jedną prostą pułapką jest domena apex (example.com). Wielu dostawców DNS nie pozwala na prawdziwy CNAME na apex. Jeśli spróbujesz wymusić CNAME na apex, może to działać nieregularnie, zawodzić cicho lub łamać się tylko w niektórych sieciach. Używaj tego, co wspiera twój DNS (często A/AAAA lub ALIAS/ANAME).
Inną częstą przyczyną przestojów jest zmiana DNS zanim SSL będzie gotowy na nowym endpointcie. Użytkownicy przychodzą, aplikacja ładuje się, a potem przeglądarka blokuje połączenie, bo certyfikat brak lub nie obejmuje wszystkich hostname’ów. W praktyce warto, żeby certyfikat obejmował oba: example.com i www.example.com, nawet jeśli planujesz przekierować jeden na drugi.
Typowe błędy tworzące przestoje lub dziwne zachowanie:
http:// zasobów, co wywołuje ostrzeżenia przeglądarkiSzybkie sprawdzenie: otwórz oba hosty (www i apex) przez HTTPS, zaloguj się, odśwież i potwierdź, że pasek adresu nigdy nie wraca do HTTP.
Jeśli robisz to na platformie takiej jak Koder.ai, upewnij się, że custom domains są połączone i SSL jest wydany zanim zmienisz produkcyjne DNS, i miej gotowy plan rollback, żeby złe przekierowanie lub rekord nie wisiało długo.
Spokojne przełączenie to w dużej mierze praca przygotowawcza. Cel jest prosty: użytkownicy powinni pozostać zalogowani, ciasteczka działać, a ty musisz mieć możliwość szybkiego rollbacku, jeśli coś pójdzie nie tak.
Wykonaj to, gdy ruch nadal idzie do starej domeny. Daj sobie dzień, jeśli możesz, aby zmiany DNS miały czas się rozpropagować.
www, api itp.) i wybierz metodę walidacji SSL (DNS lub HTTP).www -> apex (lub odwrotnie), i jeden host kanoniczny.Gdy zmieniasz DNS, traktuj pierwszą godzinę jak ćwiczenie na wypadek incydentu. Obserwuj rzeczywiste przepływy użytkowników, nie tylko panele statusu.
Nawet jeśli Koder.ai (lub inna platforma) obsługuje custom domains i SSL za ciebie, ta lista kontrolna wciąż ma znaczenie. Większość problemów pochodzi z DNS i przekierowań, nie z kodu aplikacji.
Twoja aplikacja działa pod tymczasowym adresem platformy, np. myapp.koder.ai. Działa, ale chcesz, żeby klienci używali example.com, z www.example.com przekierowującym na apex i wszystkim wymuszonym na HTTPS.
Prosty plan DNS utrzyma ryzyko niskie. Zanim cokolwiek zmienisz, zanotuj bieżący działający stan (zrób snapshot, jeśli platforma to wspiera, jak Koder.ai) i obniż TTL na krótko przed zmianą.
Dodaj nowe rekordy, zostawiając istniejący adres platformy bez zmian:
example.com: rekord A/ALIAS wskazujący na cel hostingu podany przez platformęwww.example.com: CNAME wskazujący na example.com (lub na cel platformy, zależnie od dostawcy)myapp.koder.ai bez zmian, by mieć zawsze znany, działający fallbackGdy DNS jest skonfigurowany, poproś o SSL dla obu hostname’ów (example.com i www.example.com). Nie przekierowuj ruchu, dopóki certyfikat nie zostanie wydany i nie będzie aktywny — w przeciwnym razie użytkownicy zobaczą ostrzeżenia.
Harmonogram przełączenia z punktami kontrolnymi:
example.com w trybie incognito (strona główna, zasoby statyczne, wywołania API)www -> apex)Po zmianie sprawdź zachowanie ciasteczek. Zaloguj się, odśwież i upewnij się, że sesja jest zachowana zarówno na www, jak i na apex. Jeśli sesje zawodzą, zwykle winne jest ustawienie domeny ciasteczka lub SameSite, które wciąż zakładają stary host.
Po udanym przełączeniu praca się nie kończy. Większość problemów pojawia się później, gdy nikt nie zauważy: certyfikat zbliża się do wygaśnięcia, ktoś robi pośpieszny update DNS, albo zmiana przekierowania psuje logowanie.
Ustal prostą rutynę monitoringu, której rzeczywiście będziesz się trzymać. Nie potrzebujesz narzędzia klasy enterprise, ale potrzebujesz kilku wiarygodnych sygnałów: kontrole dostępności kluczowych stron (strona główna, logowanie i jedna strona wymagająca autoryzacji), alerty o wygasaniu certyfikatu (np. 30 dni i 7 dni przed), śledzenie wskaźników błędów (sprawdzaj skoki 4xx/5xx, nie tylko uptime) oraz okresowe walidacje przekierowań (HTTP powinien iść na HTTPS, a preferowany host wygrywa).
Przez 24–72 godziny trzymaj przygotowany rollback (stare cele DNS, starą konfigurację hostingu, stare ustawienia TLS), aby móc szybko cofnąć się, jeśli wyjdzie ukryty problem, np. callback płatności lub dostawca OAuth nadal wskazujący starą domenę.
Gdy poczujesz się pewnie, podnieś TTL z powrotem. Niskie TTLy są użyteczne podczas zmian, ale zwiększają obciążenie resolverów i potęgują wpływ drobnych błędów później. Wybierz normalny TTL odpowiadający częstotliwości zmian (wiele zespołów wybiera 1–4 godziny).
Na koniec, udokumentuj finalny stan, póki jest świeżo: jakie rekordy istnieją (typ, nazwa, wartość, TTL), jakie hostname’y są obsługiwane i dokładne reguły przekierowań. Dołącz informacje, gdzie wystawiane są certyfikaty, co obejmują (apex, www, subdomeny) i kto odpowiada za odnowienia.
Jeśli budujesz i wdrażasz na platformie, warto, by domeny były traktowane jako funkcja pierwszorzędna, z prostym rollbackem. Na Koder.ai custom domains siedzą obok snapshotów i rollbacku, co ułatwia przyszłe zmiany i szybkie cofnięcie, gdy trzeba.
Default to one canonical hostname and redirect everything else to it.
example.com (apex) or www.example.com as the “real” one.This keeps cookies, sessions, and bookmarks consistent and prevents half-working behavior.
Lower TTL the day before you plan to switch, then wait long enough for the old TTL to age out.
Only lower TTL on the records you’re actually going to change.
For many app setups:
www.example.com or app.example.com when you’re pointing to a provider hostname.example.com.Don’t switch user traffic until HTTPS is valid on the new hostname(s).
A practical order:
This avoids browser warnings and blocked requests right at cutover.
Most email breakage happens when people delete or overwrite MX and TXT records.
Before changing anything:
Redirect chains and loops usually come from conflicting rules between your CDN/proxy and your app.
Use these safe defaults:
http:// → https://If you’re behind a proxy/CDN, make sure your app respects forwarded scheme headers; otherwise it may think every request is HTTP and keep redirecting forever.
Yes, it’s common if cookies were scoped to the old hostname.
What to check:
old-host won’t be sent to new-hostUpdate identity settings before cutover.
Typical items that must match the new domain exactly:
If these still point to the old domain, sign-in can succeed at the provider but fail when returning to your app.
A rollback is usually just restoring the previous DNS values.
Keep it simple:
If your platform supports snapshots/rollback (Koder.ai does), take one before cutover so you can quickly undo related configuration changes too.
Focus on real user paths, not just the homepage.
Test these on both the canonical host and the redirecting host:
Also verify the address bar ends on and always on , with no mixed-content warnings.
Avoid trying to force a CNAME at the apex if your DNS host doesn’t support an apex alias style record.
A quick safety step is exporting or screenshotting the current zone so you can restore it fast.
A low-risk approach is keeping the old hostname working during a transition so users can refresh sessions on the new domain.