He actualizado uno de mis servidores de foros Discourse, por lo que abrí el puerto UDP 443 en lugar de solo TCP en el panel de firewall de IONOS Cloud (soy del Reino Unido).
No utilizo CDN porque este foro en particular no tiene muchos usuarios, pero sí tiene muchas categorías.
Tuve algunas dificultades para garantizar que la geolocalización de IPs funcionara correctamente a través de nginx, y ahora el foro funciona bien sin problemas en /logs.
He configurado registros de proxy rotativos con Docker Compose y aprecio que Caddy realice una redacción automática de campos sensibles en los registros de proxy, algo que no había notado antes con Nginx. Aunque solo recuerdo haber utilizado los registros de proxy dos veces en los 2 años que he utilizado Discourse en producción.
Espero recopilar cuánto interés habría si publicara una guía que explicara qué comandos ejecuté y qué ocurrió al ejecutarlos, para pasar desde la Guía de instalación de Docker para principiantes hasta el foro actual, que es un poco más amigable para dispositivos móviles; puedo incluir comandos para mantenimiento futuro, es decir, actualizar Caddy a una versión más reciente, pero aún no he probado estos comandos en mi VPS L de IONOS.
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.
Solo una corrección/clarificación de lo que dije anteriormente.
Cuando originalmente describí el resultado como un:
foro más amigable para móviles, parte de lo que había notado fue que el viaje de ida y vuelta inicial al abrir la PWA de iOS Safari se sentía demasiado lento.
Sin embargo, ahora me arrepiento de haber incluido esta afirmación en mi respuesta posterior:
Deshabilitar 0-RTT fue algo que intenté mientras diagnosticaba el problema de la IP del cliente, pero parece que no fue necesario. Ambos errores de PostgreSQL que involucraban unix: continuaron ocurriendo mientras 0rtt off ya estaba configurado.
El cambio que parece haber resuelto esos errores fue en cambio el gancho persistente app.yml que modifica nginx para que utilice el valor X-Forwarded-For de Caddy para la IP real del cliente cuando llegan solicitudes a través del socket Unix.
Por lo tanto, ahora he eliminado la configuración 0rtt off y restaurado el comportamiento predeterminado de Caddy. HTTP/3 sigue funcionando y la IP del cliente correcta sigue pasando a Discourse.
Así que si finalmente hay suficiente interés para que prepare la guía paso a paso, no incluiría la deshabilitación de QUIC 0-RTT como parte obligatoria de la configuración.
Gracias - verifiqué el nginx que actualmente se incluye en mi contenedor app de Discourse, y tienes razón en que puede proporcionar HTTP/3 directamente:
Por lo tanto, el HTTP/3 directo desde el nginx existente de Discourse es definitivamente una alternativa válida.
Sin embargo, una razón por la que aún podría preferir Caddy para esta configuración en particular es 0-RTT. Después de la corrección anterior, volví a habilitar el comportamiento predeterminado de QUIC 0-RTT de Caddy, y en la PWA de iOS Safari noté una mejora significativa en la experiencia de carga que estaba intentando optimizar.
Por lo que puedo deducir de la documentación de nginx, las versiones de nginx anteriores a 1.29.1 no pueden habilitar 0-RTT cuando se compilan con OpenSSL, independientemente de ssl_early_data, por lo que el nginx 1.26.3 actual en mi contenedor de Discourse puede manejar HTTP/3, pero no esa optimización en particular.
Así que me interesa comparar los dos enfoques en lugar de asumir que Caddy es necesario solo por HTTP/3.