Я обновил один из своих серверов форума Discourse, поэтому мне пришлось открыть UDP 443, а не только TCP, в брандмауэре панели управления IONOS Cloud (я из Великобритании).
Я не использую CDN, так как этот конкретный форум не имеет большого количества пользователей, но содержит множество категорий.
У меня возникли некоторые трудности с правильной настройкой гео-фильтрации IP-адресов через nginx, но теперь форум работает отлично, и в /logs нет никаких проблем.
Я настроил ротацию журналов прокси с помощью Docker Compose и заметил, что Caddy автоматически маскирует конфиденциальные поля в журналах прокси — этого я раньше не замечал в Nginx. Хотя я вспоминаю, что пользовался журналами прокси всего два раза за два года эксплуатации Discourse в продакшене.
Я хочу понять, насколько велик интерес к публикации руководства, в котором я опишу, какие команды запускал и что происходило при их выполнении, чтобы перейти от руководства по установке Docker для начинающих к текущей, более удобной для мобильных устройств версии форума. Я могу включить команды для будущего обслуживания, например, обновление Caddy до новой версии, но я ещё не проверял эти команды на своём VPS IONOS L.
Спасибо, я не видел этот 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. На данный момент меня в основном интересует, достаточно ли интерес к этому подходу, чтобы пошаговое руководство было целесообразным, а не начинать его создание немедленно.
Небольшое исправление/уточнение к тому, что я написал выше.
Когда я изначально описывал результат как:
более удобную для мобильных устройств платформу форума, одной из замеченных мной вещей было то, что первоначальный цикл запросов при открытии PWA в iOS Safari казался слишком медленным.
Однако теперь я жалею, что включил это утверждение в свой последующий ответ:
Отключение 0-RTT было чем-то, что я попробовал при диагностике проблемы с IP-адресом клиента, но, похоже, это не было необходимо. Обе ошибки PostgreSQL, связанные с unix:, продолжались, даже когда уже была настроена опция 0rtt off.
Изменение, которое, похоже, разрешило эти ошибки, заключалось в постоянном хуке app.yml, который модифицирует nginx так, чтобы он использовал значение X-Forwarded-For от Caddy в качестве реального IP-адреса клиента, когда запросы поступают через Unix-сокет.
Поэтому теперь я удалил настройку 0rtt off и восстановил поведение Caddy по умолчанию. HTTP/3 по-прежнему работает, и правильный IP-адрес клиента продолжает передаваться в Discourse.
Так что если в конечном итоге будет достаточно интереса, чтобы я составил пошаговое руководство, я не буду включать отключение QUIC 0-RTT как обязательную часть конфигурации.
Спасибо — я проверил nginx, который в настоящее время поставляется внутри моего контейнера Discourse app, и вы правы, что он может напрямую предоставлять HTTP/3:
Так что прямой HTTP/3 от существующего nginx в Discourse определенно является реальной альтернативой.
Одна из причин, по которой я по-прежнему могу предпочесть Caddy для этой конкретной настройки, — это 0-RTT. После исправления, описанного выше, я снова включил поведение QUIC 0-RTT по умолчанию в Caddy, и в iOS Safari PWA я заметил значительное улучшение в пользовательском опыте загрузки, который я пытался улучшить.
Насколько я могу судить по документации nginx, версии nginx до 1.29.1 не могут включить 0-RTT при сборке с OpenSSL, независимо от ssl_early_data, поэтому nginx 1.26.3, который в настоящее время находится в моем контейнере Discourse, может использовать HTTP/3, но не эту конкретную оптимизацию.
Поэтому меня интересует сравнение двух подходов, а не предположение, что Caddy необходим просто для HTTP/3.