Konfigurera en anpassad domän för webbappar med tydliga DNS-steg, SSL-utfärdande, omdirigeringar och en låg-risks plan för övergång utan nertid eller cookie-problem.
En anpassad domän är mer än en finare URL. I det ögonblick du går från en plattformsadress (till exempel en app du byggt på Koder.ai under ett plattforms-underdomän) till din egen domän, behandlar webbläsare och nätverk det som en annan webbplats. Det påverkar routing, säkerhet och hur användarsessioner beter sig.
När du växlar till en anpassad domän förändras några saker omedelbart:
www eller apex-domänen, och du behöver konsekventa regler för HTTP → HTTPS.old-platform.example fungerar inte automatiskt på app.yourdomain.com.Korta avbrott kommer ofta från tidpunktsskillnader. DNS kan börja skicka trafik till den nya hosten innan SSL-certifikatet är klart, vilket leder till webbläsarvarningar. Eller motsatsen: SSL är klart, men många användare träffar fortfarande det gamla stället eftersom deras DNS-cache inte har löpt ut.
Omdirigeringar kan också förstöra inloggningar på subtila sätt. En omdirigering som ändrar hostnamnet (apex → www, eller tvärtom) kan göra att cookies tappas om de sattes för det andra hostnamnet. Auth-leverantörer kan misslyckas om deras callback-URL fortfarande är den gamla domänen.
En låg-risks övergång betyder att du planerar för överlappning: behåll den gamla URL:en fungerande, ta upp den nya domänen parallellt, växla trafik vid ett förutsägbart tillfälle och gör rollback så enkelt som att ändra DNS tillbaka.
Innan du ändrar något, skriv ner exakt vilka namn du vill att användare ska skriva och vilka namn som tyst ska omdirigeras. De flesta "varför fungerar det halvbra?"-ögonblick kommer av att teamet aldrig enats om ett enda sannolikt hostname.
Börja med det stora valet: apex (example.com) eller www (www.example.com) som primär. Båda kan fungera, men välj en och behandla den andra som en omdirigering. Detta spelar senare roll för cookies också: sessioner är ofta enklast när appen ligger på ett konsekvent host.
Bestäm sedan vilka subdomäner du behöver nu och vilka som kan vänta. Ett vanligt mönster är app.example.com för webbappen och api.example.com för API:er, med admin.example.com eller assets.example.com tillagt senare. Om du sätter upp en anpassad domän på en plattform som Koder.ai, mappar dessa val direkt till vad du kommer att validera för SSL och vad du pekar i DNS.
Många köper en domän hos en registrar, men DNS kan vara hostad någon annanstans. Bekräfta var poster redigeras idag, vem som har åtkomst och om någon automation hanterar ändringar (företags-IT, en byrå eller en hanterad DNS-leverantör). Om du inte kan logga in och se aktuella poster — stoppa och fixa det först.
Granska också vad som redan använder domänen. E-post är den klassiska fällan: du kan bryta leverans genom att radera eller skriva över poster.
Innan du fortsätter, fånga dessa beslut skriftligt:
www) och riktning för omdirigeringOm marknadsföring redan kör e-post på example.com, lämna mail-relaterade poster orörda medan du bara lägger till det appen behöver.
Det mesta av risken i en flytt till anpassad domän är inte appen själv. Det är en fel DNS-ändring som skickar trafik till ingenstans, bryter e-post eller gör SSL-validering ogiltig.
En A-post pekar ett namn till en IP-adress. I klartext: "skicka folk till denna server." Det är vanligt för apex (example.com) när din leverantör ger en fast IP.
En CNAME-post pekar ett namn till ett annat namn. I klartext: "behandla detta namn som en alias för det där hostnamnet." Det är vanligt för www.example.com som pekar mot ett plattforms-hostname.
Många DNS-leverantörer erbjuder också ALIAS/ANAME för apex. Det beter sig som en CNAME men fungerar för example.com. Om din leverantör stödjer det kan det vara enklare att hantera eftersom målet kan flytta utan att du måste ändra IP:er.
En enkel mental modell:
Du kommer ofta lägga till TXT-poster för äganderättskontroller (plattformverifiering) och för SSL-certifikatvalidering (vissa CA:er validerar via en TXT-token). TXT används också för e-postpolicy som SPF. Att av misstag radera eller ersätta ett befintligt SPF-TXT kan bryta e-postleverans.
TTL styr hur länge andra system cachar ditt DNS-svar. En dag före cutover, sänk TTL för de poster du planerar att ändra (vanligtvis 300–600 sekunder). När allt är stabilt, höj det igen för att minska fråga-belastningen.
Innan du redigerar, exportera eller skärmdumpa den nuvarande zonen. Skriv ner varje post du kommer att ändra, dess gamla värde, nya värde och TTL. Om något går fel är rollback att återställa de tidigare värdena.
Det här är särskilt viktigt när din domän redan har MX, DKIM eller andra TXT-poster för e-post.
SSL (hänglåset) krypterar trafiken mellan webbläsaren och din app. Moderna webbläsare och många API:er förväntar sig HTTPS som standard. Utan det kan du få varningar, blockerade förfrågningar och funktioner som service workers, geolocation och vissa betalflöden kan sluta fungera.
För att utfärda ett certifikat måste CA:n verifiera att du kontrollerar domänen. Vanliga valideringsmetoder är HTTP-validering och DNS TXT-validering:
DNS-validering är ofta enklare när du använder en CDN eller när din app ännu inte är nåbar på den nya domänen.
Var certifikatet utfärdas beror på din setup. Vissa team utfärdar certifikat direkt på sitt hostingstack, vissa gör det vid CDN, och vissa plattformar som stödjer anpassade domäner hanterar det åt dig (till exempel kan Koder.ai sköta certifikatet under domäninställningen). Det viktiga är att veta vem som äger certifikatets livscykel, inklusive förnyelser.
Utfärdande av certifikat är inte alltid omedelbart. DNS-propagation, valideringskontroller och rate limits kan fördröja processen. Planera för omförsök och undvik att schemalägga cutovern i sista minuten.
En praktisk tidsplan:
Ett certifikat måste täcka varje hostname användare kommer åt. Kolla SAN-listan (Subject Alternative Names). Om din app ska vara tillgänglig på både example.com och www.example.com, måste certifikatet inkludera båda.
Wildcard-certifikat (som *.example.com) kan hjälpa för många subdomäner, men täcker inte apex-domänen (example.com).
Konkreta exemplet: om du bara utfärdar ett certifikat för www.example.com, kommer användare som skriver example.com fortfarande att få varningar om du inte omdirigerar på en nivå som redan har ett giltigt certifikat för example.com.
Omdirigeringar låter enkla, men de flesta domänproblem visar sig här: loopar, mixed content och användare som loggas ut eftersom de studsar mellan hostnames.
Välj ett kanoniskt host och håll dig till det: antingen www.example.com eller example.com (apex). Den andra ingångspunkten bör omdirigera till din valda kanoniska host så cookies, sessioner och SEO-signaler hålls konsekventa.
Säkra standarder:
http:// till https:// för varje förfråganFör HTTP → HTTPS, undvik regler som studsar användare fram och tillbaka. Det enklaste sättet att förhindra loopar är att basera beslutet på vad förfrågan faktiskt var. Om din app sitter bakom en proxy eller CDN, konfigurera den att respektera vidarebefordrade headers (t.ex. en header som säger att originalscheme var HTTP). Annars kan din app tro att varje förfrågan är HTTP och fortsätta omdirigera i oändlighet.
Under en flytt, håll gamla sökvägar levande. Om du ändrar rutter (som /login till /sign-in), lägg till explicita omdirigeringar för dessa sökvägar. Lita inte på en generell omdirigering till startsidan — det bryter bokmärken och delade länkar.
Vänta med HSTS initialt. Om du aktiverar det för tidigt och senare behöver servera HTTP för validering eller felsökning kan webbläsare vägra. Vänta tills HTTPS är stabilt och du bekräftat subdomäntäckning.
För att testa omdirigeringar utan att påverka alla, använd ett temporärt test-hostname, prova ett par riktiga djupa länkar (inklusive auth-sidor) och kör en kommandoradsförfrågan som visar varje omdirigeringssteg och slutdestination.
En säker cutover är mest timing. Du vill att din nya domän ska vara redo och testad innan riktiga användare skickas dit, och du vill att DNS-ändringar sprids snabbt så du inte sitter och väntar under en incident.
Sänk din DNS-TTL (för de poster du kommer ändra) i god tid. Gör det dagen innan om du kan, och vänta sedan ut den gamla TTL-intervallet så att cachar hinner plocka upp det lägre värdet.
Lägg sedan till den anpassade domänen i din hosting/leverantör och slutför den verifiering de kräver. Om du använder en plattform som Koder.ai, lägg till domänen där först så plattformen kan bekräfta ägarskap och förbereda routing.
Utfärda SSL i förväg. Certifikat kan ta minuter eller längre beroende på validering, och du vill inte ha den fördröjningen under bytet.
Innan du gör domänen publik, gör ett privat test: träffa den nya endpointen på ett sätt som inte beror på publik DNS (t.ex. genom att lägga en temporär host-post på din egen maskin) och bekräfta att sajten laddar över HTTPS med rätt certifikat.
Använd en stegvis metod så du kan stoppa snabbt om något ser konstigt ut:
www) innan du flyttar användare.Om du inte kan göra en riktig canary på DNS-nivå kan du fortfarande stage:a genom att byta bara ett hostname först (t.ex. www) och lämna apex orörd tills du fått förtroende.
Skriv ner exakt vad du kommer att återställa (vilka poster, vilka värden) och vem som gör det. Rollback är vanligtvis att lägga tillbaka DNS precis som det var.
Se till att den gamla setupen fortfarande är giltig (inklusive SSL på den gamla domänen) så att användare kan falla tillbaka smidigt medan du åtgärdar den nya vägen.
En domänändring är inte bara en DNS-ändring. För många appar beror "inloggad" på cookies som webbläsare kopplar till ett särskilt hostname. Om du byter från ett hostname till ett annat kommer webbläsaren kanske sluta skicka de gamla cookiesen, och din app ser ut som om alla loggats ut.
Cookie-inställningar är ofta orsaken:
app.old.com skickas inte till app.new.com. En cookie satt för .example.com kan fungera över app.example.com och www.example.com./api) kanske webb-UI:t inte ser den.Lax är ofta ok, men vissa SSO- eller betalningsomdirigeringar kan behöva None plus Secure.För att minska risk, planera en kort övergång där båda domänerna fungerar. Håll det gamla hostnamnet svarande och omdirigerande, men tillåt sessioner att uppdateras på den nya domänen. Om möjligt, använd en delad sessionslagring så en användare som träffar vilket host som helst fortfarande kan kännas igen.
Om du använder SSO eller OAuth, uppdatera inställningarna före cutover: callback-URL:er, tillåtna origins och alla "audience" eller redirect-URI-allowlists. Annars kan inloggningar lyckas hos identitetsleverantören men misslyckas vid återvändandet till appen.
Testa de flöden som brukar bråka först: registrering (och e-postverifiering), inloggning/utloggning, lösenordsåterställning, betalningsretur och sessioner över flera flikar.
Exempel: om du omdirigerar www.example.com till example.com, se till att cookies sätts för .example.com (eller använd konsekvent ett hostname). Annars studsar användare mellan hostnames och förlorar sin session.
De flesta domänproblem är inte "mystiska internetproblem". De är små mismatch mellan DNS, certifikat och omdirigeringsregler som bara visar sig när riktiga användare kommer till sajten.
En enkel fälla är apex-domänen (example.com). Många DNS-leverantörer tillåter inte en riktig CNAME på apex. Om du pekar apex mot en CNAME ändå kan det misslyckas tyst, lösas inkonsekvent eller bara bryta på vissa nätverk. Använd det din DNS-host stödjer (ofta en A/AAAA-post eller en ALIAS/ANAME-typ).
En annan frekvent orsak till driftstopp är att man byter DNS innan SSL är klart på den nya endpointen. Användare kommer, appen laddar och webbläsaren blockerar eftersom certifikatet saknas eller bara täcker delar av hostnamnen. I praktiken vill du oftast att certifikatet täcker både example.com och www.example.com, även om du planerar att omdirigera en till den andra.
Vanliga misstag som skapar driftstopp eller konstigt beteende:
www → apex, sedan apex tillbaka till www) eller tvinga HTTP i ett ställe och HTTPS i ett annathttp://-resurser, vilket triggar webbläsarvarningar och brutna funktionerEn snabb hälsokontroll: öppna båda hostnames (www och apex) över HTTPS, logga in, uppdatera och bekräfta att adressfältet aldrig växlar tillbaka till HTTP.
Om du gör detta på en plattform som Koder.ai, bekräfta att anpassade domäner är kopplade och att SSL är utfärdat innan du rör produktions-DNS, och håll en rollback-option redo så en dålig omdirigering eller poständring inte ligger kvar länge.
En lugn cutover är mest förberedelse. Målet är enkelt: användare ska fortsätta vara inloggade, cookies ska fungera och du ska kunna rulla tillbaka snabbt om något ser fel ut.
Gör detta medan trafiken fortfarande går till den gamla domänen. Ge dig själv en dag om möjligt så DNS-ändringar hinner landa.
www, api osv.) och välj din SSL-valideringsmetod (DNS eller HTTP).www → apex (eller tvärtom) och en kanonisk host.När du slår om DNS, behandla första timmen som en incidentövning. Övervaka verkliga användarflöden, inte bara statuspaneler.
Även om Koder.ai (eller en annan plattform) hanterar anpassade domäner och SSL åt dig, är denna checklista fortfarande viktig. De flesta problem kommer från DNS och omdirigeringar, inte appkoden.
Din app körs på en temporär plattformsadress som myapp.koder.ai. Den fungerar, men du vill att kunder ska använda example.com, med www.example.com som omdirigerar till apex, och att allt tvingas till HTTPS.
En enkel DNS-plan håller risken låg. Innan du ändrar något, notera det aktuella fungerande tillståndet (ta en snapshot om plattformen stödjer det, som Koder.ai gör) och sänk DNS-TTL till något kort 24 timmar i förväg.
Lägg till de nya posterna och låt den befintliga plattformsadressen vara orörd:
example.com: A/ALIAS-post som pekar mot hostingmålet din plattform tillhandahållerwww.example.com: CNAME som pekar mot example.com (eller mot plattformens mål beroende på leverantör)myapp.koder.ai som fallback så du alltid har en känd fungerande återgångNär DNS är på plats, begär SSL för båda hostnames (example.com och www.example.com). Byt inte trafik förrän certifikatet är utfärdat och aktivt, annars får användare webbläsarvarningar.
Cutover-tidslinje med tydliga kontrollpunkter:
example.com i ett inkognitofönster (startsida, statiska assets, API-anrop)www → apex)Efter flytten, validera cookie-beteende. Logga in, uppdatera och kontrollera att du förblir inloggad på både www och apex. Om sessioner bryts är det ofta en cookie-domain eller SameSite-inställning som fortfarande antar det gamla hostnamnet.
Efter att cutovern fungerat är jobbet inte klart. De flesta domänflyttar misslyckas senare eftersom ingen märker långsam drift: ett certifikat som närmar sig utgång, en hastig DNS-ändring eller en omdirigeringsjustering som bryter ett inloggflöde.
Sätt upp en enkel övervakningsrutin du faktiskt kommer att följa. Du behöver inte ett enterprise-verktyg för att börja, men du behöver några signaler du litar på: availability-checkar för nyckelsidor (startsida, inloggning och en autentiserad sida), certifikat-utgångsvarningar (t.ex. 30 dagar och 7 dagar kvar), felratsspårning (övervaka 4xx/5xx-spikar, inte bara uptime) och sporadisk omdirigeringsvalidering (HTTP går till HTTPS och prefererat hostname vinner).
Behåll ett kort rollback-fönster, även om allt ser bra ut. I 24–72 timmar, håll den tidigare setupen redo (gamla DNS-mål, gamla hostingkonfigurationer, gamla TLS-inställningar) så du snabbt kan återställa om ett dolt problem dyker upp, som en betalningscallback eller en OAuth-leverantör som fortfarande pekar på den gamla domänen.
När du är säker, höj DNS-TTL-värden igen. Låg TTL är användbar under förändring, men ger ökad belastning på resolvers och ökar konsekvenserna av små misstag senare. Välj en normal TTL som matchar hur ofta du förväntar dig ändringar (många team väljer 1–4 timmar).
Slutligen, dokumentera slutligt tillstånd medan det är färskt: vilka poster som finns (typ, namn, värde, TTL), vilka hostnames som stöds och exakta omdirigeringsregler. Inkludera var certifikat utfärdas, vad de täcker (apex, www, subdomäner) och vem som ansvarar för förnyelser.
Om du bygger och distribuerar på en plattform hjälper det när domäner behandlas som en förstklassig funktion och rollback är enkel. På Koder.ai sitter anpassade domäner tillsammans med snapshots och rollback, vilket kan göra framtida domän- och omdirigeringsändringar mindre stressiga när något behöver ångras snabbt.
Standardisera på en kanonisk hostname och omdirigera allt annat dit.
example.com (apex) eller www.example.com som den ”riktiga”.Detta håller cookies, sessioner och bokmärken konsekventa och förhindrar halv-fungerande beteenden.
Sänk TTL dagen innan du planerar att byta, och vänta tills den gamla TTL-perioden har löpt ut.
Sänk endast TTL för de poster du faktiskt kommer att ändra.
För många app-upplägg:
www.example.com eller app.example.com när du pekar mot ett leverantörs-hostname.example.com.Vänta med att flytta trafik tills HTTPS är giltigt på de nya hostnamnen.
Ett praktiskt förfarande:
Detta undviker att webbläsare visar varningar och blockerar förfrågningar vid cutover.
Mest e-postavbrott händer när folk raderar eller ersätter MX och TXT-poster.
Innan du ändrar något:
Kedjor och loopar kommer ofta från motstridiga regler mellan CDN/proxy och app.
Använd dessa säkra standarder:
http:// → https://Om du ligger bakom en proxy/CDN, se till att din app respekterar vidarebefordrade scheme-headers; annars kan den tro att varje förfrågan är HTTP och fortsätta omdirigera i oändlighet.
Ja, det är vanligt om cookies var scoped till det gamla hostnamnet.
Att kontrollera:
old-host skickas inte till new-hostUppdatera identitetsinställningar före cutover.
Vanliga poster som måste matcha den nya domänen exakt:
Om dessa fortfarande pekar på den gamla domänen kan inloggning lyckas hos leverantören men misslyckas när den återvänder till din app.
Rollback är oftast bara att återställa de tidigare DNS-värdena.
Håll det enkelt:
Om din plattform stödjer snapshots/rollback (Koder.ai gör det), ta en innan cutover så du snabbt kan ångra relaterade konfigurationsändringar också.
Fokusera på verkliga användarvägar, inte bara startsidan.
Testa detta på både den kanoniska hosten och den som omdirigerar:
Verifiera också att adressfältet landar på och alltid på , utan mixed-content-varningar.
Undvik att försöka tvinga en CNAME på apex om din DNS-leverantör inte stödjer en apex-alias.
Ett snabbt säkerhetssteg är att exportera eller skärmdumpa den nuvarande zonen så att du snabbt kan återställa den.
Ett lågriskförfarande är att hålla det gamla hostnamnet aktivt under en övergång så att användare kan uppdatera sina sessioner på den nya domänen.