ありがとうございます。DOですが、SSL設定をさらに見直します。Full-strictではなくFullになっており、これがletsencryptと相互作用していると考えています。
BotおよびAI-Botの緩和策と、非常に特定のジオサーバーブロックを有効にしました。
ええ、変ですよね。私のサイトのいくつかはフル、いくつかはフルストリクトを使用しています。すべて同じウェブサーバーで実行されているのに、かなり奇妙ですよね（笑）。CFをオンにする際は数時間ごとにチェックし、VPNを試してISPのDNSキャッシュなどをバイパスしてください。私のサイトの1つは、厳格なSSLのみオリジンプルを使用しており、それ以外ではエラーが発生するようです（笑）。SSLエラーが発生した場合は、機能するものに変更してそのままにしておきます。約30のウェブサイトのうち、すべてにCFを適用した場合、1日かそこら後にその設定を調整する必要がありました。
VPN経由でブラウジングしていて、SSLエラーには遭遇していません。
Qualysで確認したところ、4回ともB評価でした。
この間、IPは保護されていませんでした。
ということは、途中にCF（Cloudflare）を入れると、直接IPにヒットすることはなくなりますが、これで合っていますか？
まあ、そんな感じです。サイトやデータベースに直接攻撃することはできません。しかし、DNSの履歴は公開されています。そのため、IPアドレスに対してDDoS攻撃を行うことは可能です。通常、IPが何をホストしているかを知らない場合、特定のIPを狙ったDDoS攻撃は稀だと思います。何に影響を与えているかの結果が見えないため、DDoS帯域の無駄遣いです。
「いいね！」 1
すごい。あなたの最後のダッシュボードグラフは私のものと驚くほど似ています。タイミングも同じかもしれませんね。
こちらも2つのフェーズがあります。
数日間続く最初の増加は、心地よいトラフィックの増加のように見え、その後フェーズ2の急増が続きます。
もし見ることができれば、トラフィックの主な地理的位置はどこですか？
「いいね！」 1
ファーウェイは2019年以降、AIハブとしてシンガポールへの投資を開始しました。
同じシンガポールのファーウェイASNが、メキシコと香港のトラフィックで関与してきました。
それはどのように機能しますか？場所のなりすましですか？
「いいね！」 1
「other」列も、個別に見てみてください。
DDoS攻撃を受けていなくても、Cloudflareのコミュニティ（discourse）フォーラムに投稿されたこのガイドは、焦点を絞り、取り組むべき可能なアクションポイントとして役立つことがわかりました。
https://community.cloudflare.com/t/mitigating-an-http-ddos-attack-manually-with-cloudflare/302366
ピークトラフィックが発生した際、直帰率が80%を超えて急上昇しました。通常、通常のトラフィックでは直帰率は20%台前半から半ばです。
奇妙なことに、ある日のトラフィックで再び直帰率が80%近くまで跳ね上がっているのですが、今回は急増はありません。トラフィックレベルは通常、つまり急増前と同じように見えます。
急増時には「平均エンゲージメント時間」が劇的に低下しましたが、今回も同様に低下しています。私は通常その指標を見ませんが、あなたがグラフを投稿してくれたので見ました。これ（平均エンゲージメント時間）か直帰率が、トラフィックの質や種類に何か異常があることを示す良い警告になると考えます。
「いいね！」 1
私の解決策は、ポルトガル語を話さないすべての国をジオブロックすることでしたが、私の国、アメリカ、ドイツからは依然として大量のトラフィックを受けています。ブラジルがこの種の攻撃の最大の発生源であるようです。そのため、私の試みは失敗でした。アクティブなメンバーは20人いますが、月間200万件のリクエストがあります。信じられないことに、プラグインを無効にしても、私のインスタンスはフェディバースからのトラフィックを受け取り続けています。私はもう疲れましたし、どう解決すればいいのか全くわかりません。
「いいね！」 1
Cloudflareの緩和策に関して、私にとって効果的だったのは以下の通りです。
WAFルール 1)
ASN - JSチャレンジ適用済み / ASN = 136907
（トラフィックの多い順のロケーション）
- シンガポール
- 香港
- メキシコ
@piffyさんのような方も、同じASNからのアクセスを受けていないか確認してみてください。これはGoogleアナリティクスでは実際のトラフィックのように見えましたが、直帰率が80%以上に跳ね上がり、ユーザーエンゲージメントが崩壊しました。私が知る限り、AdSenseのRPM/CPCを台無しにするでしょう。
WAFルール 2)
地域別JSチャレンジ適用済み（トラフィックの多い順）
- シンガポール
- 香港
- メキシコ
Cloudflareのサービス提供に新たな増加が見られ、再び同じ地域が上位を占めていたため、これら上位3つの問題のある地域に地域別JSチャレンジを適用しました。
これは、アナリティクス/ユーザーエンゲージメントの指標の健全性を回復することを主な目的とした対策です。CFがキャッシュやボット攻撃の管理を通じて多くの処理を行っているため、このトラフィックはもはやサーバーに負荷をかけていませんが、全体的に指標がひどく乱されています。これは悪質なトラフィックです。
アナリティクス指標やAdSenseなどに改善が見られれば、更新します。
「いいね！」 1
それを実行し、しばらくの間、他のルールを有効にしてすべての国をブロックしました。チャレンジは十分で、攻撃元が遅くなったようです。
これで、エンゲージメント率が131%増加し、拒否率が16%低下しました。Playストアが影響していると推測されるため、この増加がボットによるものか、正当なトラフィックによるものかを確認するために、しばらく数週間待つ必要があります。
「いいね！」 1
WAF RuleNo.2 は、Geo適用JSチャレンジを使用して余分なトラフィックを抑制しました。
以前の比率は約 4:1 でした。
Cloudflare:OriginServer
現在は 1:1 に近いサービス提供となっています。
これらの地域からは依然として大量のトラフィックが送信されていました。
アナリティクスは異常アラートを吐き出し、アナリティクスのメトリクスは依然として混乱していました。
Adsense はひどい状態になり、急増によりページ RPM はほぼ .00c になりました。Adsense はこれを疑わしいトラフィックとして検出し、計測を停止したのだと思います。
急増前の増加（青）が見られますが、その時点でもRPMは崩壊していましたが、スーパーページビューの急増（青）はページRPMを完全に底上げしました。過去30日以上は非常に安定したページビューとパターンでした。
ダッシュボード
ダッシュボードビューは以下のようになりました。CFの緩和策がこの時点から展開されたため、過去5日間は低くなっています。そうでなければ、このトラフィックが増加し続ける理由はまったくありませんでした。
参考までに、最もトラフィックが多かった日のその他（赤）のページビューのトラフィックは、匿名（緑）のページビューのほぼ10倍でした。よく考えてみてください。 
今後2〜3日でバランスが取れることを願っています。
「いいね！」 1
JavaScriptの課題は、マネージドなものと同じ効果が得られないことです。私はメディアやCSS、JSのようなライブラリにホットリンクブロックを適用することで、ほぼ同じ効果を得ました。これはリファラーからのみ機能し（タブから直接アクセスするとブロックされます）、帯域幅とCPUの使用量を削減するのに役立ちました。
「いいね！」 1
JSチャレンジは、これまでのところCSR（チャレンジ解決率）が**0%**であるため、しばらくの間そのままにしておきます。
より多くのトラフィックが処理され、かつ/またはCSRが変動し始めたら、マネージド（Managed）を試してみるつもりです。
現時点では、CF:OSの提供比率はさらに厳密な1:1の比率になっているようです。
緩和されたトラフィックがその代わりを占め、急増しています。
疑問に思うのは、JSによって一定期間後にブロックされているのに、なぜ攻撃が続くのか（結局、それほど高度ではないのか？）ということです。また、他のASNや地理的ロケーションを経由して侵入しようとする試みがあるのでしょうか？
もしそうなれば、新たな攻撃ベクトルに対してはマネージドを試します。
「いいね！」 1
「JSチャレンジ」は「マネージチャレンジ」と同じ目的を持ちながら、効率が最も悪いため、おそらく非推奨になっているのだろう。このオプションは、マネージドのようにキャプチャを表示せず、正当なトラフィックとして破棄するだけだからだ。
metaで、このトピックを見つけました。これは非常に興味深く、独自のトピックとして扱うのが最善だと思われます。Cloudflare Security WAF (Web Application Firewall) + Discourse?
役立つ可能性のある別のリソース - https://radar.cloudflare.com/
トピックを更新すると言ったので、ここに更新があります。
全体として、無料ティアのCloudflareによる軽減策は、現時点、つまり当面の短期的な解決策として非常にうまく機能しました。
ある意味では、CloudflareがDiscourseで使用しても問題ないことを知っていればよかったのですが、どういうわけかそれを見逃していました。
Cloudflareを使用したさまざまな軽減策により、シンガポール、香港、メキシコのトラフィック（おそらく偽装）からの偽のトラフィックがほぼ即座に停止しました。
昨日と今日は、同じトラフィックソースが試みるのをやめたように見える傾向が見られ、ボリュームが劇的に減少しました。これは、諦めるまでに要した時間です。
しかし、まだ始まったばかりです。
また、他の短時間のバースト攻撃/ボットトラフィックもより簡単に特定できます。
Cloudflareはこれらの攻撃を約30〜60分後に軽減すると思いますが、これらのCloudflareが提供するサージに焦点を当てるべきであり、ソースASNまたは地理的位置を特定し、ブロックリストまたはWAFルールに追加することをはるかに容易にします。
レーダーリンク https://radar.cloudflare.com/bots/ は、ASNの品質を評価するのに非常に役立ちました。WOWサーバーのスウォームをいくつか選びましたが、これはWorld Of Warcraftサーバーだと思いますか？ 
それがサージで繰り返し表示されていました。
トラフィックが通常のレベルに戻り、より安定して均一なリズムになったことにも気づきました。
AdSenseの指標はほぼ正常に戻ったか、少なくとも回復しています（つまり、低いRPMはRPMがないよりはましです！） 
これはおそらく、サーバーにこれほど大きなプレッシャーがかかり、サービスが苦労しているのを見たのは初めてでした。この場合、サーバーのIPを変更するなどの他の軽減策を除けば、全体として迅速な解決策およびその場の管理ソリューションとしてCloudflareは素晴らしかったです。特に、nginxなどと格闘する時間やスキルがない場合、成長する攻撃下で、最小スペックのドロップレットをアイドルに近い状態で実行させ、スペックを超えるヘッドルームを与えることができました。