force_https=true でログインに失敗した場合（つまり、ログインに失敗した場合）、実行中の Docker 内の log/production.log には何と表示されますか？
@RGJ – あなたの解決策が気に入りました！最後の提案で force-https を行うべきでしょうか？proxy_pass https についてです。
編集: proxy_pass https://192.168.86.108 だけを実行すると、502 エラーが発生します。
編集2: app.yml を通じて Discourse のポート 80 を非表示にしましたが、まだ動作しませんでした。あなたの投稿を再確認しましたが、Discourse コンテナには独自に Nginx のインスタンスが存在するのでしょうか？つまり、実質的にプロキシをプロキシに渡していることになりますか？申し訳ありませんが、この時点で本当に混乱しています。
@itsbhanusharma 80:80 #http をコメントアウトして、@RGJ のアドバイスに従い proxy_pass https を使用しますか？
なぜここではマルチサイトのサポートされた手順に従っていないのですか？非常に不安定な車輪を再発明していることになります。
Stephen さん、リンクがあまりにも多く提供されているため、すべてを理解することができません。サポートされているプロセスに従っているつもりだったのですが、上記のコメントはサポートされていないのでしょうか？
はい、force_https を使用していなかったため、上記の unsupported-install タグが付いています。サポート可能なトラックから外れると、あまり支援を受けられません。
こちらから開始してください：
マルチサイトでの SSL カプセル化を処理するための別のガイドがあります。
では、標準コンテナは http のみを実行するのでしょうか？私が行おうとしていることがマルチサイトであるとはどのように理解すればよいのでしょうか？私は複数のドメインをホストしようとしているわけではありません。単一のドメインしか持っていません。それが私の問題にどのように対応するのか、詳しく説明していただけますか？
「私は現在、Discourse サーバーを約 5 インスタンスセットアップしており、すべて奇妙な動作を示しています。これが実際にバグなのか、それとも他の誰かにも同じ経験があるのか、わかりません。」という意味は何ですか？
互いに一切接続されていない独立したインフラストラクチャです。
ただし、上記の通り、すべての設定は非常に類似しています。
では、なぜ nginx はホストをプロキシするのでしょうか？マシン上では他に何が行われているのでしょうか？
外部に公開されていない複数の VM があり、トラフィックはプロキシ（外部に公開されています）を経由して、内部の Discourse VM にルーティングされます。各インストールでも同様の状況です。これで明確になりましたか？
正直なところ、これは技術的な課題であり、いずれにせよ受け入れるしかありません。ユースケースやトポロジーがあまりにも曖昧なため、より良いアプローチがあるかどうかについてコメントすることは不可能です。
適切なソリューションの組み合わせは以下の通りだと考えられます：
@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 を有効にしました。これで、すべて正常に動作しているようです。
現在、残りのサーバー/インフラストラクチャでもこれを再現しようとしています。
はっきりさせておきますが、これは私が提案したものではありません。
私が求めたのは、ローカル IP 上でポート 80 を公開し、リバースプロキシで SSL を終端することだけです。
つまり、外部向けのプロキシでは SSL を使用せず、代わりに通常の http リクエストを Discourse サーバーに転送し、force_https でそれらのリクエストを処理させるということでしょうか？その場合、証明書はどうやって渡されるのでしょうか？最初の Nginx インスタンスを介してですか？ここが私にとって理解できない部分です。
まあ、動作していて、クリーンに再構築やアップグレードができるのであれば問題ありません。あなたは @itsbhanusharma が最新の投稿で提案したことをすでに行っているようです。
複数の SSL 接続を単一の IP で共有する場合は、プロキシのフロントエンドに SAN 証明書が必要です。ネットワークが安全であれば、その背後にある他のすべての通信は暗号化されていないままで構いません。
Discourse では、ユーザーが SSL 経由で接続する場合は force_https が必要であり、上記のヘッダーフラグが保持され、転送されるようにする必要があります。
いいえ、SNI というものがあります。
そのことは十分承知していますが、すべての証明書がLet’s Encryptから発行される場合、個別の証明書を取得することにはどのような価値があるのでしょうか？LEはSAN（サブジェクト代替名）をサポートしていますから、それを使わない理由は何でしょうか？