Proxy Reverso

Seu servidor web fica à frente de tudo: serve seu site publicado como arquivos simples e encaminha os poucos caminhos dinâmicos (formulários, documentos, a UI de admin) ao daemon do CMS. Esta página explica as configurações de exemplo embarcadas, como portas e idiomas mapeiam e como os certificados TLS são tratados.

Os exemplos embarcados

A pasta de deploy do projeto contém configurações prontas para copiar:

Caddy (recomendado): um exemplo completo com HTTPS automático: o site do produto, o domínio de admin e vhosts estáticos por idioma construídos a partir de um snippet reutilizável.
nginx (completo): o padrão de dois vhosts, com um vhost estático por idioma mais o proxy da UI de admin, e com cache e headers de segurança.
nginx (mínimo): um template de domínio único com placeholders (domínio, caminho de saída, porta do CMS) cobrindo o layout comum.

Todos os três codificam as mesmas regras; as diferenças são o binário do servidor e o quanto eles pegam na sua mão.

Portas e para onde o tráfego flui

Cada instância do CMS escuta em sua própria porta de loopback: a convenção é 3001 para a instância 1, 3002 para a instância 2, e assim por diante (o instalador as atribui; você pode sobrescrever).
O vhost do site público serve o diretório de saída estática diretamente do disco. É apenas um file server mais três pequenas regras de proxy (abaixo).
A UI de admin (por exemplo admin.example.com) é um reverse proxy completo para a porta da instância: cada requisição vai ao CMS.

Três regras de proxy de que você pode precisar

Copie estas para o(s) vhost(s) do site público. Cada uma é exigida por uma funcionalidade específica, e todos os exemplos embarcados avisam sobre elas:

/forms/: todo formulário do seu site envia POST para /forms/<slug>, o que nenhum servidor de arquivos estático consegue tratar. Sem este bloco, cada envio de formulário falha. (Obrigatório se você usa formulários de contato ou newsletter.)
/documents/: downloads de documentos (com rastreamento e controle de acesso) são servidos ao vivo pelo CMS. Obrigatório apenas se você usa a funcionalidade Documents, com a ressalva de que um dos dois exemplos nginx embarcados é anterior a ela; se seu arquivo de exemplo não tem o bloco /documents/, adicione-o quando usar documentos.
Honeypots de scanner: uma curta lista de URLs de sondagem conhecidas (/.env, /wp-login.php, wp-admin, phpmyadmin, …) é encaminhada ao CMS para que esses acessos sejam registrados e retardados em vez de respondidos por um 404 estático simples.

O vhost de admin encaminha tudo, e esse é o ponto: a interface de admin é o CMS.

Loopback é uma decisão de segurança

Ligue o CMS a 127.0.0.1:<porta> e deixe o proxy de frente para a internet. O CMS confia em IPs de cliente encaminhados apenas de conexões loopback: ligue-o a uma interface pública e seus limites de taxa/bloqueios de login podem ser falsificados.
Se o seu proxy alcança o CMS por uma rede não-loopback (como o Docker), adicione essa rede via CHINASKI_TRUSTED_PROXIES no arquivo de env da instância.
Comportamento de headers: os exemplos passam X-Real-IP/X-Forwarded-For/X-Forwarded-Proto de forma consistente. O Caddy v2 os gerencia por conta própria; os exemplos nginx os definem explicitamente em cada bloco de proxy.

Cache (o que os exemplos definem)

Páginas (HTML): cache de 5 minutos, deliberadamente curto para que os builds cheguem rápido aos leitores.
Service worker: nunca em cache, pois uma cópia obsoleta bloquearia as atualizações do site.
Fontes: com hash de conteúdo, cache de um ano (nunca mudam de nome).
Outros assets (CSS/JS/imagens): um dia.
O próprio app já envia headers corretos; as regras de proxy são cinto e suspensório, para que respostas erradas não passem despercebidas, nem mesmo de páginas de erro obsoletas.

Headers de segurança

Os exemplos de vhost de admin adicionam proteção contra frames, proteção contra sniffing de content-type e política de referrer na camada de proxy, explicitamente como backup para o caso de uma página de erro estática ser servida antes que o CMS possa responder. O CMS reproduz cada um deles por si mesmo em cada resposta, para que as duas camadas concordem; o exemplo mínimo do nginx também adiciona HSTS no proxy.

TLS com Let’s Encrypt

Caddy: faz tudo automaticamente, solicitando e renovando certificados assim que seu DNS aponta para o host e as portas 80/443 estão acessíveis. Nenhuma linha de configuração no exemplo; esse é o objetivo.
nginx: os templates vêm apenas em HTTP e esperam um comando, certbot --nginx -d SEU_DOMINIO, que injeta para você as linhas de listen 443 e de certificado.
Sem internet? O modo offline (“EOTW”) executa intencionalmente HTTP puro, sem certificados a renovar: a alternativa documentada quando o Let’s Encrypt não está acessível. Use uma VPN ou regras de firewall para proteger o admin nesse modo.
O TLS é terminado no proxy; o CMS sempre vê tráfego criptografado terminando ali e emite HSTS de um ano.

Sites multilíngues

Os exemplos completos de Caddy e nginx dão um vhost por idioma (cada um enraizado no diretório output/<lang> daquele idioma). Se o seu modo de idioma de permalinks mudar depois, o script de deploy ressincroniza automaticamente as document roots do servidor web: a configuração do proxy nunca precisa de edição manual para essa troca.

O modo de idioma por subdomínio combina com um host por idioma: as URLs canônicas são então construídas por subdomínio, correspondendo ao layout.

Um checklist antes de entrar no ar

Dois blocos de proxy existem: /forms/ (se formulários forem usados) e /documents/ (se documentos forem usados).
O daemon de admin está ligado ao loopback; apenas o proxy está exposto.
nginx -t (ou a validação do Caddy) passa e o serviço recarregou de forma limpa.
Certificados emitidos (ou modo EOTW escolhido deliberadamente).
Uma passada rápida com um scanner externo acerta o bloco de honeypot, não um 404 simples, o que fica visível nos logs de admin.