Utilisez cette checklist de dépannage de domaine personnalisé pour diagnostiquer les erreurs d’enregistrements DNS, les délais de propagation et le timing du SSL, avec des étapes de vérification simples.
« Domaine personnalisé non fonctionnel » est une expression générique pour plusieurs types de pannes. Votre navigateur affiche le symptôme, pas la cause. Avant de modifier quoi que ce soit, décrivez précisément ce que vous voyez.
Les symptômes typiques incluent :
La plupart du temps, une seule chose est en défaut :
Avant de dépanner, assurez‑vous d’avoir accès à deux endroits : là où vous éditez les enregistrements DNS (registrar ou fournisseur DNS) et là où vous rattachez le domaine côté hébergement. Par exemple, si vous connectez une application déployée sur Koder.ai à un domaine personnalisé, vous avez besoin d’un accès DNS pour le domaine et des paramètres de domaine dans la configuration d’hébergement ou de déploiement de l’app.
Certaines corrections sont instantanées (comme corriger une faute de frappe). D’autres prennent du temps. Les changements DNS peuvent mettre un moment à apparaître, et le SSL ne se complétera généralement pas tant que le DNS ne pointe pas correctement et que le domaine est accessible. L’objectif est d’arrêter de deviner et de confirmer chaque couche dans l’ordre.
La plupart des problèmes de domaine se résument à un décalage entre (1) le nom d’hôte que vous testez, (2) l’endroit où le DNS est géré, et (3) la cible réelle de l’enregistrement. Une fois ces trois éléments alignés, le SSL est généralement la dernière étape.
Les domaines ont deux formes courantes : le domaine racine (example.com, aussi appelé apex) et les sous‑domaines (www.example.com, app.example.com). Ils sont liés mais peuvent avoir des enregistrements DNS différents. Il est donc normal que www fonctionne tandis que l’apex échoue, ou l’inverse.
Les nameservers déterminent qui gère votre zone DNS. Si vous avez acheté un domaine chez une société mais que les nameservers pointent vers une autre, vous devez éditer le DNS là où pointent les nameservers. Beaucoup de situations « je l’ai mis à jour mais rien n’a changé » viennent du fait que les enregistrements ont été modifiés dans le mauvais tableau de bord.
Voici ce que font les principaux types d’enregistrements :
www)Le TTL est le « temps de mise en cache ». Un TTL bas signifie que les caches se rafraîchissent plus vite. Un TTL élevé signifie que vous pouvez devoir attendre plus longtemps, même après avoir corrigé l’enregistrement. Voir l’ancienne valeur pendant un moment peut être normal.
Quand un domaine personnalisé échoue, vous pouvez généralement le classer dans quatre catégories : le DNS ne résout pas, le DNS résout vers le mauvais endroit, le SSL n’est pas prêt, ou cela échoue seulement pour certains utilisateurs à cause du cache.
Suivez cet arbre de décision :
www fonctionne mais le domaine racine non (ou l’inverse), vous avez probablement configuré un seul nom d’hôte, ou des règles de redirection contradictoires.Allez plus vite en notant l’exact nom d’hôte en échec (apex vs www) et le message d’erreur exact. Sur les plateformes qui automatisent domaines et certificats, la différence entre « hôte introuvable » et « certificat en attente » vous indique s’il faut corriger les enregistrements DNS ou simplement attendre le SSL après que le DNS soit visible.
Beaucoup d’échecs de domaine commencent par une simple erreur d’alignement : vous avez configuré le DNS pour un nom d’hôte, mais vous testez un autre.
D’abord, notez précisément le nom d’hôte que vous voulez mettre en ligne. Le domaine racine ressemble à example.com. Un sous‑domaine ressemble à www.example.com ou app.example.com. Ce sont des entrées DNS séparées, donc « www fonctionne » ne signifie pas que le domaine racine fonctionnera.
Ensuite, trouvez la cible attendue fournie par votre hébergeur. Certaines plateformes fournissent une adresse IP (pour un enregistrement A ou AAAA). D’autres donnent un nom d’hôte cible (pour un CNAME). Si votre hébergeur fournit une valeur dans un écran de configuration de domaine, considérez‑la comme la source de vérité.
Avant de modifier quoi que ce soit, capturez ce qui est actuellement configuré. Restez simple :
Confirmez aussi que vous éditez la bonne zone DNS. Il est facile de mettre à jour le mauvais domaine, le mauvais environnement ou le mauvais compte fournisseur.
Beaucoup de problèmes viennent simplement d’un mauvais type d’enregistrement pour le nom d’hôte que vous essayez de connecter. Commencez par séparer deux cas : le domaine racine (example.com) et un sous‑domaine (www.example.com). Ils se comportent différemment chez de nombreux fournisseurs DNS.
Un enregistrement A pointe un nom vers une adresse IPv4. De nombreuses configurations utilisent un A pour le domaine racine car certains fournisseurs n’autorisent pas un CNAME à l’apex. Si votre hôte vous donne une IP, un A est généralement correct.
Un AAAA est la version IPv6. Un AAAA résiduel pointant vers une ancienne destination peut créer un comportement confus « ça marche pour moi », car certains visiteurs utiliseront IPv6 tandis que d’autres utiliseront IPv4. Si votre hébergeur n’a pas fourni de cible IPv6, supprimer un AAAA incorrect corrige souvent des échecs incohérents.
Un CNAME pointe un sous‑domaine vers un autre nom d’hôte (souvent utilisé pour www). Il est utile quand l’hébergeur veut que vous cibliez un endpoint nommé qui peut changer en arrière‑plan.
Un TXT sert à la vérification et aux challenges (y compris certains contrôles SSL). Les erreurs courantes incluent le placement du TXT sur le mauvais nom (apex vs _acme-challenge vs un sous‑domaine), des espaces en trop ou une valeur collée incorrecte.
Avant d’avancer, recherchez les conflits. Ce sont les plus problématiques :
www ou le domaine racineBeaucoup de cas « domaine personnalisé non fonctionnel » ne concernent pas la valeur de l’enregistrement. Ils surviennent parce que l’enregistrement a été ajouté chez le mauvais fournisseur. Si votre domaine utilise les nameservers du Fournisseur A, changer des enregistrements dans le tableau de bord du Fournisseur B ne servira à rien, même si les enregistrements y paraissent corrects.
Vérifiez quels nameservers votre domaine utilise réellement. Vous pouvez généralement le voir dans les paramètres du registrar sous « Nameservers ». Pour un second avis, interrogez le DNS depuis votre ordinateur :
dig NS example.com
Les nameservers renvoyés par cette commande sont les autoritaires.
Un contrôle rapide :
ns1... et ns2..., ces valeurs exactes doivent apparaître chez le registrar.Si vous mettez à jour des enregistrements chez le mauvais fournisseur, vous verrez souvent deux tableaux de bord qui ne correspondent pas. Seuls les nameservers autoritaires comptent.
Faites aussi attention aux délais après un changement de nameservers chez le registrar. Pendant la fenêtre de transition, les résultats peuvent paraître incohérents selon l’endroit d’où vous testez. Si les nameservers changent encore, suspendrez les modifications d’enregistrement jusqu’à ce que l’ensemble soit stable, puis continuez.
La « propagation » n’est pas un interrupteur unique. C’est une chaîne de caches DNS (FAI, opérateur mobile, résolveurs publics et vos propres appareils) qui se mettent à jour à des vitesses différentes. C’est pour ça que votre domaine peut fonctionner pour un collègue mais pas pour vous.
Le TTL (time to live) indique combien de temps les caches peuvent garder une réponse. Si l’ancien TTL était d’une heure, certaines personnes verront l’ancienne valeur pendant près d’une heure. Baisser le TTL aide seulement si vous l’avez fait avant de faire le changement.
Pour séparer les délais de cache des erreurs réelles, faites quelques vérifications rapides :
Si l’enregistrement est erroné partout où vous vérifiez (mauvaise IP, www manquant, ancien CNAME), corrigez‑le. Si les enregistrements semblent corrects dans la plupart des endroits mais qu’un réseau montre encore l’ancienne valeur, c’est généralement un délai de cache.
Les certificats SSL échouent généralement pour une raison basique : le fournisseur de certificat ne peut pas valider le domaine tant que le DNS ne pointe pas au bon endroit de façon cohérente.
La séquence normale est simple :
Les blocages courants sont faciles à manquer. Une mauvaise cible A ou CNAME envoie les contrôles de validation vers le mauvais serveur. Un AAAA obsolète peut remplacer votre A fonctionnel pour certains visiteurs, provoquant des échecs HTTPS seulement pour eux. L’absence d’un TXT requis peut empêcher l’émission.
Utilisez les symptômes pour distinguer « encore en émission » de « mal configuré » :
Pendant que vous attendez, n’alternez pas sans cesse les enregistrements. Chaque changement remet le compteur à zéro et peut créer un monde divisé où différents réseaux voient des réponses différentes. Configurez correctement une fois, puis revérifiez la résolution et la validation jusqu’à ce que le certificat soit émis.
Si vous utilisez une plateforme comme Koder.ai, le flux le plus sûr est le même : confirmez que le DNS pointe vers la cible attendue, supprimez les AAAA incorrects s’ils existent, et laissez le SSL le temps d’être émis après la stabilisation du DNS.
Un bon dépannage consiste surtout à comparer : ce que vous voyez vs ce que vous attendez. Ne vous fiez pas à « ça marche sur mon téléphone ». Utilisez des contrôles reproductibles.
Utilisez un outil de recherche DNS (comme nslookup ou dig) et confirmez que la valeur retournée correspond à ce que vous vouliez (une IP pour A ou AAAA, un nom d’hôte pour CNAME, un token pour TXT).
# Apex (domaine racine)
dig example.com A
dig example.com AAAA
# Sous‑domaine www
dig www.example.com CNAME
# TXT (souvent utilisé pour la vérification)
dig example.com TXT
Vérifiez les deux noms que vous pourriez utiliser : l’apex (example.com) et www (www.example.com). Il est courant que l’un soit correct tandis que l’autre pointe toujours vers l’ancien emplacement.
Ouvrez http:// et https:// pour l’apex et pour www. Vous voulez un domaine « maison » clair et une redirection propre.
www) et redirigez l’autre vers celui‑ci.Si les résultats diffèrent selon le réseau, vous observez probablement de la propagation ou du cache. Tenez un petit journal : ce que vous avez changé, où vous l’avez changé, l’heure et ce que vous avez observé.
La plupart des problèmes DNS et SSL ne sont pas des mystères. Ce sont de petites erreurs qui vous font vérifier la mauvaise chose, ou modifier les choses trop vite pour obtenir une lecture claire.
La perte de temps la plus courante est d’éditer le DNS à deux endroits. Cela arrive souvent après un changement de nameservers : vous mettez à jour des enregistrements chez le registrar, mais le DNS est en fait hébergé ailleurs (ou l’inverse). Tout a l’air correct dans un tableau de bord, mais rien ne change publiquement.
Une autre erreur classique est d’essayer de mettre un CNAME sur le domaine racine chez un fournisseur qui ne le permet pas. Vous devrez peut‑être utiliser un enregistrement A, ou un enregistrement de type ALIAS/ANAME si votre fournisseur le propose.
L’IPv6 peut aussi poser problème. Laisser un ancien AAAA peut envoyer certains visiteurs vers le mauvais serveur tandis que d’autres atteignent correctement l’IPv4.
Faites attention aux enregistrements « au cas où ». Plusieurs enregistrements A peuvent se comporter comme un équilibrage de charge accidentel si une cible est erronée, surtout quand vous pointez un domaine personnalisé vers une application hébergée.
Une règle finale : arrêtez de remettre le compteur à zéro.
De petites modifications calmes valent mieux que des bidouillages constants.
www fonctionne mais le domaine racine ne fonctionne pasVous lancez une nouvelle app et configurez example.com et www.example.com. Quelques minutes plus tard, www.example.com charge correctement, mais le domaine racine affiche une erreur DNS, charge un ancien site, ou le HTTPS reste en attente. Ce schéma est courant et a généralement une cause simple.
Commencez par la question ennuyeuse : éditez‑vous le DNS au bon endroit ? Si votre domaine est enregistré chez une société mais que le DNS est hébergé ailleurs, vous pouvez modifier des enregistrements toute la journée sans résultat. Vérifiez d’abord les nameservers, puis ouvrez le panneau DNS du fournisseur vers lequel ces nameservers pointent.
Comparez ensuite les deux noms d’hôtes. www est typiquement un CNAME. Le domaine racine est plus délicat : beaucoup de fournisseurs n’autorisent pas un CNAME à l’apex, il nécessite souvent un enregistrement A vers une IP, ou un enregistrement ALIAS/ANAME si disponible.
Un chemin de décision utile :
example.com n’a pas d’enregistrement (ou pointe ailleurs) ? Corrigez l’apex.L’état final attendu est ennuyeux : example.com et www.example.com pointent vers la même application, l’un est canonique (l’autre redirige), et HTTPS est valide.
Quand une configuration de domaine échoue, la plupart des corrections viennent de quelques vérifications rapides. Faites‑les avant de changer autre chose.
Après que le DNS soit clairement correct, vérifiez ensuite le SSL. Beaucoup de plateformes n’émettent le certificat que lorsque votre domaine se résout de façon cohérente vers la bonne cible. Si vous vérifiez trop tôt, vous pouvez confondre un délai normal avec une erreur réelle.
Si vous ajoutez un domaine personnalisé à une application déployée sur Koder.ai, considérez l’écran de configuration du domaine comme la référence pour la cible attendue, puis revérifiez le statut uniquement après que le DNS ait eu le temps de se propager.
La manière la plus rapide d’éviter de répéter les erreurs DNS et SSL est de garder une courte « note de configuration de domaine » pour chaque projet. C’est un runbook réutilisable que vous pouvez copier la prochaine fois que vous lancez quelque chose.
Conservez‑le dans la documentation du projet et remplissez‑le avant de toucher au DNS :
Pendant le lancement, désignez une personne responsable du DNS. Le DNS casse le plus souvent quand deux personnes « corrigent » des choses différentes en même temps (par exemple l’un change les nameservers pendant que l’autre édite des enregistrements).
Côté hébergement, prévoyez des retours en arrière sûrs. Si votre plateforme prend en charge des snapshots ou rollback, faites‑en un avant de modifier le routage pour pouvoir revenir rapidement à l’état précédemment fonctionnel. Si vous construisez sur Koder.ai, vous pouvez utiliser Planning Mode pour écrire les étapes du domaine, les appliquer dans l’ordre et revenir en arrière si un changement casse la production.
Si vous avez confirmé que le DNS est correct et que vous voyez encore des échecs, arrêtez de deviner et escaladez avec des preuves :
Quand vous escaladez, incluez le nom d’hôte, les enregistrements attendus, les résultats de résolveur actuels et des horodatages. Cela transforme des allers‑retours lents en une résolution rapide.
Cela signifie généralement qu’un maillon de la chaîne est défaillant : le DNS ne résout pas, le DNS pointe vers la mauvaise destination, le serveur/hébergeur ne reconnaît pas votre nom d’hôte, ou le certificat HTTPS/SSL n’a pas encore été émis. Commencez par noter exactement l’erreur affichée et le nom d’hôte tapé (apex vs www).
Parce que example.com (l’apex) et www.example.com sont des noms d’hôtes distincts avec des enregistrements DNS séparés. Il est courant d’avoir un CNAME correct pour www tandis que l’apex n’a pas d’enregistrement A, a un A erroné, ou nécessite un type d’enregistrement que votre fournisseur DNS ne supporte pas.
Vérifiez les nameservers du domaine chez votre registrar et comparez-les au fournisseur DNS que vous modifiez. Seul le fournisseur indiqué dans les nameservers actifs est autoritaire ; éditer ailleurs ne changera rien publiquement.
Utilisez un enregistrement A si votre hébergeur vous fournit une adresse IPv4, un AAAA uniquement si on vous donne une adresse IPv6, et un CNAME quand l’hébergeur vous demande de pointer vers un autre nom d’hôte (très courant pour www). Les enregistrements TXT servent à la vérification et aux challenges et doivent être créés sur le nom exact demandé.
Oui : un enregistrement AAAA obsolète ou erroné peut envoyer certains visiteurs vers un ancien serveur via IPv6 tandis que d’autres vont vers l’IPv4 correcte, créant une confusion « ça marche pour moi ». Si votre hébergeur n’a pas fourni de cible IPv6, supprimer un AAAA incorrect règle souvent le problème.
Le plus souvent, vous avez configuré un seul nom d’hôte côté hébergement (seulement l’apex ou seulement www), ou des règles de redirection qui se contre‑disent et renvoient la requête en boucle entre HTTP/HTTPS ou entre apex et www. Choisissez un nom canonique, configurez les deux noms et assurez‑vous d’avoir un seul chemin de redirection propre.
Oui. L’émission d’un certificat échoue souvent parce que le fournisseur de certificat ne peut pas valider le domaine tant que le DNS ne pointe pas de manière cohérente vers la bonne destination. Une fois le DNS correct, il faut attendre que la résolution soit stable partout avant que le certificat soit émis.
Le TTL indique combien de temps les résolveurs gardent une réponse en cache, donc même après correction d’un enregistrement, certains réseaux continueront d’afficher l’ancienne valeur jusqu’à l’expiration du TTL. Testez depuis deux réseaux différents (par ex. Wi‑Fi et données mobiles) et évitez de modifier le DNS toutes les quelques minutes pour pouvoir observer la propagation.
Utilisez une vérification reproductible comme dig ou nslookup pour confirmer que les réponses A/AAAA/CNAME/TXT correspondent à la cible attendue, puis testez http:// et https:// pour l’apex et www. Si un réseau renvoie des réponses DNS différentes d’un autre, c’est probablement du cache ; si tous renvoient de mauvaises réponses, c’est une erreur de configuration.
Sur Koder.ai, considérez l’écran de configuration de domaine de l’application comme la source de vérité pour la cible DNS attendue, faites correspondre le DNS exactement chez le fournisseur autoritaire, puis laissez le temps au DNS de se propager avant de revérifier le SSL. Utilisez les snapshots/rollback si vous modifiez le routage en production pour revenir rapidement à un état connu fonctionnel.