長年にわたり（そして読んだところによると、ここ数ヶ月ウェブ全体で体系的である）提起された懸念や問題に対処したことに基づき、そしてこうした問題の新たな波に直面しているため、
ログインのみをテストしましたが、これらのAIボットの波がさまざまなDiscourseのリソース/パスを攻撃しており、ページ/コンテンツが提供されている可能性があることに気づきました。
ログインのみが 完全なブロックであるかどうか、誰か確認できますか？
また、ログインのみの姿勢で全キャッシュをパージした後でも、キャッシュに関して別のエントリーアングル（相互作用）はありますか？
具体的にどのパスですか？アクセスされたものはすべてログインにリダイレクトされるはずです。
はい、ログインのみとは、サイトにアクセスする唯一の方法がログインすることであることを意味します。人間がログインできるようにするため、/ または /login ルートにボットトラフィックが到達する可能性はまだありますが、それらのルートに限定されます。
リンクされたトピックに投稿されているように、例えば：
...stylesheets/docker_manager_abc123.css
簡単なテストで、さまざまなトラフィックが求めているリンクをたどったところ、Discourseが「ログインのみ」モードのときに、cssやjsファイルなどをダウンロードできることがわかりました。
ああ、なるほど、それは想定内です…それらはアプリのレンダリングに使用される静的アセットであり、パフォーマンス向上のためにキャッシュされることが多く、機密性の高い投稿情報は含まれていません。
了解しましたが、技術的な理由で、引き抜かれる可能性のあるスレッドを残さないようにするため（DDoSレベル）、真のロックダウンを深く迅速に検討する必要があるかもしれません。
シンガポールの単一IPから発信された、uploads/default/original/3X/c/.../...some.jpeg ルートを特に標的とする3K近くのユニークなURLリクエストをちょうど確認しました。パスは正しいです。いくつかのリンクをサンプリングしたところ、それらはユニークな特定の画像ファイルへのものでしたが、Cloudflareはシンガポール全体をブロックするように設定されていました。
このままでは、標的練習に使われかねないものは何も残すべきではありません。完全にブロックすべきです。
Secure Uploads がお役に立てるかもしれません。
ご指摘ありがとうございます。知りませんでしたが、そうですね、大きな「たぶん」です。現時点で実装するための時間とリソースがあるかどうかはわかりません。
メタを検索したところ、以下の設定を新たに見つけて有効にしました。
Prevent anonymous users from downloading attachments.（匿名ユーザーによる添付ファイルのダウンロードを禁止する。）これで、そのようなリクエストがブロックされるかもしれません。