Danke, ich hatte diesen PR nicht gesehen. Das ist interessant – mein Setup ist etwas anders, da ich Discourses nginx-Webserver beibehalten und Caddy separat in Docker Compose davor laufen lasse, hauptsächlich um HTTP/3 am Edge bereitzustellen.
Es gibt eine kleine Änderung auf Discourse-Seite: Ich habe einen persistenten app.yml-Hook hinzugefügt, sodass nginx den X-Forwarded-For-Wert von Caddy für die echte Client-IP verwendet, wenn Anfragen über den Unix-Socket eintreffen. Ursprünglich brauchte ich einen Caddy-X-Real-IP-Workaround, aber nachdem ich die nginx-seitige Korrektur hinzugefügt hatte, konnte ich diesen entfernen und überprüfen, dass Discourse weiterhin die korrekte Client-IP aufzeichnet.
Ich habe auch QUIC 0-RTT/Early Data in der Caddy-Konfiguration explizit deaktiviert, während HTTP/3 aktiviert bleibt, um diesen zusätzlichen Early-Data-Edge-Case zu vermeiden.
Mein Ansatz ermöglicht auch Caddys HTTP-Access-Logging auf Site-Ebene, was mir Caddys Standard-Redaktion sensibler Credential-Header bietet. Ich rotiere die daraus resultierenden Docker-json-file-Logs bei 25 MB × 3. Ich habe bemerkt, dass der PR aktuell seinen rotierenden Log-Block in Caddys globalen Optionen hat, was in Caddys Dokumentation als Konfiguration des Runtime-Loggings und nicht des HTTP-Access-Loggings beschrieben wird.
Es ist also nicht ganz eine komplett unberührte Standardinstallation, aber es ist auch ein anderer Ansatz als den Austausch von nginx durch Caddy insgesamt.
Ich werde mir diesen PR genauer ansehen. Für jetzt bin ich hauptsächlich daran interessiert, ob genug Interesse an diesem Ansatz besteht, um eine Schritt-für-Schritt-Anleitung sinnvoll zu machen, anstatt sofort damit zu beginnen.