我认为我找到了问题所在（最终问题出在我们这边），但还有一些 bug 需要报告。不过，这并不是我熟悉的代码栈，所以希望有人能更仔细地查看。
首先是原因。直接查看 screened_ip_addresses 数据库表，我发现它错误地阻止了两个完整的地址块（176.59.0.0/16 和 109.252.0.0/16）。我真不知道它们是怎么被添加进去的，而且这两个条目从二月起就一直存在。Discourse 管理后台有没有什么按钮可以一次性阻止整个 /16 地址块！？
无论如何，这很可能就是我最初问题的罪魁祸首。不过，Discourse 团队可能还需要关注一些其他问题，因为正是这些问题使得此次排查格外困难：
-
出于某种原因，这些被阻止的地址范围并未显示在“已屏蔽 IP"列表中。我不得不直接查看数据库才能找到它们。不过，使用搜索功能输入 “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 登录并未触发这些匹配？