これは事実ではありません。
- 上記のコメントに添付したリンクは
git blameからのものです。ファイルの最新バージョン(関連行へのリンク)はこちらです:discourse_docker/templates/web.ssl.template.yml at 247c71a1e45d32b0b814a8e9d5fdaa4faaf727b9 · discourse/discourse_docker · GitHub - 友人の新しいサイトのインストールは1週間前に行われたものです。上記のテンプレートの37行目には
return 301 https://${DISCOURSE_HOSTNAME}$request_uri;とありますが、Discourse Dockerコンテナ内では、彼女のもの(および私のもの)の/etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.confはreturn 301 https://\u003cour_discourse_site\u003e;となっています。$request_uriが削除されていることに注目してください。(何が原因かはわかりませんが)。 - 調査の一環として、今朝シミュレートされた強制更新を実行しました。失敗しました。その後、
/etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.confを変更しました。成功しました!
実際にはこれで問題ありません。Discourseを更新するたびに 20-redirect-http-to-https.conf を手動で編集するだけです。このコメントに行き当たった人のために、実行するコマンドは次のとおりです。
cat > /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf << 'EOF'
server {
listen 80;
listen [::]:80;
location ~ /.well-known {
root /var/www/discourse/public;
allow all;
}
location / {
return 301 https://\u003cYOUR_FORUM_ADDRESS\u003e$request_uri;
}
}
EOF
この失敗の正確な原因はわかりませんが、上記のconfを変更すると修正されることはわかっています。しかし、letsencryptの更新がサイレントに失敗しなくなったように通知も変更したので、事前に警告を受けることができます。お知らせまで!