Hospedaje Estático
Un site Chinaski construido es un árbol plano de HTML/CSS/imágenes afilado para servicio estático; de nuevo, el despliegue típico es un proxy inverso o un host estático leyendo esa salida. Esta página cubre el servicio con nginx o Caddy, cómo funcionan los archivos de redirect (hosting estilo Netlify) y qué rutas necesita seguir reenviando al CMS un site "estático".
La salida construida
Un directorio por idioma (o una raíz única para sites monolingües):
index.htmlpor directorio, con semántica de try-files que traduce las URL a rutas._redirects: las reglas de redirect estilo Netlify que el builder genera en cada build (redirects de slug con sus códigos de estado configurados)._redirects.caddy: un archivo complementario con los mismos redirects en la sintaxis nativa de Caddy, listo para incluir en un Caddyfile.- Archivos PWA (
sw.js, manifest, página offline) con sus propias directivas de caché. - Aplicación completa del dominio canónico: un bloque generado en
_redirectsque redirige con 301 el host alterno www/sin www al que coincide con tu Site URL (consulta la página del dominio canónico para su sintaxis exacta).
Las rutas que un site estático debe seguir reenviando
Dos familias de URL no pueden servirse estáticamente y deben ir por proxy inverso al daemon del CMS:
/forms/*: páginas públicas de formularios y POST de envío. Sin reenvío, cada envío de formulario devuelve 404./documents/*: descargas de documentos (conteo de descargas, control por estado de publicación). Sin reenvío, cada URL de documento da 404.
Ambos ejemplos incluidos hacen exactamente esto
El repositorio trae vhosts listos para copiar y editar:
- nginx (
deploy/chinaski.nginx.exampley su hermano más completo-conf.example): sirve desde la document root, reenvía/forms/y/documents/a127.0.0.1:<CMS port>, establece caché larga en fuentes/assets, sin caché para el service worker, caché corta en HTML, además de las cabeceras de seguridad a nivel de app como cinturón y tirantes. TLS: ejecuta certbot sobre el vhost habilitado. - Caddy (
deploy/chinaski.Caddyfile.example): un bloque por instancia, hace proxy al puerto loopback del CMS, establece X-Forwarded-For/Proto/Host explícitamente, añade políticas de caché que reflejan las de nginx, y enruta las rutas señuelo de escáneres (/.env, /.git/config, sondeos de wp-login…) al CMS para que se registren y se retengan en lugar de ser respondidas por el servidor web.
El proxy por loopback es deliberado: los proxies que conectan desde 127.0.0.1 se confían por defecto, así que no hace falta un CHINASKI_TRUSTED_PROXIES extra. Si tu proxy está a un salto de red de contenedores, añade esa red a CHINASKI_TRUSTED_PROXIES.
La sincronización del root de nginx de deploy.sh
En cada deploy el script sincroniza la document root de nginx con el modo de idioma actual: a output/ para sites monolingües o output/<default language> en caso contrario, editando solo las configuraciones que referencian esa instalación. Corre nginx -t antes de recargar y advierte, dejando todo seguro, si la prueba de configuración falla.
Los archivos de redirect
El builder emite tres archivos generados en la raíz de la salida relacionados con redirects. Ver la página de formatos de redirect para el desglose archivo por archivo, incluyendo la línea de dominio canónico específica de Caddy.
Hosting estilo Netlify
El builder escribe las reglas de redirect en el formato Netlify _redirects (líneas planas de slug-viejo → slug-nuevo con tu código de estado elegido). Dos cosas que saber antes de apuntar Netlify a la salida:
- Los redirects por patrón (comodines
*con marcadores de captura) deliberadamente no se escriben en_redirects; el formato simple de archivo no puede expresarlos de forma segura; esos viven en la configuración de tu proxy. - El bloque generado de dominio canónico usa la sintaxis de fuerza
301!de Caddy en el mismo archivo. Un parser estricto de_redirectsde Netlify rechazará esa línea; revísala/edítala antes de enviar el archivo a un host que no sea Caddy, o sobrescríbela.
Nota de cinturón y tirantes: las cabeceras de seguridad que establece la app del CMS también están en los vhosts de ejemplo, porque un proxy puede servir respuestas cacheadas antes de que la app tenga la oportunidad de responder.
En esta sección
También en Hospedaje Estático
Caddy sirve el árbol estático construido con TLS automático.
nginx sirve el árbol estático construido y reenvía dos familias de URL al daemon del CMS.
Cada build escribe reglas de redirect en archivos en la raíz de la salida.