Что говорит лог production.log (в запущенном Docker-контейнере), когда вы пытаетесь войти с ошибкой (при этом force_https=true)?
@RGJ – Мне нравится ваше решение! Нужно ли мне принудительно включать HTTPS с помощью последнего предложения? Касательно proxy_pass https.
РЕДАКТИРОВАНИЕ: Я получаю ошибку 502, если просто использую proxy_pass https://192.168.86.108.
РЕДАКТИРОВАНИЕ 2: Я закрыл порт 80 в Discourse через app.yml, но это всё равно не работало — я только что перечитал ваш пост. Есть ли у контейнера Discourse собственный экземпляр Nginx? То есть, по сути, я передаю прокси прокси? Извините, я сейчас действительно запутался.
@itsbhanusharma, мне закомментировать 80:80 #http и последовать совету @RGJ, используя proxy_pass https?
Почему вы не следуете здесь поддерживаемому процессу для мультисайта? Вы по сути изобретаете очень хрупкое колесо.
Сейчас предоставлено так много ссылок, @Stephen, что я растерялся и не могу во всём этом разобраться. Я думал, что следую поддерживаемым процессам. Разве комментарии выше не поддерживаются? 
Да, потому что вы не использовали force_https, отсюда и тег unsupported-install выше. Если вы отклоняетесь от поддерживаемого пути, вы не получите особой помощи.
Начните здесь:
Существует отдельное руководство по обработке инкапсуляции SSL для многосайтовых конфигураций.
Итак, стандартный контейнер работает только с http? Как то, что я пытаюсь сделать, связано с несколькими сайтами? Я не пытаюсь разместить несколько доменов, у меня один домен. Не могли бы вы прояснить, как это решает мою проблему?
Что вы имели в виду, сказав:
Я уже настроил серверы Discourse примерно в 5 случаях, и все они проявляют странное поведение; не уверен, действительно ли это ошибка или у кого-то ещё был подобный опыт.
Независимые инфраструктуры, никак не связанные друг с другом.
Но все с очень похожими настройками, как указано выше.
Так почему же nginx вообще проксирует хост? Что ещё происходит на машинах?
У нас есть несколько ВМ, которые не доступны извне; трафик маршрутизируется через прокси (который доступен извне) к внутренней ВМ Discourse. Аналогичная ситуация в каждой из отдельных установок. Это проясняет?
Не совсем, но так или иначе это технические неудобства, с которыми вам придется смириться. Невозможно сказать, есть ли лучший подход, когда случай использования и топология настолько неоднозначны.
Я считаю, что правильное сочетание решений было следующим:
Как указал @itsbhanusharma:
РЕДАКТИРОВАТЬ /var/discourse/containers/app.yml и изменить порты на пользовательские, я использовал:
- "8080:80" #http
- "4343:443" #https
Выполнил ./launcher rebuild app
Затем я изменил наш внешнедоступный прокси-сервер для перенаправления запросов с 80/443 на http://internal_ip:8080.
После выполнения sudo nginx -t и sudo systemctl restart nginx я вошел в систему на сервере https://discourse.mobiusnode.io (который все еще демонстрировал вышеуказанные проблемы) и включил force_https, после чего, похоже, все начало работать.
Теперь я собираюсь воспроизвести это на оставшихся серверах/инфраструктурах.
Чтобы прояснить ситуацию: это не то, что я предлагал.
Я лишь попросил вас открыть порт 80 на локальном IP-адресе и завершить SSL-соединение на вашем обратном прокси-сервере.
Так, не использовать SSL на моем внешнем прокси, а перенаправлять обычные http-запросы на сервер Discourse и позволить force_https обрабатывать эти запросы? Как тогда передается сертификат? Через первый экземпляр Nginx? Вот здесь у меня всё ломается.
Что ж, главное, чтобы это работало, и вы могли бы чисто восстановить или обновить систему. Похоже, вы уже делаете то, что предложил @itsbhanusharma в своём последнем сообщении.
Если вы используете один IP-адрес для нескольких SSL-соединений, на передней панели вашего прокси-сервера должен быть установлен SAN-сертификат. Если сеть защищена, все остальное за ней может быть не зашифровано.
Для Discourse необходимо включить параметр force_https, если пользователь подключается через SSL, и вам нужно убедиться, что упомянутый выше заголовок сохраняется и передаётся дальше.
Нет, существует технология под названием SNI (указание имени сервера).
Я прекрасно понимаю, но раз все сертификаты выдаются Let’s Encrypt, какой смысл запрашивать отдельные сертификаты? Let’s Encrypt поддерживает SAN, так почему бы не использовать эту возможность?