インスタンスのリンクの1つはこちらです:
https://discourse.mobiusnode.io
オフになっています。X-Forwarded-Proto はサーバーブロックに含まれています。そのため、あなたが共有してくれたリンクに基づくと、私がまだ採用していない要素は以下の通りです:
# 使用するベーステンプレート; コンテナごとの機能を減らすために一部を除外可能:
# - "templates/cron.template.yml" # cron は現在ベースイメージに含まれている
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/sshd.template.yml"
- "templates/web.template.yml"
# - "templates/web.ssl.template.yml" # 削除 - https は外部の nginx で処理される
- "templates/web.ratelimited.template.yml"
- "templates/web.socketed.template.yml" # <-- 追加済み
# どのポートを公開するか？
# expose: セクション全体をコメントアウト
3 つのブラウザ（Edge、Firefox、Chrome Mobile）でサイトを読み込みましたが、匿名でも完全に正当な証明書が表示されます。この現象を再現するための手順を教えてください。
ユーザーとしてサインアップし、サインインすると、以前報告されたエラーが発生し、状況が混沌とします。
わかりました、今すぐ Firefox で架空のユーザーとしてサインアップします。
メールが受信トレイに届きません。再送を試みましたが、効果はありませんでした。ここではアカウントの手動アクティベーションのみを行っているのでしょうか？
いいえ。おそらく Junk または Spam フォルダに移動したのでしょう。その方面からのユーザーからの苦情はありません。
地獄が開け放たれたわけではありません。考えられる問題の一つは、メールにまだ http:// リンクが含まれていることです。ただし、アカウントの活性化時には正しく https サイトへリダイレクトされ、SSL 関連のエラーも確認されません。
というわけで、はい、force_https が有効になっていないか、インストールに何か非常に重大な問題があり、これが原因だと 99% 確信しています。
サーバーブロックにリダイレクトを設定しているため、そこに表示されるリンクは問題ありません。常に HTTPS にリダイレクトされます。
それはあなたの誤りです。「HTTPS 強制」が有効になっている場合、Discourse はすべてのリンクを HTTPS として送信する必要があります。フォーラムに関連するすべてのリンクは HTTPS で読み込まれなければなりません。もしあなたが依然として奇妙なことを続け、推奨される方法に従っていないのであれば、それはあなたの自己責任です。標準的な手順（機能するもの）を超えてお手伝いすることはできません。
それは私にはあまり意味がわかりません。論理的に分解すると、私は本質的に force-https が意図していることをサーバーブロックで行っていることになります。
また、force-https を有効にするとサイトが機能しなくなり、ユーザーが認証できなくなります。
force_https は単なる書き換えではありません。内部的にはそれ以上の処理を行います。ご自身の問題を解決したい場合は、すでに解決策が提示されています。その解決策を拒否されるのであれば、ご自身で対応し、新たな道を探求されることをお勧めします。
これは、不安定なリバースプロキシが原因です。何が問題なのかを特定し、適切な方法で対応する必要があります。ご自身で構築されたソリューションに関するサポートは提供できません。
提示されたすべての「解決策」は、私の特定のユースケースには適合しません。
- リモートサーバー（同じネットワーク内）：すべての例が、Nginx と Discourse が同じサーバー上で動作していることを前提としているように思われますが、私は別の内部 IP にアクセスするために
proxy_pass を使用しています。
なぜこのような設定にしたのかというと、セキュリティの向上とリソースの分散のためです。これは、サービスをコンテナと VM の 2 つの方式に分割しているのと同じ理由です。提示されたドキュメントは、すべてのサービスが同じサーバー上で動作している状況を前提としているように見えます。
上記のような状況は、かなり一般的であると考えられます。もし上記の条件のいずれかが proxy_pass の状況に対応できるのであれば、私の設定を適宜調整することに喜んで対応します。ただ、「すべての卵を一つのバスケットに入れる」ことを避けようとしているだけで、「あとはご自身で」というような包括的な声明を提示されるのは、少し行き過ぎだと感じています。
proxy_pass 192.168.20.10:8080
Discourseでは、192.168.20.10:8080:80を公開
ソケット化されたテンプレートを削除
force_httpsを有効化
これで完了です。
これは、あなたが書かれたこと以上の多くの含意を持っていますが、私はそれを調査する必要があります——私たちはそこで始めてもよかったかもしれません。
即座の疑問点:
- app.yml でデフォルトのリスニングポートを 8080 に変更しますか？
- SSL 443 はどうしますか？443 のままにしますか？
- Nginx サーバーブロックでポート 80 のリダイレクトを削除しますか？
- #3 は、内部側で
proxy_pass を変更するだけなら関係ありますか？おそらく関係ないですよね？単に 8080 に再ルーティングするだけですから？
- 最大の疑問：なぜ？80 から 8080 に変更することで、なぜ違いが出るのでしょうか？
- 他のすべてのテンプレートをアクティブなままにしますか？
socketed のみをコメントアウトしますか？
お手伝いと根気強い対応に感謝します。
それはあなたの好み次第です。私は例として書いただけです。80 を公開することを選んでも構いません。
ローカルネットワーク上で SSL を有効化することには、メリットも意味もありません。
それは存在する必要があります。
server {
listen 80;
server_name discourse.example.com;
return 301 https://example.com$request_uri;
}
まさにそれが起こっています。プロキシ/イングレスが受信するすべてのリクエストを、8080 ポート（つまり Discourse）にある内部バックエンドへ転送しています。
#1 で回答済みですが、これは個人の好みです。好きなポート番号を選んでください。
内部サーバーでは、ソケットや SSL に関連するものは特に必要ありません。SSL はリバースプロキシで適切に終端されるべきです。
注：これらは顧客向けデプロイに基づいた個人の好みが大半を占めています。
わかりました。コメントありがとうございます。
参考までに、私の Nginx サーバーブロックを以下に示します：
server {
# ssl
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name discourse.mobiusnode.io;
location / {
#http トラフィック
proxy_pass http://192.168.86.108;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
ssl on;
ssl_certificate /path/to/certificate/domain.io/fullchain.pem; # Certbot によって管理されています
ssl_certificate_key /path/to/certificate/domain.io/privkey.pem; # Certbot によって管理されています
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
add_header Strict-Transport-Security "max-age=63072000;";
ssl_stapling on;
ssl_stapling_verify on;
client_max_body_size 0;
}
server {
if ($host = discourse.mobiusnode.io) {
return 301 https://$host$request_uri;
} # Certbot によって管理されています
listen 80;
listen [::]:80;
server_name discourse.mobiusnode.io;
return 404; # Certbot によって管理されています
}`
上記の条件の下で、私が経験している動作は以下の通りです。
app.yml の冒頭は次のようになります：
## これはオールインワンのスタンドアロン Discourse Docker コンテナテンプレートです
##
## このファイルを変更した後、必ず再構築してください
## /var/discourse/launcher rebuild app
##
## 編集時は非常に注意してください！
## YAML ファイルは空白やアライメントの誤りに極めて敏感です！
## 必要に応じて http://www.yamllint.com/ を訪れてこのファイルを検証してください
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Lets Encrypt (https) を追加したい場合は、以下の 2 行のコメントアウトを外してください
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"
## このコンテナが公開すべき TCP/IP ポートはどれですか？
## Discourse を Apache や nginx などの他のウェブサーバーとポートを共有させたい場合は、
## https://meta.discourse.org/t/17247 を参照してください
expose:
- "80:80" # http
- "443:443" # https
params:
db_default_text_search_config: "pg_catalog.english"
## db_shared_buffers を総メモリの最大 25% に設定します。
## ブートストラップによって検出された RAM に基づいて自動的に設定されますが、上書きすることも可能です
db_shared_buffers: "1024MB"
## ソートパフォーマンスを向上させることができますが、接続ごとにメモリ使用量が増加します
#db_work_mem: "40MB"
## このコンテナが使用する Git リビジョンはどれですか？（デフォルト: tests-passed）
#version: tests-passed
RGJ
(Richard - Communiteq)
39
2 番目の nginx のポート 80 に接続しているため、nginx は HTTP 接続と認識し、HTTPS 接続とは認識していません。
内部の nginx で X-Forwarded-Proto を探し、proxy_set_header X-Forwarded-Proto $thescheme; を proxy_set_header X-Forwarded-Proto https; に変更してください。
または、トラフィックを HTTPS に転送するよう設定してください：proxy_pass https://192.168.86.108
