19 nov 2025·8 min
Checklist per la risoluzione dei problemi di dominio personalizzato: DNS e SSL
Usa questa checklist per diagnosticare problemi di record DNS, ritardi di propagazione e tempi di emissione SSL, con semplici passaggi di verifica.
Usa questa checklist per diagnosticare problemi di record DNS, ritardi di propagazione e tempi di emissione SSL, con semplici passaggi di verifica.
“Custom domain not working” è una frase ombrello per alcuni tipi diversi di guasti. Il browser mostra il sintomo, non la causa. Prima di cambiare qualcosa, definisci cosa stai effettivamente vedendo.
Sintomi tipici includono:
La maggior parte delle volte, c'è un solo problema alla base:
Prima di iniziare a risolvere, assicurati di avere accesso a due posti: dove modifichi i record DNS (registrar o provider DNS) e dove colleghi il dominio sul lato hosting. Per esempio, se stai collegando un'app distribuita su Koder.ai a un dominio personalizzato, ti servono l'accesso al DNS del dominio e le impostazioni del dominio nell'area hosting o di deployment dell'app.
Alcune correzioni sono istantanee (come correggere un errore di battitura). Altre richiedono tempo. Le modifiche DNS possono impiegare a comparire e SSL di solito non si completerà finché il DNS non punta correttamente e il dominio non è raggiungibile. L'obiettivo è smettere di indovinare e confermare ogni livello in ordine.
La maggior parte dei problemi di dominio si riduce a una discrepanza tra (1) l'hostname che stai testando, (2) dove è gestito il DNS, e (3) dove il record punta effettivamente. Quando questi tre elementi coincidono, SSL è di solito l'ultimo passo.
I domini hanno due forme comuni: il dominio root (example.com, chiamato anche apex) e i sottodomini (www.example.com, app.example.com). Sono correlati, ma possono avere record DNS diversi. Quindi è normale che www funzioni mentre l'apex fallisce, o viceversa.
I nameserver decidono chi è responsabile della tua zona DNS. Se hai comprato un dominio da una società ma i nameserver puntano a un'altra, devi modificare il DNS dove i nameserver puntano. Molti casi di “l'ho aggiornato ma non è cambiato nulla” succedono perché i record sono stati modificati nella dashboard sbagliata.
Ecco cosa fanno i principali tipi di record:
Il TTL è il timer del “quanto a lungo mettere in cache questa risposta”. Un TTL basso significa che le cache si aggiornano più velocemente. Un TTL alto significa che potresti dover aspettare più a lungo, anche dopo aver corretto il record. Vedere il valore vecchio per un po' può essere normale.
Quando un dominio personalizzato fallisce, di solito rientra in una di quattro categorie: il DNS non risolve, il DNS risolve nel posto sbagliato, SSL non è pronto, o fallisce solo per alcune persone a causa della cache.
Usa questo albero decisionale:
www funziona ma il dominio root no (o viceversa), probabilmente hai configurato solo un hostname, o hai regole di redirect in conflitto.Procedi più velocemente annotando l'hostname esatto che fallisce (apex vs www) e l'errore esatto. Su piattaforme che automatizzano domini e certificati, la differenza tra “cannot find host” e “certificate pending” ti dice se devi correggere i record DNS o semplicemente aspettare SSL dopo che il DNS è visibile.
Molti fallimenti di dominio iniziano con una semplice discrepanza: hai impostato il DNS per un hostname, ma stai testando un altro.
Per prima cosa, annota l'hostname esatto che vuoi mettere online. Il dominio root appare come example.com. Un sottodominio appare come www.example.com o app.example.com. Questi sono voci DNS separate, quindi “www funziona” non significa che il dominio root funzionerà.
Poi, trova il target previsto dalla tua piattaforma di hosting. Alcune piattaforme danno un indirizzo IP (per un record A o AAAA). Altre danno un hostname di destinazione (per un CNAME). Se il tuo host fornisce un valore nella schermata di configurazione del dominio, trattalo come fonte di verità.
Prima di cambiare qualsiasi cosa, cattura ciò che è attualmente impostato. Tienilo semplice:
Conferma anche che stai modificando la zona DNS corretta. È facile aggiornare il dominio sbagliato, l'ambiente sbagliato o l'account provider sbagliato.
Molti problemi derivano dal tipo di record sbagliato per l'hostname che stai cercando di collegare. Inizia separando due casi: il dominio root (example.com) e un sottodominio (www.example.com). Si comportano diversamente in molti provider DNS.
Un record A punta un nome a un indirizzo IPv4. Molte configurazioni usano un record A per il dominio root perché alcuni provider non permettono un CNAME all'apex. Se il tuo host ti dà un IP, un A è di solito corretto.
Un record AAAA è la versione IPv6. Un AAAA rimasto che punta a una destinazione vecchia può creare comportamenti confusi “funziona per me”, perché alcuni visitatori useranno IPv6 mentre altri useranno IPv4. Se il tuo host non ti ha dato un target IPv6, rimuovere un AAAA errato spesso risolve fallimenti incoerenti.
Un CNAME punta un sottodominio a un altro hostname (spesso usato per www). È utile quando l'host vuole che tu punti a un endpoint nominato che può cambiare dietro le quinte.
Un TXT è per verifiche e challenge (inclusi alcuni controlli SSL). Errori comuni includono posizionare il TXT sul nome sbagliato (root vs _acme-challenge vs un sottodominio), aggiungere spazi extra o incollare il valore sbagliato.
Prima di continuare, cerca conflitti. Questi sono quelli che causano più problemi:
Molti casi di “custom domain not working” non riguardano il valore del record. Succedono perché il record è stato aggiunto dal provider sbagliato. Se il tuo dominio usa i nameserver del Provider A, cambiare record nella dashboard del Provider B non farà nulla, anche se i record lì sembrano corretti.
Controlla quali nameserver sta veramente usando il tuo dominio. Di solito puoi vederlo nelle impostazioni del dominio del registrar sotto “Nameservers”. Per un secondo parere, chiedi il DNS direttamente dal tuo computer:
dig NS example.com
I nameserver restituiti da quel comando sono quelli autorevoli.
Un controllo di base:
ns1... e ns2..., quegli stessi valori devono comparire al registrar.Se aggiorni i record sul provider sbagliato, vedrai spesso due dashboard che non corrispondono. Soltanto i nameserver autorevoli contano.
Fai anche attenzione ai ritardi dopo aver cambiato i nameserver al registrar. Durante la finestra di transizione, i risultati possono apparire incoerenti a seconda da dove testi. Se i nameserver sono ancora in fase di cambio, metti in pausa le modifiche dei record finché l'insieme dei nameserver non è stabile, poi continua.
La “propagazione” non è un interruttore unico. È una catena di cache DNS (ISP, operatori mobili, resolver pubblici e i tuoi dispositivi) che si aggiornano a velocità diverse. Per questo motivo il tuo dominio può funzionare per un collega ma non per te.
Il TTL (time to live) dice alle cache per quanto tempo possono tenere una risposta. Se il TTL precedente era 1 ora, alcune persone continueranno a vedere il valore vecchio per quasi un'ora. Abbassare il TTL aiuta solo se lo hai fatto prima di effettuare la modifica.
Per separare i ritardi di cache dagli errori reali, fai alcuni controlli rapidi:
Se il record è sbagliato ovunque controlli (IP sbagliato, www mancante, CNAME vecchio), correggilo. Se i record sembrano corretti nella maggior parte dei posti ma una rete vede ancora il valore vecchio, è di solito un ritardo di cache.
I certificati SSL falliscono di solito per una ragione semplice: il provider del certificato non può convalidare il dominio finché il DNS non punta al posto giusto in modo coerente.
La sequenza normale è semplice:
I blocchi comuni sono facili da perdere di vista. Un A o CNAME sbagliato manda i controlli di validazione al server sbagliato. Un AAAA obsoleto può sovrascrivere il tuo A funzionante per alcuni visitatori, quindi HTTPS fallisce solo per loro. La mancanza di un TXT richiesto può impedire alla piattaforma di emettere un certificato.
Usa i sintomi per separare “ancora in emissione” da “malconfigurato”:
Mentre aspetti, evita di continuare a cambiare i record. Ogni modifica resetta l'orologio e può creare un mondo diviso dove reti diverse vedono risposte diverse. Imposta i record corretti una volta, poi ricontrolla risoluzione e verifiche finché il certificato non è emesso.
Se usi una piattaforma come Koder.ai, il flusso più sicuro è lo stesso: conferma che il DNS punti al target previsto, rimuovi eventuali AAAA errati se esistono, e lascia tempo a SSL dopo che il DNS è stabile.
Una buona risoluzione dei problemi è soprattutto confronto: ciò che vedi vs ciò che ti aspetti. Non fare affidamento su “si apre sul mio telefono”. Usa controlli ripetibili.
Usa uno strumento di lookup DNS (come nslookup o dig) e conferma che il valore restituito corrisponda a quello che intendevi (un IP per A o AAAA, un hostname per CNAME, un token per TXT).
# Apex (root) domain
dig example.com A
dig example.com AAAA
# www subdomain
dig www.example.com CNAME
# TXT (spesso usato per verifica)
dig example.com TXT
Controlla entrambi i nomi che potresti usare: l'apex (example.com) e www (www.example.com). È comune che uno sia corretto mentre l'altro punti ancora a qualcosa di vecchio.
Apri sia http:// che https:// per l'apex e per www. Vuoi un dominio “home” chiaro e un redirect pulito.
www) e reindirizza l'altro verso quello.Se i risultati differiscono per rete, è probabile che tu stia vedendo caching o propagazione. Tieni un piccolo registro: cosa hai cambiato, dove lo hai fatto, l'orario e cosa hai osservato.
La maggior parte dei problemi DNS e SSL non sono misteri. Sono piccoli errori che ti portano a controllare la cosa sbagliata o a cambiare le cose troppo velocemente per ottenere una lettura chiara.
Il più comune spreco di tempo è modificare il DNS in due posti. Succede spesso dopo aver cambiato nameserver: aggiorni i record al registrar, ma il DNS è ospitato altrove (o viceversa). Tutto sembra corretto in una dashboard, eppure nulla cambia pubblicamente.
Un altro errore classico è tentare di mettere un CNAME sul dominio root con un provider che non lo supporta. Potresti aver bisogno di un record A, o di un record ALIAS o ANAME se il tuo provider DNS li offre.
L'IPv6 può anche creare problemi. Lasciare un vecchio record AAAA può mandare alcuni visitatori al server sbagliato mentre altri arrivano correttamente via IPv4.
Fai attenzione ai record “just in case”. Più record A possono comportarsi come un bilanciamento accidentale se un target è sbagliato, specialmente quando punti un dominio personalizzato a un'app ospitata.
Una regola finale: smetti di resettare l'orologio.
Piccoli cambi calmi battono continue modifiche affrettate.
Lanci un'app nuova e configuri sia example.com sia www.example.com. Pochi minuti dopo, www.example.com si apre correttamente, ma il dominio root mostra un errore DNS, carica un sito vecchio o HTTPS resta in sospeso. Questo pattern è comune e di solito ha una causa semplice.
Inizia con la domanda noiosa: stai modificando il DNS nel posto giusto? Se il dominio è registrato presso una società ma il DNS è ospitato altrove, puoi cambiare i record tutto il giorno e nulla succederà. Controlla prima i nameserver, poi apri il pannello DNS del provider a cui quei nameserver puntano.
Poi, confronta i due hostname. www è tipicamente un CNAME. Il dominio root è più complicato: molti provider non permettono un CNAME all'apex, quindi spesso necessita di un record A verso un IP, o di un record ALIAS/ANAME se supportato.
Un percorso decisionale che funziona nella pratica:
example.com non ha record (o punta altrove)? Correggi il record apex.Lo stato finale corretto è noioso: sia example.com che www.example.com portano alla stessa app, uno è canonico (l'altro reindirizza), e HTTPS è valido.
Quando una configurazione dominio fallisce, molte soluzioni derivano da pochi controlli rapidi. Esegui questi prima di cambiare altro.
Dopo che il DNS è chiaramente corretto, controlla SSL. Molte piattaforme emettono il certificato solo dopo che riescono a risolvere il dominio verso il target giusto in modo coerente. Se controlli troppo presto, puoi scambiare un ritardo normale per un errore reale.
Se stai aggiungendo un dominio personalizzato a un'app distribuita su Koder.ai, considera la schermata di configurazione dominio dell'app come riferimento per il target DNS atteso, poi ricontrolla lo stato solo dopo che il DNS ha avuto tempo per propagarsi.
Il modo più veloce per evitare di ripetere errori DNS e SSL è tenere una breve “nota di setup dominio” per ogni progetto. È un runbook riutilizzabile che puoi copiare la prossima volta che lanci.
Tienilo nei documenti di progetto e compilalo prima di toccare il DNS:
Durante il lancio, assegna una persona come proprietario del DNS. I problemi DNS avvengono più spesso quando due persone “sistemano” cose diverse contemporaneamente (per esempio, una cambia nameserver mentre un'altra modifica i record).
Sul lato hosting, pianifica inversioni sicure. Se la tua piattaforma supporta snapshot o rollback, fai uno snapshot prima di cambiare il routing così puoi tornare rapidamente all'ultimo stato funzionante. Se costruisci su Koder.ai, puoi usare Planning Mode per annotare i passaggi del dominio che farai, applicarli in ordine e ripristinare se un cambiamento rompe la produzione.
Se hai confermato che il DNS è corretto e vedi ancora errori, smetti di indovinare e scala con prove:
Quando fai escalation, includi l'hostname, i record previsti, i risultati dei resolver attuali e i timestamp. Questo trasforma un lungo scambio in una soluzione rapida.
Di solito significa che uno degli anelli della catena è errato: il DNS non risolve, il DNS risolve verso il posto sbagliato, il server/host non riconosce il tuo hostname, oppure HTTPS/SSL non è ancora stato emesso. Inizia annotando l'errore esatto che vedi e l'hostname che hai digitato (apex vs www).
example.com (l'apex) e www.example.com sono hostname separati con record DNS separati. È comune avere un CNAME corretto per www mentre l'apex non ha un record A, ha un record A sbagliato o richiede una configurazione non supportata dal tuo provider DNS.
Controlla i nameserver del dominio presso il registrar e confrontali con il provider DNS che stai modificando. Solo il provider elencato nei nameserver attivi è autorevole; modificare i record in altri posti non cambierà ciò che vede Internet pubblico.
Usa un record A quando l'host ti dà un indirizzo IPv4, un record AAAA solo se l'host ti dà un indirizzo IPv6, e un CNAME quando l'host ti dà un altro hostname (molto comune per www). I record TXT servono per verifiche e challenge e devono essere creati esattamente sul nome indicato dal tuo host.
Un record AAAA obsoleto o sbagliato può mandare alcuni visitatori via IPv6 a un server vecchio mentre altri vanno correttamente via IPv4, creando confusione del tipo “a me funziona”. Se il tuo host non ha fornito un target IPv6, rimuovere un AAAA errato è spesso la soluzione più semplice.
Di solito hai configurato solo un hostname sul lato hosting (solo apex o solo www), oppure ci sono regole di redirect concorrenti che rimbalzano tra HTTP e HTTPS o tra apex e www. Scegli un hostname canonico, configura entrambi gli hostname e assicurati che esista solo un percorso di redirect pulito.
Sì. L'attesa è la mossa giusta solo dopo aver verificato chiaramente che il DNS punti al target corretto da più posizioni. L'emissione del certificato SSL di solito non si completa finché il dominio non risolve in modo coerente verso la destinazione prevista; cambiare il DNS ripetutamente può continuare a resettare il processo.
TTL è il tempo per cui i resolver memorizzano una risposta, quindi anche dopo aver corretto un record, alcune reti potrebbero continuare a fornire il valore vecchio finché non scade il TTL. Testa da due reti diverse (per esempio Wi‑Fi e dati mobili) e evita di fare nuovi cambiamenti DNS ogni pochi minuti, così puoi osservare la propagazione.
Usa un controllo ripetibile come dig o nslookup per confermare che le risposte A/AAAA/CNAME/TXT corrispondano al target atteso, e poi prova sia http:// che https:// per apex e www. Se una rete mostra risposte DNS diverse da un'altra, trattala come caching; se tutte le reti mostrano risposte sbagliate, trattalo come un errore di configurazione.
Su Koder.ai, considera la schermata di impostazione del dominio dell'app come fonte di verità per il target DNS atteso, quindi fai corrispondere il DNS esattamente a quello dal provider DNS autorevole. Dopo aver cambiato il DNS, concedi tempo per stabilizzarsi prima di ricontrollare SSL e usa snapshot/rollback se modifichi il routing su un progetto live per tornare rapidamente a uno stato noto e funzionante.