Proxy Inverso

Tu servidor web está delante de todo: sirve tu site publicado como archivos planos y reenvía las pocas rutas dinámicas (forms, documents, la UI de administración) al daemon del CMS. Esta página explica las configuraciones de ejemplo incluidas, cómo mapean los puertos y los idiomas, y cómo se manejan los certificados TLS.

Los ejemplos incluidos

La carpeta deploy del proyecto contiene configuraciones listas para copiar:

Caddy (recomendado): un ejemplo completo con HTTPS automático: el site del producto, el dominio de administración y vhosts estáticos por idioma construidos a partir de un snippet reutilizable.
nginx (completo): el patrón de dos vhosts, un vhost estático por idioma más el proxy de la UI de administración, con caché y cabeceras de seguridad.
nginx (mínimo): una plantilla de un solo dominio con marcadores de posición (dominio, ruta de salida, puerto del CMS) que cubre el layout común.

Los tres codifican las mismas reglas; las diferencias son el binario del servidor y cuánto te llevan de la mano.

Puertos y por dónde fluye el tráfico

Cada instancia del CMS escucha en su propio puerto de loopback: la convención es 3001 para la instancia 1, 3002 para la instancia 2, y así sucesivamente (el instalador los asigna; puedes sobrescribirlos).
El vhost del site público sirve el directorio de salida estático directamente desde disco. Es solo un servidor de archivos más tres pequeñas reglas de proxy (abajo).
La UI de administración (p. ej. admin.example.com) es un reverse proxy completo al puerto de la instancia; cada petición va al CMS.

Tres reglas de proxy que puede que necesites

Cópialas en el/los vhost(s) del site público; cada una la requiere una característica específica, y todos los ejemplos incluidos advierten sobre ellas:

/forms/: cada formulario de tu site hace POST a /forms/<slug>, cosa que ningún servidor de archivos estáticos puede manejar. Sin este bloque, cada envío de formulario falla. (Requerido si usas formularios de contacto o newsletter.)
/documents/: las descargas de documentos (con seguimiento y control de acceso) las sirve en vivo el CMS. Requerido solo si usas la característica Documents, con la salvedad de que uno de los dos ejemplos de nginx incluidos es anterior a ella; si tu archivo de ejemplo carece del bloque /documents/, agrégalo cuando uses documentos.
Honeypots de escáneres: una lista corta de URLs de sondeo conocidas (/.env, /wp-login.php, wp-admin, phpmyadmin, …) se hace proxy al CMS para que esos hits se registren y se ralenticen en lugar de responderse con un 404 estático plano.

El vhost de administración hace proxy a todo; ese es el punto: la interfaz de administración es el CMS.

Loopback es una decisión de seguridad

Enlaza el CMS a 127.0.0.1:<port> y deja que el proxy dé la cara a internet. El CMS confía en las IPs de cliente reenviadas solo desde conexiones de loopback: si lo enlazas a una interfaz pública, tus límites de tasa y bloqueos de login pueden falsificarse.
Si tu proxy llega al CMS por una red que no es loopback (como Docker), agrega esa red mediante CHINASKI_TRUSTED_PROXIES en el archivo env de la instancia.
Comportamiento de las cabeceras: los ejemplos pasan X-Real-IP/X-Forwarded-For/X-Forwarded-Proto de forma consistente. Caddy v2 las gestiona por sí mismo; los ejemplos de nginx las establecen explícitamente en cada bloque de proxy.

Caché (lo que los ejemplos establecen)

Páginas (HTML): en caché 5 minutos: deliberadamente corto para que los builds lleguen rápido a los lectores.
Service worker: nunca se cachea; una copia obsoleta bloquearía las actualizaciones del site.
Fuentes: con hash de contenido, caché de un año (nunca cambian de nombre).
Otros assets (CSS/JS/imágenes): un día.
La aplicación ya envía las cabeceras correctas; las reglas del proxy son un doble seguro para que no se cuelen respuestas incorrectas ni siquiera desde páginas de error obsoletas.

Cabeceras de seguridad

Los ejemplos del vhost de administración añaden protección contra iframes, protección contra sniffing de content-type y política de referrer en la capa de proxy, explícitamente como respaldo en caso de que se sirva una página de error estática antes de que el CMS pueda responder. El CMS reproduce cada una de ellas él mismo en cada respuesta, así que las dos capas coinciden; el ejemplo mínimo de nginx también añade HSTS en el proxy.

TLS con Let's Encrypt

Caddy: lo hace todo automáticamente; solicita y renueva certificados en cuanto tu DNS apunta al host y los puertos 80/443 son alcanzables. No hay líneas de configuración en el ejemplo; ese es el punto.
nginx: las plantillas vienen solo con HTTP y esperan un comando (certbot --nginx -d YOUR_DOMAIN) que inyecta por ti las líneas listen 443 y de certificado.
¿Sin internet? El modo offline (“EOTW”) ejecuta intencionalmente HTTP plano sin certificados que renovar: la alternativa documentada cuando Let's Encrypt no es alcanzable. Usa una VPN o reglas de firewall para proteger la administración en ese modo.
TLS se termina en el proxy; el CMS siempre ve el tráfico cifrado terminando allí y emite HSTS de un año.

Sitios multi-idioma

Los ejemplos completos de Caddy y de nginx dan ambos un vhost por idioma (cada uno con raíz en el directorio output/<lang> de ese idioma). Si más adelante cambia tu modo de idioma de permalinks, el script de deploy re-sincroniza automáticamente las document roots del servidor web; la configuración del proxy nunca necesita edición a mano para ese cambio.

El modo de idioma por subdominio se empareja con un host por idioma; las URLs canónicas se construyen entonces por subdominio, coincidiendo con el layout.

Una lista de verificación antes de salir a producción

Existen los dos bloques de proxy: /forms/ (si se usan forms) y /documents/ (si se usan documents).
El daemon de administración enlaza a loopback; solo el proxy está expuesto.
nginx -t (o la validación de Caddy) pasa y el servicio se recargó limpiamente.
Certificados emitidos (o modo EOTW elegido deliberadamente).
Una pasada rápida con un escáner externo golpea el bloque honeypot, no un 404 pelado, visible en los logs del admin.