proxy_set_header X-Forwarded-Proto https; でシンプルに機能しますか？
http/s リクエストは、インターネット上の Discourse ID 用のコンテナから IDP サーバーに送信されます。リクエストヘッダーを追加/変更できるインスタンスは間にありません。
私の意見では、「Discourse ID」が標準的な OAuth であると仮定すると、正しい方法は次のいずれかになります。
a) Discourse ID の設定オプションで、「よく知られた」設定エンドポイントを追加できるようにする。このエンドポイントには、"https://… プレフィックスを含む、必要な OIDC 設定値がすべて含まれます。
b) 同じですが、コードに既にハードコーディングされています。
Discourse ID の技術的な詳細については、まだ調べています…
Discourse ID の詳細はコードで確認できます。使用しているプロトコルはすべて Github リポジトリに記載されています。他の OAuth 実装との唯一の違いは、インスタンスを自動登録することです。そして、その自動登録中に、登録をリクエストしているインスタンスが本人であり、https に接続されていることを確認します（今日では、Discourse インスタンスは http:// に接続されるべきではありません）。
上記で共有した http エラーは、サイトが正しく設定されていないことを示しています。
コンソール経由で以下の出力を確認できますか？
Discourse.base_url
SiteSetting.force_https
最初のコマンドで http:// URL が返され、2 番目のコマンドで false が返された場合、SiteSetting.force_https = true を設定して問題が解決するかどうかを確認することをお勧めします。（ただし、他の場所の設定が間違っている場合は、問題が発生する可能性もあります。ご注意ください。）
「いいね！」 1
Penar様
まず、私のセットアップの詳細を明確にする必要があるかもしれません。これは標準的なデプロイメントとは少し異なります。
- SSLアクセラレータとして機能する中央ロードバランサー（https://www.haproxy.org/）（複数のWebサービス用であり、Discourse専用ではありません）。インターネットからこれらのサービスへのアクセスはhttps経由のみ許可されています。httpからhttpsへの切り替えはロードバランサー自体で行われます。詳細はhttps://www.haproxy.com/blog/redirect-http-to-https-with-haproxy を参照してください。
- HAProxyは、プライベートネットワーク（10.x.x.x）上のバックエンドにフロントエンドリクエストを転送しますが、暗号化は行いません。このトラフィックは、Dockerホスト上のローカルnginxで終了します。
- nginxは、
proxy_pass ``http://unix``:/mnt/data/discourse/shared/web-only/nginx.http.sockを使用して、Web_onlyコンテナのhttpソケットにリクエストを転送します。
（web_only.ymlおよびdata.ymlを使用した2コンテナセットアップを使用しています）。詳細はtemplates/web.socketed.template.ymlを参照してください。
https暗号化はすべてDiscourseコンテナの外部で行われるため、SiteSetting.force_https は必要ありません。すでにhttps://meta.discourse.org/t/discourse-openid-connect-oidc/103632プラグインと独自のIDPに基づいたOAuthを使用しています。Discourse OIDCプラグインには、「well-known」 OpenID Connect discovery document の設定が含まれています。私の場合は次のようになります： https://login.netzwissen.de/realms/netzwissen/.well-known/openid-configuration
Discourse IDが、DiscourseコンテナインスタンスとDiscourse ID IDP間のリンクのために同様のものを実装すれば、問題は発生しないでしょう。「Discourse ID」は固定IDPを使用するため、このような「well-known URL」は、httpsプレフィックスを含めてハードコードすることさえ可能です。
トーマス、申し訳ありませんが、あなたの特定のセットアップについては実際にお手伝いできません。あなたのインスタンスのどこかが間違っているとしか言えません。
あなたのサイトのJSコンソールは、コンテナ外でのhttps暗号化がすべてをカバーしているとは考えていないようです。上記で共有したJSの警告は、IDであなたが抱えている問題と同様の症状であり、あなたのセットアップにおけるディスコース自体は http で実行されていると考えており、それは問題です。なぜなら、それは場合によってはhttpでURLを生成するからです。
「いいね！」 2
大変申し訳ありません。
本番環境（PROD）の設定と開発環境（DEV）の設定を比較しました。開発環境では force_https 設定が無効になっていました。これは、SSL haproxy SSLアクセラレータが前面にあったため、機能していました。
現在、開発環境で SiteSetting.force_http を有効にし、Discourse ID は正常に動作しています。そのため、本番環境（forum.netzwissen.de）にも Discourse ID をデプロイします。
混乱させてしまい申し訳ありませんでした。
「いいね！」 3
心配いりません、解決してよかったです。フォローアップありがとうございます！
「いいね！」 2