Gracias, no había visto ese PR. Eso es interesante: mi configuración es ligeramente diferente, ya que he mantenido el servidor web nginx de Discourse en su lugar y ejecuto Caddy por separado en Docker Compose delante de él, principalmente para proporcionar HTTP/3 en el borde.
Hay un pequeño cambio en el lado de Discourse: he añadido un gancho persistente en app.yml para que nginx utilice el valor de X-Forwarded-For de Caddy como la IP real del cliente cuando llegan las solicitudes a través del socket Unix. Originalmente necesitaba una solución alternativa con X-Real-IP de Caddy, pero después de añadir la corrección en el lado de nginx, pude eliminarla y verificar que Discourse sigue registrando la IP correcta del cliente.
También he deshabilitado explícitamente QUIC 0-RTT/datos tempranos en la configuración de Caddy, manteniendo habilitado HTTP/3, para evitar ese caso extremo adicional de datos tempranos.
Mi enfoque también permite el registro de acceso HTTP de Caddy a nivel de sitio, lo que me proporciona la redacción predeterminada de Caddy para los encabezados de credenciales sensibles. Roto los registros json-file de Docker resultantes en 25 MB × 3. He observado que el PR actual tiene su bloque de rotación de registros en las opciones globales de Caddy, lo cual la documentación de Caddy describe como la configuración de registro en tiempo de ejecución, en lugar de registro de acceso HTTP.
Así que no es exactamente una instalación estándar completamente intacta, pero tampoco es el mismo enfoque que reemplazar nginx por Caddy por completo.
Echaré un vistazo más detallado a ese PR. Por ahora, me interesa principalmente saber si hay suficiente interés en este enfoque para que valga la pena crear una guía paso a paso, en lugar de empezar una de inmediato.