Dominio Personalizado y TLS

Apuntar tu site a tu propio dominio, y conseguir certificados HTTPS que se renuevan solos (o que gestionas intencionalmente), es una secuencia corta: apunta el DNS, elige la ortografía canónica, configura el proxy, verifica TLS. Esta guía lo recorre con los settings y las comprobaciones que el software espera.

Paso 1; Aputar el dominio

Agrega un registro DNS A/AAAA para tu dominio público (y otro separado para el admin, por ejemplo admin.example.com, si usas el patrón de los ejemplos), apuntando a tu server.
Para sites multiidioma decide pronto si cada idioma recibe su propio subdominio o vive bajo un host (ambos layouts vienen incluidos; ve Reverse Proxy). El modo subdominio significa direcciones estilo es.example.com para cada idioma.

El DNS está completamente fuera del software; no se asume ningún proveedor.

Paso 2; Fija tu URL canónica

En Settings, define Site URL; la ortografía exacta que quieres como la única dirección verdadera del site, incluyendo si usas www.

Por qué importa este único setting:

Cada URL canónica de página, cada entrada de sitemap, cada dirección de feed se genera a partir de ella.
El build escribe una regla de redirect permanente (301) que manda la otra ortografía de tu host (la que no elegiste) hacia la que sí; así buscadores y visitantes aterrizan en una sola dirección.
En el modo de idioma por subdominio, las URLs de cada idioma se reescriben automáticamente a su propio subdominio según este setting.

Haz esto bien primero; decide lo que será cada dirección generada.

Paso 3; Configurar el proxy y los certificados

Caddy (recomendado): suelta tus dominios en el config de ejemplo. Y listo; Caddy solicita y renueva los certificados Let's Encrypt automáticamente una vez que tu DNS apunte al server y los puertos 80/443 sean alcanzables. Ninguna línea de certificados que gestionar.
nginx: levanta el vhost HTTP desde el ejemplo incluido, luego corre Certbot para tu dominio; te inyecta el listener HTTPS y las referencias de certificado.
Mantén el CMS atado a loopback (por ejemplo 127.0.0.1:3001) y deja que el proxy haga el TLS. Comprueba: tras el primer arranque, curl -I https://your.admin.domain debería responder limpio.
No olvides las pequeñas reglas del proxy: /forms/ si tu site tiene formularios, /documents/ si usas documentos, y la lista honeypot (todo incluido en los ejemplos).

Paso 4; Verificar

Comprueba antes de dar por terminado:

La página pública por HTTPS carga sin warnings de mixed-content (el CMS y el proxy envían ambos los headers de cache/seguridad correctos).
El dominio del admin también responde por HTTPS.
La ortografía no canónica del host redirige a la elegida (o tu regla de host a nivel de Caddyfile lo hace; ve abajo).
La URL de cada idioma responde en su host/subdominio esperado.

Detalles que importan

El enforcement canónico es más fuerte en los hosts que leen el archivo de redirects con formato Netlify; el build escribe una regla 301 de nivel de host en _redirects. En deploys Caddy el archivo de reglas equivalente no la incluye, así que agrega el redirect de host en tu Caddyfile cuando necesites el redirect duro (los tags canónicos por página vienen del CMS en todos los hosts).
HSTS lo emite el CMS para el tráfico del admin (un año, incluyendo subdominios) y se refleja en el ejemplo nginx incluido; una vez que los navegadores lo han visto, el TLS debe seguir presente, así que asegúrate de que las renovaciones funcionan antes de depender de él.
Mapeo de puertos: cada instancia mantiene un puerto único (3001, 3002, …) detrás del proxy; el proxy enruta cada dominio hacia su instancia. Si adoptas el Manager, ahí adjuntas los dominios y regenera/recarga la config del proxy por ti; el daemon mismo nunca se sale del loopback.
Hosts extremamente air-gapped: hay un modo documentado sin DNS y sin certificados; HTTP plano en un puerto local, protegido por VPN/firewall en lugar de TLS. Es el escape hatch deliberado cuando la renovación es imposible; trátalo como un deploy de seguridad física.

Qué no debes preocuparte

El software nunca necesita un proveedor de DNS ni una conexión API para dominios.
La renovación de certificados (en deploys normales) la maneja el proxy, no el CMS.
Los security headers llegan del CMS en cada respuesta sin importar la configuración del proxy; los ejemplos los duplican solo como red de seguridad.

La versión corta

Apunta el DNS, fija la ortografía canónica en Settings, pon el proxy al frente con Let's Encrypt haciendo los certificados (o elige deliberadamente el modo offline sin TLS), verifica con curl -I; y ambas variantes www/sin www acaban en el único dominio, permanentemente.