Guida alla configurazione di domini personalizzati per app web: passaggi DNS chiari, emissione SSL, regole di redirect e un piano di cutover a basso rischio per evitare downtime e problemi con i cookie.
Un dominio personalizzato è più di un URL più carino. Nel momento in cui passi da un indirizzo di piattaforma (per esempio, un'app che hai costruito su Koder.ai sotto un sottodominio di piattaforma) al tuo dominio, i browser e le reti lo trattano come un sito diverso. Questo influenza il routing, la sicurezza e il comportamento delle sessioni utente.
Appena passi a un dominio personalizzato, alcune cose cambiano subito:
www o sull'apex, e servono regole coerenti da HTTP a HTTPS.old-platform.example non funzionerà automaticamente su app.yourdomain.com.Brevi interruzioni solitamente nascono dalla temporizzazione. Il DNS può cominciare a inviare traffico al nuovo host prima che il certificato SSL sia pronto, causando avvisi nel browser. Oppure può succedere il contrario: il certificato è pronto, ma molti utenti colpiscono ancora il vecchio host perché la loro cache DNS non è scaduta.
I redirect possono anche rompere i login in modi sottili. Un redirect che cambia hostname (da apex a www, o viceversa) può far perdere cookie se erano impostati per l'altro host. I provider di autenticazione possono fallire se la callback URL è ancora il vecchio dominio.
Un cutover a basso rischio significa pianificare una sovrapposizione: mantenere il vecchio URL funzionante, preparare il nuovo dominio in parallelo, cambiare il traffico in un momento prevedibile e rendere il rollback semplice come riportare indietro il DNS.
Prima di cambiare qualsiasi cosa, annota esattamente quali nomi vuoi che gli utenti digitino e quali devono semplicemente reindirizzare. La maggior parte dei momenti del tipo “perché funziona a metà?” nasce da un team che non ha concordato un unico hostname vero.
Inizia con la scelta principale: apex (example.com) o www (www.example.com) come primario. Entrambi possono funzionare, ma scegline uno e tratta l'altro come redirect. Questo conta anche per i cookie: le sessioni sono generalmente più semplici quando l'app vive su un host coerente.
Poi decidi quali sottodomini ti servono ora e quali possono aspettare. Un pattern comune è app.example.com per la web app e api.example.com per le API, con admin.example.com o assets.example.com aggiunti più tardi. Se stai configurando un dominio personalizzato su una piattaforma come Koder.ai, queste scelte mappano direttamente a ciò che dovrai convalidare per SSL e a cosa puntare nel DNS.
Molte persone comprano un dominio dal registrar, ma il DNS può essere ospitato altrove. Conferma dove si modificano oggi i record, chi ha accesso e se ci sono automazioni che gestiscono le modifiche (IT aziendale, un'agenzia o un provider DNS gestito). Se non puoi effettuare il login e vedere i record attuali, fermati e risolvi prima quello.
Fai anche una verifica di cosa usa già il dominio. La posta elettronica è la trappola classica: puoi interrompere la consegna della posta cancellando o sovrascrivendo record.
Prima di procedere, cattura queste decisioni per iscritto:
www) e direzione del redirectSe il marketing già gestisce la posta su example.com, non toccare i record legati alla posta mentre aggiungi solo ciò che serve all'app.
La maggior parte del rischio nello spostamento di un dominio personalizzato non è nell'app in sé. È una modifica DNS sbagliata che manda il traffico nel vuoto, rompe la posta o fa fallire la validazione SSL.
Un record A punta un nome a un indirizzo IP. In termini semplici: “manda le persone a questo server.” È comune per l'apex (example.com) quando il provider ti dà un IP fisso.
Un record CNAME punta un nome a un altro nome. In termini semplici: “tratta questo nome come alias di quell'hostname.” È comune per www.example.com che punta a un hostname della piattaforma.
Molti provider DNS offrono anche ALIAS/ANAME per l'apex. Si comporta come un CNAME ma funziona per example.com. Se il tuo provider lo supporta, può essere più facile da gestire perché la destinazione può cambiare senza che tu tocchi gli IP.
Un modello mentale semplice:
Spesso aggiungerai TXT per verifiche di proprietà del dominio (verifica piattaforma) e per la validazione del certificato SSL (alcune CA validano via token TXT). TXT è anche usato per policy email come SPF. Cancellare o sostituire uno SPF esistente può rompere la consegna della posta.
Il TTL controlla per quanto tempo altri sistemi memorizzano nella cache la risposta DNS. Un giorno prima del cutover, abbassa il TTL sui record che prevedi di cambiare (comunemente 300–600 secondi). Quando tutto è stabile, rialzalo per ridurre il carico di query.
Prima di modificare, esporta o fai screenshot della zona attuale. Annota ogni record che cambierai, il suo vecchio valore, il nuovo valore e il TTL. Se qualcosa va storto, il rollback è ripristinare i valori precedenti.
Questo è particolarmente importante quando il dominio già ha MX, DKIM o altri TXT per la posta.
SSL (l'icona del lucchetto) cifra il traffico tra browser e app. I browser moderni e molte API si aspettano HTTPS di default. Senza di esso puoi ottenere avvisi, richieste bloccate e funzionalità come service worker, geolocalizzazione e alcuni flussi di pagamento possono smettere di funzionare.
Per emettere un certificato, l'autorità di certificazione deve verificare che controlli il dominio. I metodi comuni di validazione sono la validazione HTTP e la validazione via TXT DNS:
La validazione DNS è spesso più semplice quando usi una CDN o quando la tua app non è ancora raggiungibile sul nuovo dominio.
Dove viene emesso il certificato dipende dalla tua configurazione. Alcuni team emettono certs direttamente nello stack di hosting, altri lo fanno alla CDN, e alcune piattaforme che supportano custom domain gestiscono il tutto per te (per esempio, Koder.ai può gestire il certificato durante la configurazione del dominio). Ciò che conta è sapere chi è responsabile del ciclo di vita del certificato, incluse le rinnovazioni.
L'emissione non è sempre istantanea. La propagazione DNS, i controlli di validazione e i limiti di rate possono rallentare. Pianifica retry e evita di fissare il cutover all'ultimo minuto.
Un piano pratico di tempistica:
Un certificato deve coprire ogni hostname che gli utenti possono raggiungere. Controlla la lista SAN (Subject Alternative Names). Se la tua app sarà disponibile sia su example.com che su www.example.com, il certificato deve includere entrambi.
I wildcard (come *.example.com) possono aiutare per molti sottodomini, ma non coprono l'apex (example.com).
Esempio concreto: se emetti un cert solo per www.example.com, gli utenti che digitano example.com vedranno comunque avvisi a meno che tu non reindirizzi a un livello che ha già un certificato valido per example.com.
I redirect sembrano semplici, ma la maggior parte dei problemi di dominio emerge qui: loop, contenuto misto e utenti che vengono disconnessi perché rimbalzano tra host.
Scegli un host canonico e mantienilo: www.example.com o example.com (apex). L'altro punto di accesso dovrebbe reindirizzare al host canonico scelto così cookie, sessioni e segnali SEO restano coerenti.
Default sicuri:
http:// a https:// per ogni richiestaPer HTTP→HTTPS, evita regole che rimbalzino gli utenti avanti e indietro. Il modo più semplice per prevenire loop è basare la decisione su cosa fosse realmente la richiesta originale. Se la tua app sta dietro a un proxy o CDN, configuralo per rispettare le intestazioni forwarded (per esempio, un header che indica che lo schema originale era HTTP). Altrimenti, la tua app può pensare che ogni richiesta sia HTTP e continuare a reindirizzare all'infinito.
Durante una migrazione, mantieni i vecchi percorsi vivi. Se stai cambiando route (come /login in /sign-in), aggiungi redirect espliciti per quelle path. Non fare affidamento su un redirect blanket verso la homepage: rompe bookmark e link condivisi.
Rinvieni HSTS all'inizio. Se lo abiliti troppo presto e poi hai bisogno di servire HTTP per validazioni o troubleshooting, i browser potrebbero rifiutare. Aspetta che HTTPS sia stabile e che tu abbia confermato la copertura dei sottodomini.
Per testare i redirect senza impattare tutti, usa un hostname di test temporaneo, prova alcuni deep link reali (incluse pagine di auth) ed esegui richieste da riga di comando che mostrino ogni step di redirect e la destinazione finale.
Un cutover sicuro è soprattutto questione di tempistica. Vuoi che il nuovo dominio sia pronto e testato prima che qualsiasi utente reale vi venga indirizzato, e vuoi che le modifiche DNS si propaghino in fretta così non resti bloccato durante un incidente.
Abbassa il TTL dei record che cambierai con largo anticipo. Fallo il giorno prima se puoi, poi attendi che la finestra del vecchio TTL sia trascorsa così le cache avranno il tempo di recepire il nuovo valore.
Poi aggiungi il dominio personalizzato nel tuo hosting/provider e completa le verifiche richieste. Se usi una piattaforma come Koder.ai, aggiungi il dominio lì prima così la piattaforma può confermare la proprietà e preparare il routing.
Emetti il certificato SSL in anticipo. I certificati possono richiedere minuti o più in base alla validazione, e non vuoi quel ritardo durante il cambio.
Prima di rendere pubblico il dominio, fai un test privato: colpisci il nuovo endpoint in un modo che non dipenda dal DNS pubblico (per esempio modificando temporaneamente il file hosts sulla tua macchina) e conferma che il sito carica in HTTPS con il certificato corretto.
Usa un approccio a tappe così puoi fermarti rapidamente se qualcosa non va:
www) prima di cambiare gli utenti.Se non puoi fare un vero canary a livello DNS, puoi comunque stratificare cambiando prima un solo hostname (per esempio www) e lasciando l'apex intatto finché non hai fiducia.
Scrivi esattamente cosa reverterai (quali record, quali valori) e chi lo farà. Il rollback di solito è ripristinare il DNS com'era.
Assicurati che la vecchia configurazione sia ancora valida (incluso SSL sul vecchio dominio) così gli utenti possono tornare puliti mentre risolvi il nuovo percorso.
Un cambio di dominio non è solo una modifica DNS. Per molte app, “essere loggati” dipende da cookie che i browser legano a un hostname specifico. Se cambi hostname, il browser potrebbe smettere di inviare i vecchi cookie e la tua app sembrerà aver disconnesso tutti.
Le impostazioni dei cookie sono spesso la causa:
app.old.com non verrà inviato a app.new.com. Un cookie impostato per .example.com può funzionare su app.example.com e www.example.com./api), la UI web potrebbe non vederlo.Lax spesso è sufficiente, ma alcuni SSO o redirect di pagamento possono richiedere None più Secure.Per ridurre il rischio, pianifica una breve transizione in cui entrambi i domini funzionano. Mantieni il vecchio hostname che risponde e reindirizza con cura, ma consenti il refresh delle sessioni sul nuovo dominio. Se puoi, usa uno store di sessione condiviso così un utente che colpisce uno qualsiasi dei due hostname può essere riconosciuto.
Se usi SSO o OAuth, aggiorna le impostazioni prima del cutover: callback URL, allowed origins e qualsiasi allowlist per redirect URI. Altrimenti i login possono riuscire presso l'identity provider ma fallire al ritorno nell'app.
Testa per prime le flow che di solito si rompono: registrazione (e verifica email), login/logout, reset password, checkout o ritorni da pagamento, e sessioni multi-tab.
Esempio: se reindirizzi www.example.com a example.com, assicurati che i cookie siano impostati per .example.com (o usa coerentemente un solo hostname). Altrimenti gli utenti rimbalzano tra host e perdono la sessione.
La maggior parte dei problemi di dominio non sono “misteriosi problemi internet”. Sono piccole discrepanze tra DNS, certificati e regole di redirect che si manifestano solo quando gli utenti reali colpiscono il sito.
Una trappola semplice è l'apex (example.com). Molti provider DNS non consentono un vero CNAME all'apex. Se provi a puntare l'apex a un CNAME, può fallire silenziosamente, risolversi in modo incoerente o rompersi solo su alcune reti. Usa ciò che il tuo host DNS supporta (spesso un record A/AAAA, o un record ALIAS/ANAME).
Un'altra causa frequente di downtime è cambiare il DNS prima che SSL sia pronto sul nuovo endpoint. Gli utenti arrivano, l'app si carica e poi il browser lo blocca perché manca il certificato o copre solo parte degli hostname. In pratica, di solito vuoi che il certificato copra sia example.com che www.example.com, anche se prevedi di reindirizzare uno all'altro.
Errori comuni che creano outage o comportamenti strani:
www → apex poi apex → www), o forzare HTTP in un posto e HTTPS in un altrohttp:// per asset, che provoca avvisi del browser e funzionalità rotteUn controllo rapido: apri entrambi gli hostname (www e apex) su HTTPS, esegui il login, ricarica e conferma che la barra dell'indirizzo non torni mai a HTTP.
Se lo fai su una piattaforma come Koder.ai, conferma che i custom domain siano collegati e che SSL sia emesso prima di toccare il DNS di produzione, e tieni pronto un piano di rollback così un redirect o un record sbagliato non rimanga appeso.
Un cutover calmo è soprattutto lavoro di preparazione. L'obiettivo è semplice: gli utenti devono continuare a loggarsi, i cookie devono continuare a funzionare e devi poter tornare indietro rapidamente se qualcosa non va.
Fai queste operazioni mentre il traffico va ancora al vecchio dominio. Concediti un giorno se puoi, così le modifiche DNS hanno il tempo di stabilizzarsi.
www, api, ecc.) e scegli il metodo di validazione SSL (DNS o HTTP).www → apex (o viceversa) e un host canonico.Quando cambi il DNS, tratta la prima ora come un drill d'incidente. Guarda i flussi reali degli utenti, non solo i dashboard di stato.
Anche se Koder.ai (o un altro provider) gestisce custom domain e SSL per te, questa checklist rimane rilevante. La maggioranza dei problemi deriva da DNS e redirect, non dal codice dell'app.
La tua app gira su un indirizzo temporaneo di piattaforma come myapp.koder.ai. Funziona, ma vuoi che i clienti usino example.com, con www.example.com che reindirizza all'apex e tutto forzato su HTTPS.
Un piano DNS semplice riduce il rischio. Prima di cambiare qualsiasi cosa, annota lo stato attualmente funzionante (fai uno snapshot se la tua piattaforma lo supporta, come fa Koder.ai) e riduci il TTL DNS a qualcosa di breve con 24 ore di anticipo.
Aggiungi i nuovi record lasciando intatto l'URL della piattaforma:
example.com: record A/ALIAS che punta al target di hosting fornito dalla piattaformawww.example.com: CNAME che punta a example.com (o al target della piattaforma, a seconda del provider)myapp.koder.ai così avrai sempre un fallback noto funzionanteUna volta che il DNS è a posto, richiedi SSL per entrambi gli hostname (example.com e www.example.com). Non cambiare il traffico finché il certificato non è emesso e attivo, altrimenti gli utenti vedranno avvisi del browser.
Timeline di cutover con checkpoint chiari:
example.com in una finestra in incognito (home, asset statici, chiamate API)www→apex)Dopo lo spostamento, valida il comportamento dei cookie. Effettua il login, ricarica e controlla di restare autenticato sia su www che su apex. Se le sessioni si rompono, spesso è una configurazione di cookie o SameSite che assume ancora il vecchio host.
Dopo che il cutover ha funzionato, il lavoro non è finito. La maggior parte dei fallimenti nei domain move arriva dopo, perché nessuno nota un lento degrado: un certificato vicino alla scadenza, una modifica DNS frettolosa o una variazione del redirect che rompe un flusso di login.
Stabilisci una piccola routine di monitoraggio che manterrai davvero. Non serve uno strumento enterprise per cominciare, ma ti servono alcuni segnali affidabili: controlli di disponibilità per pagine chiave (home, login e una pagina autenticata), avvisi di scadenza certificato (per esempio a 30 giorni e poi a 7 giorni), monitoraggio del tasso di errori (osserva i picchi di 4xx/5xx, non solo l'uptime) e convalide periodiche dei redirect (HTTP va a HTTPS e l'hostname preferito vince).
Tieni una breve finestra di rollback, anche se tutto sembra a posto. Per 24–72 ore, mantieni la configurazione precedente pronta (vecchi target DNS, vecchia configurazione hosting, vecchie impostazioni TLS) così puoi tornare indietro rapidamente se appare un problema nascosto, come un callback di pagamento o un provider OAuth che punta ancora al vecchio dominio.
Quando sei sicuro, rialza i valori TTL DNS. Il TTL basso è utile durante i cambi, ma aggiunge carico ai resolver e aumenta l'impatto di piccoli errori. Scegli un TTL normale che rispecchi quanto spesso prevedi cambi (molti team scelgono 1–4 ore).
Infine, documenta lo stato finale mentre è ancora fresco: quali record esistono (tipo, nome, valore, TTL), quali hostname sono supportati e le regole di redirect esatte. Includi dove sono emessi i certificati, cosa coprono (apex, www, sottodomini) e chi è responsabile dei rinnovi.
Se costruisci e distribuisci su una piattaforma, aiuta quando i domini sono trattati come feature di prima classe e il rollback è semplice. Su Koder.ai, i custom domain stanno accanto a snapshot e rollback, il che può rendere meno stressanti i cambi futuri quando qualcosa deve essere annullato rapidamente.
Default a un solo hostname canonico e reindirizza tutto il resto verso di esso.
example.com (apex) o www.example.com come “vero” hostname.Questo mantiene coerenti cookie, sessioni e segnalazioni SEO ed evita comportamenti a metà.
Abbassa il TTL il giorno prima di prevedere il cambio, poi attendi abbastanza a lungo perché il vecchio TTL venga scaduto.
Abbassa il TTL solo sui record che intendi modificare.
Per molte configurazioni app:
www.example.com o app.example.com quando punti a un hostname del provider.example.com.Non mandare traffico utenti finché HTTPS non è valido sui nuovi hostname.
Ordine pratico:
Questo evita avvisi del browser e richieste bloccate proprio al cutover.
La maggior parte dei problemi email nasce dal cancellare o sovrascrivere MX e TXT.
Prima di cambiare qualsiasi cosa:
Le catene e i loop di redirect derivano solitamente da regole conflittuali tra CDN/proxy e l'app.
Usa queste impostazioni sicure:
http:// → https://Se sei dietro un proxy/CDN, assicurati che la tua app rispetti le intestazioni forwarded scheme; altrimenti potrebbe pensare che ogni richiesta sia HTTP e continuare a reindirizzare all'infinito.
Sì, è comune se i cookie erano limitati all'hostname vecchio.
Cosa controllare:
old-host non verranno inviati a new-hostAggiorna le impostazioni identity prima del cutover.
Voci tipiche che devono corrispondere esattamente al nuovo dominio:
Se questi puntano ancora al vecchio dominio, il login può riuscire dal provider ma fallire al ritorno nell'app.
Un rollback è di solito solo il ripristino dei valori DNS precedenti.
Mantienilo semplice:
Se la tua piattaforma supporta snapshot/rollback (Koder.ai lo fa), prendine uno prima del cutover così puoi annullare anche le modifiche di configurazione correlate.
Concentrati sui percorsi reali degli utenti, non solo sulla homepage.
Testa questi sia sull'host canonico sia su quello che reindirizza:
Verifica anche che la barra dell'indirizzo finisca su e sempre su , senza avvisi di contenuti misti.
Evita di forzare un CNAME all'apex se il tuo host DNS non supporta uno stile alias per l'apex.
Un passo di sicurezza rapido è esportare o fare screenshot della zona attuale in modo da poterla ripristinare velocemente.
Un approccio a basso rischio è mantenere l'hostname vecchio attivo durante la transizione in modo che gli utenti possano rinfrescare le sessioni sul nuovo dominio.