お役に立てれば幸いですが、こちらにCloudflareのパフォーマンスとセキュリティ設定に関する一般的なガイドも作成しました。
Cloudflareのスタッフメンバーもコメント欄でいくつかのヒントや修正を追加してくれました。
そのガイドを更新中で、Discourseから何か新しいアドバイスがないか探していたところ、このページを見つけました。
これらを私の管理対象ルールに追加する予定です。ありがとうございます！
こちらがカスタムルールの概要です。これはスパムを大幅に減らすのに役立っており、多くの場合（常にではありませんが）、最も質の低いトラフィックはVPNやDCトラフィック経由で入ってくるため、これらが役立っています。
ルールの完全な内容をまとめた正式な記事を作成する予定です。これらを約6か月間実行しており、Log Explorerツールを使用して一度に10kのイベントを検査することで、その成功を検証しています。
無料バージョンを使用して、新しい Discourse サイトで使用する前に Cloudflare の統合を理解しようとしています。具体的な内容や例を挙げて、これらについて詳しく説明していただけますか？Discourse サイトは「discourse.abc123.com」であると仮定します。
(1) Cloudflare は、現在設定しているオリジン Nginx のセキュリティヘッダーを削除するようです。
(2) 次のコメントの意味がわかりません。「CloudFlare CDN (オレンジ色の雲) を有効にすることにした場合、Discourse インスタンスのアドレスに対してページルールを設定するという、もう 1 つのステップを実行する必要があります。このルールは「パフォーマンスを無効にする」(そのオプションが見当たりません) に設定する必要があり、これにより、Discourse と干渉することがよく文書化されている CloudFlare の機能をオフにできます。」および dash.cloudflare.com/?to=/:account/:zone/rules で次のページルールを作成します。
community.example.com/session/* のキャッシュレベルを「バイパス」に設定する
入ってくる URL を正規化するようにルール設定を構成する
その他に注意すべき点があれば教えてください。
よろしくお願いします。
2025年の夏以来、CloudflareをリバースプロキシモードでDiscourseフォーラムの前に使用していますが、問題は発生していません。最近では、正常に動作させるために必要なDiscourse固有の設定はそれほど多くありません。
最も重要なことの1つは、app.ymlファイルにCloudflareテンプレートを含めることを確実にすることです。これを怠ると、実際の訪問者のIPアドレスではなく、CloudflareサーバーのIPアドレスしかDiscourseダッシュボードに表示されなくなります。
「/session/\*のキャッシュをバイパスする」ルールは、依然として必要のようです（新しいインターフェースではキャッシュルールとして設定します）。また、「投稿の作成/編集時にWAFをスキップする」ルールも間違いなく必要です（これはマネージドルールとして設定しています）。
主にWordpressサイトのコメントシステムとしてDiscourseを使用しているため、Webサーバーが訪問者が特定のWP投稿のコメントスレッドをリクエストしたときに発信する/wp-json/wp-discourse/v1/discourse-comments?post_id=xxxxのAjax応答に、Wordpressで60秒のTTLを追加しています。これは、訪問者の急増パターンを管理するのに役立ちます。/wp-json/wp-discourse/を含むURIに対してTTLを尊重するCFキャッシュルールを追加しました（エンタープライズアカウントがないと、Cloudflare経由でこれらのURLに短いTTLを設定できないため、mu-plugin経由でアプリケーションレイヤーでTTLを設定し、CFキャッシュルール経由でそのTTLを尊重するようにCFに指示します）。
それ以外では、スレッドの最初の投稿で言及されている基本的な設定を除けば、やることはほとんどありません。CloudflareはDiscourseと非常にうまく機能します。
こんにちは、設定したばかりですが、20分で完了しました。
私もCloudflareの無料プランを使用していますが、一部の設定が変更されました。Cloudflareダッシュボードの検索バーを使用すると、新しい場所が表示されます。私もいくつかの設定を見つけるのに問題がありました。
再構築が必要です
私は小黄云をオンにしただけで、何も操作をしていません〜時間があるときに設定して効果を見てみます。
以前言及したDiscourse + Cloudflare WAFに関する書き込みを完成させました。
私がDiscourseフォーラムで使用しているカスタムルールの完全なスタックをカバーしています。静的アセットと/message-busのスキップルール、スキャナー、ASN、ジオチャレンジのブロックルール、Discourse向けに調整されたレート制限、およびマネージドルールの例外です。
また、公式ガイドの投稿作成/編集式で明確化が必要なものを見つけました。正規表現の演算子 matchesはBusinessプランを必要とします。そのため、記事ではProプランで機能するstarts_withの代替手段を使用しました。
実際のトラフィックがあるライブフォーラムでテストしました。提案、改善、または設定で問題が発生した場合はお知らせください。
少し教えていただきたいのですが、この設定方法は、小黄云（Xiao Huang Yun）のみをオンにして、他はすべてデフォルト設定のままの場合と、どのような違いがありますか。よろしくお願いします。
良い質問ですね。オレンジ色のクラウドのデフォルト設定だけでも、DNS、CDN、DDoS保護、無料のマネージドルールセットが利用できます。これはしっかりとした基本であり、その設定だけでDiscourseは問題なく動作します。
多くの人がさらに踏み込む理由は、多くの場合スパムですが、帯域幅/サーバーリソースの浪費、および全体的なページの速度/読み込みパフォーマンスも挙げられます。
スパムに関して言えば、週に5〜10件のスパム投稿があり、時にはフォーラムで解決策を積極的に探すほど執拗でした。
これらのカスタムルールを導入して以来、それは月に2〜3件程度に減少しました。残っている主な問題は、捕まっても新しいアカウントで登録し続ける荒らしや迷惑行為が1〜2件です。しかし、それは別のトピックです！データセンターやVPNトラフィック、Tor、問題のある国に対するチャレンジング設定の組み合わせが大きな違いを生みました。
スパム以外には、ホスティングリソースの側面があります。ホスティングリソースが何に使われているかを正確に把握することは非常に重要です。自動化されたトラフィックやボットにリソースを提供しないことは、インターネット全体にとっても良いことです。
まず、堅牢で高速なホスティングを良いネットワーク上で確保することが最も重要です。その上にCloudflareを配置することで、サーバーから遠くにいるユーザーでも高速な体験を得られるようになります。キャッシングレイヤーはデフォルト設定でも役立ちますが、デフォルト設定を超えて設定を続けることで、パフォーマンスとセキュリティの両方が向上します。
デフォルトでは、Cloudflareは副作用なく有効にできる非常に安全な設定で出荷されます。しかし、デフォルトではオンになっていないが有効にしても安全な追加設定もたくさんあります。また、Cloudflareは「Discourseを実行している」や「WordPressを実行している」といった選択肢を選んでルールを自動構築するウィザードを提供していないため、カスタムルールはカスタムである必要があります。それは素晴らしい機能であり、次にCloudflareと話す際に提案するつもりです。
したがって、何を望むかによります。デフォルト設定で問題なく、スパムも問題なければ、これらすべてが必要ないかもしれません。
しかし、私の意見では、フォーラムに到達するものをより細かく制御し、ホスティングレイヤーからエッジに至るセットアップからあらゆるパフォーマンスを引き出したいのであれば、カスタムルールを導入する価値はあります。
