Grazie, non avevo visto quella PR. È interessante: la mia configurazione è leggermente diversa, poiché ho mantenuto il server web nginx di Discourse in posizione ed eseguo Caddy separatamente in Docker Compose davanti ad esso, principalmente per fornire HTTP/3 al bordo della rete.
C’è una piccola modifica lato Discourse: ho aggiunto un hook persistente in app.yml in modo che nginx utilizzi il valore di X-Forwarded-For di Caddy per l’IP reale del cliente quando le richieste arrivano tramite la socket Unix. Inizialmente avevo bisogno di una soluzione alternativa con X-Real-IP in Caddy, ma dopo aver aggiunto la correzione lato nginx sono riuscito a rimuoverla e a verificare che Discourse registri ancora l’IP corretto del cliente.
Ho anche disabilitato esplicitamente QUIC 0-RTT/early data nella configurazione di Caddy, lasciando abilitato HTTP/3, per evitare quel caso particolare legato ai early data.
Il mio approccio abilita anche la registrazione degli accessi HTTP di Caddy a livello di sito, il che mi fornisce la censura predefinita di Caddy per le intestazioni delle credenziali sensibili. Ruoto i log json-file risultanti di Docker a 25 MB × 3. Ho notato che la PR attuale ha il blocco di rotazione dei log nelle opzioni globali di Caddy, che la documentazione di Caddy descrive come configurazione della registrazione runtime piuttosto che della registrazione degli accessi HTTP.
Quindi non è esattamente un’installazione standard completamente intatta, ma è anche un approccio diverso rispetto alla sostituzione completa di nginx con Caddy.
Daremo un’occhiata più attenta a quella PR. Per ora sono principalmente interessato a sapere se c’è abbastanza interesse per questo approccio da rendere utile una guida passo passo, piuttosto che iniziare subito a scriverne una.