Domínio Personalizado & TLS

Apontar seu site para seu próprio domínio, e conseguir certificados HTTPS que se renovam sozinhos (ou que você gerencia intencionalmente), é uma sequência curta: aponte o DNS, escolha a grafia canônica, configure o proxy, verifique o TLS. Este guia o percorre com as configurações e checagens que o software espera.

Passo 1: Aponte o domínio

Adicione um registro DNS A/AAAA para seu domínio público (e um separado para o admin, por exemplo admin.example.com, se você usa o padrão dos exemplos), apontando para seu servidor.
Para sites multilíngues, decida cedo se cada idioma ganha seu próprio subdomínio ou vive sob um único host (ambos os layouts são embarcados; veja Reverse Proxy). O modo subdomínio significa endereços no estilo es.example.com para cada idioma.

O DNS está inteiramente fora do software: nenhum provedor é assumido.

Passo 2: Defina sua URL canônica

Em Settings, defina a URL do Site: a grafia exata que você quer como o único endereço verdadeiro do site, incluindo se você usa www.

Por que essa única configuração importa:

Cada URL de página canônica, cada entrada de sitemap, cada endereço de feed é gerado a partir dela.
O build escreve uma regra de redirecionamento permanente (301) que manda a outra grafia do seu host (a que você não escolheu) para a que escolheu, de modo que mecanismos de busca e visitantes aterrissem em um único endereço.
No modo de idioma por subdomínio, as URLs de cada idioma são reescritas automaticamente para seu próprio subdomínio com base nesta configuração.

Acerte isso primeiro; ela decide o que cada endereço gerado será.

Passo 3: Configure o proxy e os certificados

Caddy (recomendado): ponha seus domínios na config de exemplo. É isso: o Caddy requisita e renova certificados Let’s Encrypt automaticamente assim que seu DNS aponta para o servidor e as portas 80/443 estão acessíveis. Nenhuma linha de certificado a gerenciar.
nginx: levante o vhost HTTP a partir do exemplo embarcado, então rode o Certbot para seu domínio; ele injeta o listener HTTPS e as referências de certificado por você.
Mantenha o CMS ligado ao loopback (por exemplo 127.0.0.1:3001) e deixe o proxy fazer o TLS. Verifique: após a primeira inicialização, curl -I https://your.admin.domain deve responder limpo.
Não esqueça as pequenas regras de proxy: /forms/ se seu site tem formulários, /documents/ se você usa documentos, e a lista de honeypot (tudo embarcado nos exemplos).

Passo 4: Verifique

Cheque antes de dar por encerrado:

A página pública por HTTPS carrega sem avisos de conteúdo misto (o CMS e o proxy enviam headers de cache/segurança corretos).
O domínio de admin também responde por HTTPS.
A grafia de host não canônica redireciona para a escolhida (ou a sua regra de host no nível do Caddyfile o faz; veja abaixo).
A URL de cada idioma responde em seu host/subdomínio esperado.

Detalhes que importam

A imposição canônica é mais forte em hosts que leem o arquivo de redirecionamentos em formato Netlify: o build escreve uma regra 301 de nível de host no _redirects. Em deployments Caddy, o arquivo de regras equivalente não a inclui, então adicione o redirecionamento de host no seu Caddyfile quando precisar do redirecionamento rígido (as tags canônicas por página vêm do CMS em todo host).
HSTS é emitido pelo CMS para o tráfego de admin (um ano, incluindo subdomínios) e espelhado no exemplo nginx embarcado; uma vez que os navegadores o viram, o TLS precisa permanecer presente, então certifique-se de que as renovações funcionam antes de depender dele.
Mapeamento de portas: cada instância mantém uma porta única (3001, 3002, …) atrás do proxy; o proxy roteia cada domínio para sua instância. Se você adotar o Manager, anexa os domínios lá e ele regenera/recarrega a config do proxy por você; o daemon em si nunca sai do loopback.
Hosts extremamente air-gapped: há um modo documentado sem DNS e sem certificados, com HTTP puro numa porta local, protegido por VPN/firewall em vez de TLS. É a válvula de escape deliberada quando a renovação é impossível; trate-o como um deployment de segurança física.

O que não se preocupar

O software nunca precisa de um provedor de DNS ou de uma conexão de API para domínios.
A renovação de certificados (em deployments normais) é cuidada pelo proxy, não pelo CMS.
Headers de segurança chegam do CMS a cada resposta, independente da configuração do proxy; os exemplos os duplicam apenas como rede de segurança.

A versão curta

Aponte o DNS, fixe a grafia canônica em Settings, ponha o proxy na frente com o Let’s Encrypt cuidando dos certificados (ou escolha deliberadamente o modo offline sem TLS), verifique com curl -I, e ambas as variantes www/sem-www terminam no único domínio, permanentemente.