Erros de CNAME
Se você estiver publicando de um fluxo de trabalho personalizado do GitHub Actions, qualquer arquivo CNAME será ignorado e não será necessário.
Se você estiver publicando de um branch, os domínios personalizados serão armazenados em um arquivo CNAME na raiz da fonte de publicação. que pode ser adicionado ou atualizado manualmente ou por meio das configurações do repositório. Para saber mais, confira Gerenciar um domínio personalizado do seu site do GitHub Pages.
Para que o seu site seja renderizado no domínio correto, verifique se o arquivo CNAME ainda existe no repositório. Por exemplo, muitos geradores de site estáticos forçam o push para o repositório, o que pode substituir o arquivo CNAME que foi adicionado ao repositório quando você configurou o domínio personalizado. Se você compilar o site localmente e enviar arquivos gerados por push para o GitHub Enterprise Cloud, efetue pull do commit que adicionou o arquivo CNAME para o repositório local primeiro, para que o arquivo seja incluído no build.
Em seguida, verifique se o arquivo CNAME está formatado corretamente.
- O nome do arquivo CNAME precisa estar todo em maiúsculas.
- O arquivo CNAME pode conter apenas um domínio. Para apontar vários domínios para o site, é preciso configurar um redirecionamento por meio do provedor DNS.
- O arquivo CNAME precisa conter apenas o nome de domínio. Por exemplo,
www.example.com
,blog.example.com
ouexample.com
. - O nome de domínio precisa ser único em todos os sites de GitHub Pages. Por exemplo, se o arquivo CNAME de outro repositório contiver
example.com
, não será possível usarexample.com
no arquivo CNAME para o repositório.
Configuração incorreta do DNS
Se você tiver problemas para apontar o domínio padrão do site para o domínio personalizado, entre em contato com seu provedor DNS.
Você também pode usar um dos seguintes métodos para testar se os registros DNS do seu domínio personalizado estão configurados corretamente:
- Uma ferramenta de CLI, como
dig
. Para saber mais, confira Gerenciar um domínio personalizado do seu site do GitHub Pages. - Uma ferramenta de pesquisa de DNS on-line.
Nomes de domínios personalizados que não são compatíveis
Se o seu domínio personalizado não for compatível, talvez você precise alterá-lo para um que tenha suporte. Você também pode entrar em contato com seu provedor DNS para ver se ele oferece serviços de encaminhamento para nomes de domínio.
Verifique se o seu site não:
-
Usa mais de um domínio apex. Por exemplo,
example.com
eanotherexample.com
. -
Use mais de um subdomínio
www
. Por exemplo,www.example.com
ewww.anotherexample.com
. -
Usa um domínio apex e um subdomínio personalizado. Por exemplo,
example.com
edocs.example.com
.A única exceção é o subdomínio
www
. Se ele estiver configurado corretamente, o subdomíniowww
será redirecionado automaticamente para o domínio apex. Para saber mais, confira Gerenciar um domínio personalizado do seu site do GitHub Pages.
Warning
É altamente recomendável não usar registros DNS curingas, como *.example.com
. Esses registros colocam você em risco imediato de aquisições de domínio, mesmo se você verificar o domínio. Por exemplo, verificar example.com
impedirá que outra pessoa use a.example.com
, mas ela ainda poderá usar b.a.example.com
(que é coberto pelo registro DNS curinga). Para obter mais informações, confira "Verificando seu domínio personalizado para o GitHub Pages".
Para obter uma lista de domínios personalizados com suporte, confira Sobre domínios personalizados e GitHub Pages.
Erros de HTTPS
Os sites do GitHub Pages que usam do domínios personalizados e que estão configurados corretamente com registros DNS CNAME
, ALIAS
, ANAME
ou A
podem ser acessados por HTTPS. Para saber mais, confira Proteger o site GitHub Pages com HTTPS.
Depois que você configurar seu domínio personalizado, pode levar até uma hora para o seu site ser disponibilizado por HTTPS. Após a atualização das configurações DNS existentes, talvez seja necessário remover o domínio personalizado e tornar a adicioná-lo ao repositório do site para acionar o processo de habilitação do HTTPS. Para saber mais, confira Gerenciar um domínio personalizado do seu site do GitHub Pages.
Se você estiver usando registros de CAA (Autorização da Autoridade de Certificação), pelo menos, um registro CAA precisará existir com o valor letsencrypt.org
para que o seu site seja acessível por HTTPS. Para obter mais informações, confira CAA (Autorização da Autoridade de Certificação) na documentação do Let's Encrypt.
Formatação de URL no Linux
Se a URL para o seu site incluir um nome de usuário ou de organização que começa ou termina com um traço ou contiver traços consecutivos, as pessoas que navegam com Linux receberão um erro de servidor quando tentarem visitar o site. Para corrigir isso, remova caracteres não alfanuméricos do seu nome de usuário do GitHub Enterprise Cloud. Para saber mais, confira Alterar seu nome de usuário do GitHub.
Cache do navegador
Se você tiver alterado ou removido recentemente seu domínio personalizado e não conseguir acessar a nova URL no navegador, talvez precise limpar o cache do navegador para alcançar a nova URL. Para obter mais informações sobre limpeza do cache, consulte a documentação do navegador.
Nome de domínio usado
Se estiver tentando usar um domínio personalizado e ele disser que o domínio já está em uso, você poderá disponibilizar o domínio para seu próprio uso verificando-o primeiro. Para saber mais, confira Verificando seu domínio personalizado para o GitHub Pages.