Obrigado, eu não tinha visto aquele PR. Isso é interessante – minha configuração é um pouco diferente, pois mantive o servidor web nginx do Discourse no lugar e executo o Caddy separadamente no Docker Compose na frente dele, principalmente para fornecer HTTP/3 na borda.
Há uma pequena mudança do lado do Discourse: adicionei um hook persistente no app.yml para que o nginx use o valor X-Forwarded-For do Caddy como o IP real do cliente quando as solicitações chegam pelo soquete Unix. Originalmente, eu precisava de uma solução alternativa com X-Real-IP no Caddy, mas depois de adicionar a correção do lado do nginx, consegui removê-la e verificar que o Discourse ainda registra o IP correto do cliente.
Também desativei explicitamente o QUIC 0-RTT/dados iniciais na configuração do Caddy, mantendo o HTTP/3 habilitado, para evitar esse caso de borda adicional de dados iniciais.
Minha abordagem também permite o registro de acesso HTTP do Caddy no nível do site, o que me dá a redação padrão do Caddy para cabeçalhos de credenciais sensíveis. Eu roto os logs resultantes do Docker json-file em 25 MB × 3. Notei que o PR atualmente tem seu bloco de log rotativo nas opções globais do Caddy, o que a documentação do Caddy descreve como configuração de registro em tempo de execução, em vez de registro de acesso HTTP.
Então, não é exatamente uma instalação padrão completamente intocada, mas também é uma abordagem diferente de substituir o nginx pelo Caddy completamente.
Vou dar uma olhada mais de perto nesse PR. Por enquanto, estou principalmente interessado em saber se há interesse suficiente nessa abordagem para tornar um guia passo a passo worthwhile, em vez de começar um imediatamente.