Спасибо, я не видел этот PR. Это интересно — моя настройка немного отличается тем, что я оставил веб-сервер nginx от Discourse на месте и запускаю Caddy отдельно в Docker Compose перед ним, в основном для обеспечения поддержки HTTP/3 на границе сети.
Есть одно небольшое изменение на стороне Discourse: я добавил постоянный хук в app.yml, чтобы nginx использовал значение X-Forwarded-For от Caddy в качестве реального IP-адреса клиента при поступлении запросов через Unix-сокет. Изначально мне требовалось обходное решение с использованием X-Real-IP в Caddy, но после добавления исправления на стороне nginx я смог его удалить и убедиться, что Discourse по-прежнему записывает правильный IP-адрес клиента.
Я также явно отключил QUIC 0-RTT/ранние данные в конфигурации Caddy, оставив при этом HTTP/3 включённым, чтобы избежать дополнительных проблем с ранними данными.
Мой подход также позволяет включить журналирование HTTP-доступа Caddy на уровне сайта, что даёт мне стандартное анонимизирование чувствительных заголовков учётных данных в Caddy. Я вращающие результирующие журналы Docker json-file по схеме 25 МБ × 3. Я заметил, что в текущем PR блок вращения журналов находится в глобальных опциях Caddy, что, согласно документации Caddy, предназначено для конфигурации журналов времени выполнения, а не журналов HTTP-доступа.
Так что это не совсем стандартная установка без изменений, но это и другой подход по сравнению с полной заменой nginx на Caddy.
Я внимательно изучу этот PR. На данный момент меня в основном интересует, достаточно ли интерес к этому подходу, чтобы пошаговое руководство было целесообразным, а не начинать его создание немедленно.