ちょっと待って…わかったような気がします…プロキシを無効化し、Cloudflare テンプレートなしで再構築しました。その後、再度プロキシを有効にしたら、Strict SSL で WordPress とフォーラムにアクセスできるようになりました！
「いいね！」 1
クラウドフレアテンプレートを使用しない場合、すぐにレート制限に引っかかる可能性があります。
Discourseは、同じIP（クラウドフレアプロキシ）から多くの人が登録していると判断し、レート制限を開始します。
うーん、では Let’s Encrypt のメールを省いて、Cloudflare テンプレートで再度やり直しましょう。Cloudflare テンプレートで再構築する際、プロキシは有効のままにしておくべきでしょうか？
これまでのサポート、本当にありがとうございます。私はどちらかというとクリエイティブなタイプなので……
「いいね！」 1
DNSだけでなく、レジストラの問題でもあります。別のDNSを使うために彼らが要求する高額な費用を支払う余裕がありません。なので、おっと、ですね。
「いいね！」 1
Discourse のセットアップでは、現在、証明書への登録にメールは不要です。これはしばらく前から変わっていません。yml を編集して SSL を無効にしない限り、常に HTTPS がデフォルトで有効になります。
Cloudflare を DNS として使用することと、オレンジ色のクラウドをオンにすることは完全に異なることです。上記の文脈における Cloudflare の使用は、彼らのプロキシと最適化を指しており、過去にいくつかの奇妙な問題を引き起こしたことがあります。しかし、彼らの DNS は問題なく、むしろ優れています。
Discourse のインストール自体を変更する必要はありません。現在は HTTPS が正常に動作しており、すべて問題ありません。SSL が動作しており、CloudFlare テンプレートが有効になっている場合は、変更を加えないでください。
問題は現在 WordPress 側にあるようです。どのようにインストールされていますか？単なる VPS でしょうか、それとも何らかの WordPress ホスティングサービスを利用していますか？
これは非常に一般的な構成です。簡単な修正で解決できると確信しています。
これは非常に悪い考えです。Discourse が Let’s Encrypt から証明書を登録すると、更新は異なるメカニズムを通じて自動的に成功します。サーバーと CDN 間の TLS を無効にする必要はありません。
上記を考慮して、なぜそのようなことをする必要があるのでしょうか？すべてのトラフィックに対して UFW ルールの追加処理によるローカル負荷の増加に加え、ルールが古くなるリスクがあり、ネットワークエラーの原因になりかねません。Cloudflare は定期的に新しい IP 範囲を導入しており、ユーザーがサイトにアクセスできなくなった時点で初めてそのことに気づくことになります。証明書の登録を完了させ、Cloudflare を使用したい場合は、ページルールを適切に調整してください。
「いいね！」 4
DNSのみモードでCloudflareを使用しています。これは非常に簡単です。DNSコントロールパネルで「オレンジ色の雲」をオフにするだけで、雲がグレーになります。それだけです。
「いいね！」 6
以前は通用していましたが、今はもう機能しません。Let’s Encrypt を使いたくない場合は、discourse-setup ではなく手動で設定する必要があります。
「いいね！」 1
つまり、LE メールが存在しない場合、Discourse はどのような証明書を取得するのでしょうか？自己署名証明書でしょうか、それとも任意のメールアドレスで発行された証明書でしょうか？
いずれの場合でも、Cloudflare の SSL 設定（フル SSL 以上）では有効な証明書を持つホストが許可されているため、問題なく動作するはずです。
ソースを確認する必要があります。正確には覚えていませんが、管理者のメールアドレスを使用すると思います。サーバーがポート 443 で利用可能かチェックする際に失敗すると、インストールを拒否します。
完全に間違っているかもしれませんが、このコード
read_config "LETSENCRYPT_ACCOUNT_EMAIL"
local letsencrypt_account_email=$read_config_result
if [ -z $letsencrypt_account_email ]
then
letsencrypt_account_email="me@example.com"
fi
if [ "$letsencrypt_account_email" = "me@example.com" ]
then
local letsencrypt_status="ENTER to skip"
else
local letsencrypt_status="Enter 'OFF' to disable."
fi
を見ると、デフォルトの構成チェックでは Let’s Encrypt を無効にするために「off」と入力するオプションを提供すべきではないでしょうか？もしかしたら私が完全に間違っていて、全く違う場所を見てしまっているのかもしれません。
Let’s Encrypt の無効化は解決策ではありません。
標準インストールでは、それは該当しません。
高度なインストール（例：リバースプロキシを使用している場合）では、完全に答えとなります。
「いいね！」 1
なぜそうなのか、詳しく教えていただけますか？
証明書シナリオを動作させるのは簡単です。同じサーバー上で 2 つ目の Web サーバーを運用し、ローカルでプロキシを介する場合でも、証明書を動作させることは容易です。それなのに、なぜそうしないのでしょうか？
なぜ複数の証明書を取得する必要があるのでしょうか？
リバースプロキシ（例：nginx、caddy）を通じて letsencrypt から単一の（統合された）証明書を取得できるのに、Discourse コンテナ内で 2 番目の証明書を取得しても、何にも使用されないのに、なぜ必要なのでしょうか。
「いいね！」 2
可能であれば、プロキシの複雑さを完全に避けるのが一般的な解決策だと思います 
「いいね！」 3
しかし、標準的な1〜2コンテナ構成を超えたデプロイメントを検討し始めると、これは避けられません。
フォーラムが非常に大きくなると、Cloudflare のプロキシのようなものが必要になる場合があります。フォーラムがオーバーフローし始めたら、検討すべき事項です。大規模なフォーラムを Discourse に移行する場合を除き、Discourse をインストールする人がそれを考える必要はありません。
本当に同意できません。HTTPS を正しく設定するのは簡単です。この場合、ユーザーは単一のドメインの下に 2 つの異なるサーバーで 2 つのサイトを運営しています。
CloudFlare が有効かどうかに関わらず、両方のサイトを HTTPS で提供できない技術的な理由はありません。Let’s Encrypt が使用する登録方法と、Discourse 向けに CloudFlare を調整する方法を理解すれば、簡単に設定できます。CloudFlare には、まさにこのシナリオのために用意された完全な HTTPS モードがあります。サーバーから CloudFlare のネットワークへ TLS、CloudFlare のネットワークからクライアントへ TLS、その間で復号化してキャッシュや「最適化」を行いますが、Discourse の場合、最後の部分はあまり機能しないことは知られています。
主にこれが理由ですが、/uploads/ に対するページルールによるキャッシングにも確かにメリットがあります。これでしばらくは負荷を軽減でき、低スペックな VPS の寿命を少し延ばすことができます。
「いいね！」 2