ここでの問題の特定ができたと思います（結局は私たちの側の問題でした）が、いくつかのバグを報告する必要があります。ただし、このスタックにはあまり慣れていないため、誰かがより詳しく見てくれることを願っています。
まず、原因についてです。screened_ip_addresses データベーステーブルを直接確認したところ、本来ブロックすべきではない 2 つの全体のブロック（176.59.0.0/16 と 109.252.0.0/16）がブロックされていることが分かりました。これらがどのように追加されたのか正直分かりません。この 2 つのエントリは 2 月以来存在していました。Discourse の管理画面には、/16 ブロック全体を一度にブロックするためのボタンなどあるのでしょうか!?
とにかく、これが初期の問題の原因である可能性が高いです。しかし、Discourse チームが調査した方が良いいくつかの問題が残っています。これが特に解決を難しくさせた要因です。
-
何らかの理由で、ブロックされた範囲が「Screened IPs」の一覧に表示されません。これらを見つけるには、直接データベースを確認する必要がありました。ただし、「176.59」や「109.252」で検索すると表示されます。
/admin/logs/screened_ip_addressesに結果数の制限が適用されているのでしょうか。 -
エクスポートでは、これらは 176.59.0.0 および 109.252.0.0 として表示され、ブロック情報が一切示されていません。デフォルトの範囲（127.0.0.0/8、10.0.0.0/8 など）についても同様で、エクスポートファイルにはマスクが表示されません。
-
これらのエントリはユーザーをブロックしているにもかかわらず、
match_countの値は 0 で、last_match_atは空のままです（テーブル全体で）。これは意図された動作でしょうか？おそらくallowの一致はカウントしたくないのでしょうが、ブロックがカウントされていない場合、これらのカラムは使用されていない、あるいは不要に見えるかもしれません。あるいは、SSO によるログインではこれらの一致がトリガーされないのでしょうか。