Erreurs de CNAME
Si vous publiez à partir d'un flux de travail GitHub Actions personnalisé, tout fichier CNAME est ignoré et n'est pas nécessaire.
Si vous publiez à partir d’une branche, les domaines personnalisés sont stockés dans un fichier CNAME à la racine de votre source de publication. Vous pouvez ajouter ou mettre à jour ce fichier via vos paramètres de dépôt, ou bien manuellement. Pour plus d’informations, consultez « Gestion d’un domaine personnalisé pour votre site GitHub Pages ».
Pour que votre site soit rendu sur le domaine approprié, vérifiez que votre fichier CNAME existe toujours dans le dépôt. Par exemple, de nombreux générateurs de sites statiques forcent l’envoi (push) vers votre dépôt, ce qui peut remplacer le fichier CNAME qui a été ajouté à votre dépôt quand vous avez configuré votre domaine personnalisé. Si vous générez votre site localement et que vous poussez les fichiers générés vers GitHub Enterprise Cloud, veillez à d’abord tirer (pull) le commit qui a ajouté le fichier CNAME à votre dépôt local, de sorte que le fichier soit inclus dans la build.
Vérifiez ensuite que le fichier CNAME est correctement mis en forme.
- Le nom du fichier CNAME doit être en majuscules.
- Le fichier CNAME ne peut contenir qu’un seul domaine. Pour faire pointer plusieurs domaines vers votre site, vous devez configurer une redirection via votre fournisseur DNS.
- Le fichier CNAME doit contenir seulement le nom de domaine. Par exemple,
www.example.com,blog.example.comouexample.com. - Le nom de domaine doit être unique parmi tous les sites GitHub Pages. Par exemple, si le fichier CNAME d’un autre dépôt contient
example.com, vous ne pouvez pas utiliserexample.comdans le fichier CNAME pour votre dépôt.
Configuration DNS incorrecte
Si vous rencontrez des problèmes pour faire pointer le domaine par défaut pour votre site vers votre domaine personnalisé, contactez votre fournisseur DNS.
Vous pouvez aussi utiliser une des méthodes suivantes pour tester si les enregistrements DNS de votre domaine personnalisé sont correctement configurés :
- Un outil CLI comme
dig. Pour plus d’informations, consultez « Gestion d’un domaine personnalisé pour votre site GitHub Pages ». - Un outil de recherche DNS en ligne.
Noms de domaine personnalisés qui ne sont pas pris en charge
Si votre domaine personnalisé n’est pas pris en charge, il peut être nécessaire de changer votre domaine pour un domaine pris en charge. Vous pouvez aussi contacter votre fournisseur DNS pour voir s’il offre des services de transfert pour les noms de domaine.
Vérifiez que votre site :
-
N’utilise pas plusieurs domaines apex. Par exemple,
example.cometanotherexample.com. -
N’utilise pas plusieurs sous-domaines
www. Par exemple,www.example.cometwww.anotherexample.com. -
N’utilise pas à la fois un domaine apex et un sous-domaine personnalisé. Par exemple,
example.cometdocs.example.com.La seule exception est le sous-domaine
www. S’il est configuré correctement, le sous-domainewwwest redirigé automatiquement vers le domaine apex. Pour plus d’informations, consultez « Gestion d’un domaine personnalisé pour votre site GitHub Pages ».
Avertissement : nous vous recommandons vivement de ne pas utiliser d’enregistrements DNS génériques, tels que *.example.com. Ces enregistrements vous exposent à un risque immédiat de prise de contrôle de domaine, même si vous vérifiez le domaine. Par exemple, si vous vérifiez example.com, vous empêchez un tiers d’utiliser a.example.com, mais cette personne peut toujours prendre le contrôle de b.a.example.com (couvert par l’enregistrement DNS générique). Pour plus d’informations, consultez « Vérification de votre domaine personnalisé pour GitHub Pages ».
Pour obtenir la liste des domaines personnalisés pris en charge, consultez « À propos des domaines personnalisés et des pages GitHub ».
Erreurs HTTPS
Les sites GitHub Pages en utilisant des domaines personnalisés correctement configurés avec des enregistrements DNS CNAME, ALIAS, ANAME ou A sont accessibles via HTTPS. Pour plus d’informations, consultez « Sécurisation de votre site GitHub Pages avec HTTPS ».
Cela peut prendre jusqu’à une heure pour que votre site devienne disponible via HTTPS après avoir configuré votre domaine personnalisé. Après avoir mis à jour les paramètres DNS existants, il peut être nécessaire de supprimer et de réajouter votre domaine personnalisé au dépôt de votre site pour déclencher le processus d’activation du protocole HTTPS. Pour plus d’informations, consultez « Gestion d’un domaine personnalisé pour votre site GitHub Pages ».
Si vous utilisez des enregistrements d’autorisation d’autorité de certification (CAA), au moins un enregistrement CAA doit exister avec la valeur letsencrypt.org pour que votre site soit accessible via HTTPS. Pour plus d’informations, consultez « Autorisation d’autorité de certification (CAA) » dans la documentation Let’s Encrypt.
Mise en forme d’URL sur Linux
Si l’URL de votre site contient un nom d’utilisateur ou un nom d’organisation qui commence ou se termine par un tiret, ou contient des tirets consécutifs, les personnes qui naviguent avec Linux vont recevoir une erreur du serveur quand elles tentent de visiter votre site. Pour résoudre ce problème, modifiez votre nom d’utilisateur GitHub Enterprise Cloud en y supprimant les caractères non alphanumériques. Pour plus d’informations, consultez « Modification de votre nom d’utilisateur GitHub ».
Cache du navigateur
Si vous avez récemment modifié ou supprimé votre domaine personnalisé et que vous ne pouvez pas accéder à la nouvelle URL dans votre navigateur, il peut être nécessaire d’effacer le cache de votre navigateur pour atteindre la nouvelle URL. Pour plus d’informations sur l’effacement de votre cache, consultez la documentation de votre navigateur.
Nom de domaine pris
Si vous essayez d’utiliser un domaine personnalisé et qu’il indique que le domaine est déjà utilisé, vous pouvez rendre le domaine disponible pour votre propre utilisation en le vérifiant d’abord. Pour plus d’informations, consultez « Vérification de votre domaine personnalisé pour GitHub Pages ».