Подождите… Кажется, я понял… Отключил прокси и пересобрал без шаблона Cloudflare. Включил прокси снова, и теперь я могу получить доступ к WordPress и форуму с включённым строгим SSL!
Вам очень легко получить ограничение скорости, если вы не выберете шаблон Cloudflare…
Discourse подумает, что многие люди регистрируются с одного IP-адреса (прокси Cloudflare), и начнет ограничивать их скорость.
Хм… значит, лучше сделать это снова, но без адреса электронной почты Let’s Encrypt и с использованием шаблона Cloudflare. Вы знаете, нужно ли оставить прокси включенным при повторной сборке с шаблоном Cloudflare?
Огромное спасибо за всю помощь… Я больше творческий человек.
Это мой регистратор, а не просто DNS… и я не могу позволить себе платить огромную сумму, которую они требуют от меня за использование другого DNS. Так что, ой.
Настройка Discourse больше не требует адреса электронной почты для регистрации сертификатов, и так было уже давно. Если вы не измените файл yml, чтобы отключить SSL, по умолчанию всегда будет использоваться HTTPS.
Использование Cloudflare для DNS и включение «оранжевого облака» — это совершенно разные вещи. В контексте вышеизложенного под использованием Cloudflare подразумевается их прокси и оптимизации, которые в прошлом уже приводили к довольно странным проблемам. Их DNS работает отлично, даже очень хорошо.
Ваша установка Discourse не требует изменений: у вас уже работает HTTPS, и всё в порядке. Если SSL функционирует и включён шаблон CloudFlare, не трогайте его.
Похоже, проблема теперь на стороне WordPress. Как именно он у вас установлен? Это просто VPS или какой-то специализированный хостинг для WordPress?
Это очень распространённая конфигурация, и я уверен, что проблема легко решается.
Это чрезвычайно плохая идея. Как только Discourse зарегистрирует сертификат через Let’s Encrypt, продления будут проходить успешно, так как они осуществляются через другой механизм. Нет необходимости отключать TLS между сервером и CDN.
Зачем делать это, учитывая вышесказанное? Помимо создания дополнительной локальной нагрузки на обработку правил UFW для всего трафика, вы рискуете, что ваши правила устареют, что быстро приведёт к множеству сетевых ошибок. Cloudflare периодически добавляет новые диапазоны IP-адресов, и вы узнаете об этом только тогда, когда пользователи не смогут получить доступ к сайту. Позвольте сертификату зарегистрироваться, а если вы всё же хотите использовать Cloudflare, просто настройте соответствующее правило для страницы.
Я использую Cloudflare в режиме только DNS — это просто. Просто нажмите и отключите «оранжевое облако» в панели управления DNS, чтобы облако стало серым. На этом всё.
Это больше не работает так, как раньше. Если вы не хотите использовать Let’s Encrypt, вам нужно настроить всё вручную, а не через discourse-setup.
Так какой сертификат получит Discourse в случае отсутствия email-адреса для Let’s Encrypt? Самоподписанный или сертификат, выпущенный на произвольный email?
В любом случае это должно работать корректно с SSL-настройками Cloudflare, так как они поддерживают хосты с действительным сертификатом в конфигурации Full SSL и выше.
Вам нужно проверить исходный код, так как я точно не помню. Мне кажется, что используется адрес электронной почты администратора. Если проверка доступности сервера на порту 443 не удалась, установка будет отклонена.
Возможно, я абсолютно не прав, но, судя по этому коду:
read_config "LETSENCRYPT_ACCOUNT_EMAIL"
local letsencrypt_account_email=$read_config_result
if [ -z $letsencrypt_account_email ]
then
letsencrypt_account_email="me@example.com"
fi
if [ "$letsencrypt_account_email" = "me@example.com" ]
then
local letsencrypt_status="ENTER to skip"
else
local letsencrypt_status="Enter 'OFF' to disable."
fi
кажется, что проверка конфигурации по умолчанию должна предлагать ввести “off”, чтобы отключить Let’s Encrypt? Возможно, я полностью не прав и смотрю не туда?
Отключение Let’s Encrypt — это не решение.
При стандартной установке — нет.
При расширенной установке (например, при использовании обратного прокси) — это вполне уместный ответ.
Не могли бы вы подробнее объяснить, почему?
Сценарий с сертификатом легко реализовать. Даже если вы запускаете второй веб-сервер на том же сервере и используете локальный прокси, настроить сертификат несложно. Так почему бы вам этого не сделать?
Зачем запрашивать несколько сертификатов?
Если я могу запросить один (объединённый) сертификат от Let’s Encrypt через обратный прокси (например, nginx или Caddy), зачем мне нужен второй сертификат внутри контейнера Discourse, если его всё равно никто не использует?
Я думаю, что общий ответ — по возможности полностью избежать сложности прокси-сервера 
Однако это неизбежно, как только вы переходите к развёртыванию, выходящему за рамки стандартной конфигурации из одного или двух контейнеров.
Вашему форуму нужно стать действительно очень большим, чтобы понадобился прокси Cloudflare. Это стоит учитывать, когда ваш форум начинает испытывать перегрузки. Если только вы не мигрируете крупный форум на Discourse, никто, устанавливающий Discourse, не должен задумываться об этом.
Я действительно не согласен: правильно настроить HTTPS несложно. В данном случае у пользователя два сайта на двух разных серверах в рамках одного домена.
Нет никаких технических причин, по которым оба сайта не могли бы работать по HTTPS, независимо от того, активирован ли Cloudflare. Это легко сделать, если понять метод получения сертификатов, используемый Let’s Encrypt, и знать, как настроить Cloudflare для Discourse. У Cloudflare есть режим полного HTTPS, который создан именно для таких сценариев: TLS от сервера к их сети, TLS от их сети к клиентам, расшифровка между ними, чтобы они могли кэшировать и «оптимизировать» трафик. Хотя, как мы знаем, в случае с Discourse последняя часть работает не очень хорошо.
В основном это, хотя определённая польза от правила кэширования страницы для /uploads/ всё же есть: это поможет на какое-то время снизить нагрузку и позволит VPS начального уровня работать чуть дольше.