Atualizei um dos meus servidores de fórum Discourse, então abri a porta UDP 443, em vez de apenas TCP, no firewall do Painel da IONOS Cloud (sou do Reino Unido).
Não uso CDN porque este fórum em particular não tem muitos usuários, mas tem muitas categorias.
Tive algumas dificuldades para garantir que a geolocalização de IP funcionasse corretamente através do nginx, e o fórum está funcionando bem agora, sem problemas nos /logs.
Configurei rotação de logs de proxy com Docker Compose e aprecio o fato de o Caddy fazer alguma redação automática de campos sensíveis nos logs de proxy, algo que eu não tinha notado com o Nginx antes. Embora eu só me lembre de ter usado logs de proxy duas vezes nos 2 anos em que usei o Discourse em produção.
Estou esperando para ver quanto interesse haveria se eu publicasse um guia mostrando quais comandos executei e o que aconteceu quando os executei, para ir do Guia de instalação Docker para iniciantes ao fórum agora um pouco mais amigável para dispositivos móveis - posso incluir comandos para manutenção futura, ou seja, atualizar o Caddy para uma versão mais recente, mas ainda não testei esses comandos no meu VPS IONOS L.
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.
Apenas uma correção/esclarecimento sobre o que disse acima.
Quando descrevi originalmente o resultado como um:
fórum mais amigável para dispositivos móveis, parte do que eu tinha notado era que a ida e volta inicial ao abrir a PWA do Safari no iOS parecia lenta demais.
No entanto, agora me arrependo de ter incluído esta afirmação na minha resposta posterior:
Desativar 0-RTT foi algo que tentei enquanto diagnosticava o problema do IP do cliente, mas não parece ter sido necessário. Ambos os erros do PostgreSQL envolvendo unix: continuaram enquanto 0rtt off já estava configurado.
A mudança que parece ter resolvido esses erros foi, em vez disso, o gancho persistente app.yml que modifica o nginx para que ele use o valor X-Forwarded-For do Caddy para o IP real do cliente quando as solicitações chegam pelo soquete Unix.
Portanto, agora removi a configuração 0rtt off e restaurei o comportamento padrão do Caddy. O HTTP/3 ainda está funcionando e o IP correto do cliente continua sendo transmitido para o Discourse.
Então, se houver interesse suficiente para eu preparar o guia passo a passo, eu não incluiria a desativação do QUIC 0-RTT como parte obrigatória da configuração.
Portanto, o HTTP/3 direto do nginx existente do Discourse é definitivamente uma alternativa viável.
Um motivo pelo qual posso ainda preferir o Caddy para esta configuração específica é o 0-RTT, no entanto. Após a correção acima, reativei o comportamento padrão de 0-RTT do QUIC do Caddy, e na PWA do Safari no iOS notei uma melhoria significativa na experiência de carregamento que eu estava tentando melhorar.
Tanto quanto posso entender pela documentação do nginx, versões do nginx anteriores à 1.29.1 não podem habilitar 0-RTT quando compiladas com OpenSSL, independentemente da configuração ssl_early_data, então o nginx 1.26.3 atualmente no meu container do Discourse pode fazer HTTP/3, mas não essa otimização específica.
Então, estou interessado em comparar as duas abordagens, em vez de assumir que o Caddy é necessário apenas para HTTP/3.