one1
2026 年6 月 3 日 13:59
1
也许垃圾邮件攻击如此普遍,以至于我们遇到的情况只是常态。
我相信我们使用了单点登录(SSO),但它仅限于我们的网站。我们未使用任何外部认证。
模式非常清晰:
他们总是用随机的大小写字母字符串填充我们的“性别”字段。
用户名几乎总是一个听起来像真实的名字和姓氏,后跟一串数字。
使用的邮箱总是某个自定义域名,通常看起来非常奇怪,从未是知名服务商。
我们尚未调整任何垃圾邮件过滤器。我们每天可能会收到三到四个此类账号,每周可能达到十个或更多。到目前为止,我一直只是直接删除它们,以免它们有时间发帖。
有什么建议吗?
one1:
用户名几乎总是由一个听起来像真实姓名的名字和姓氏,后跟一串数字组成
我分享一位工作人员关于如何识别垃圾账号的建议:
“经典的‘FirstLast1234’电子邮件地址格式”
这只是典型的垃圾账号手段。
one1:
总是用随机的大小写字母字符串填充我们的“性别”字段
也许这一条会让 AI 感到困惑?
one1
2026 年6 月 3 日 15:09
3
Andrew_Rowe:
也许那一点让 AI 困惑了?
也许吧。无论如何,我很高兴它如此。很难相信一个基于 AI 的机器人竟然不知道关于性别的下一个合乎逻辑的答案。
fhe
(Florian)
2026 年6 月 3 日 15:12
4
是的,我也遇到过这个问题,在我改为手动审核 TL0 用户发布的帖子后,问题就消失了。
我有一个自定义字段,允许注册用户选择他们的操作系统(我的社区是围绕某个应用建立的),而这些机器人账号在该字段中填写的是随机数据。
我使用了一个自定义的数据探索器查询,列出了所有操作系统值无效的用户,即该值不在自定义用户字段预定义的选项列表中。
SELECT
u.id,
u.username,
ucf.value AS user_field_1
FROM
users AS u
LEFT JOIN user_custom_fields AS ucf ON u.id = ucf.user_id
AND ucf.name = 'user_field_1'
WHERE
ucf.value IS NOT NULL
AND ucf.value NOT IN (
SELECT
ufo.value
FROM
user_field_options AS ufo
WHERE
ufo.user_field_id = 1
)
one1
2026 年6 月 3 日 15:25
5
新注册的用户停止了吗?因为那才是我的“问题”。我们实际上已经手动审核 TL0 的帖子了。
fhe
(Florian)
2026 年6 月 3 日 15:27
6
是的,它停止了,但现在读了你们的经历,那可能只是巧合。
我还封禁了这些账户的所有邮箱和 IP。
one1
2026 年6 月 3 日 15:35
7
fhe:
我也封禁了这些账户的所有邮箱和 IP。
是的,我也一直在封禁相关的 IP 和邮箱。只有一次是两个账户使用了同一个 IP,但说实话,我后来就不再特意去检查了。
我有点担心封禁了这么多 IP,会不会开始误伤真实用户。也许我还没有完全理解可能的 IP 数量有多少,以及合法用户被误封的可能性有多大。
我在封禁之前,是否应该每次都先检查一下该 IP 是否为共享 IP?
是的,在注册时添加自定义字段通常能拦截这类垃圾信息,那个数据探索器查询是现在尝试拦截的好方法……但我觉得我们应该提供某种自动化方案,让这变得更简单。
我们在 Meta 已经这样做了多年,新账号注册数量一直相当稳定。
fhe
(Florian)
2026 年6 月 3 日 15:42
9
我还在网站上提供了电子邮件地址,供我的应用用户直接联系我。因此,如果有真实用户无法注册,我大概会收到反馈(但目前还没有)。
不确定你是否应该这样做,但我没有这么做:
Ed_S
(Ed S)
2026 年6 月 4 日 04:49
10
awesomerobot:
我们在 Meta 已经这样做了多年……
哦不!我认为这是一个合理的担忧——世界上许多地方并没有大量的 IP 地址,而且 IP 地址被共享的情况比以往任何时候都更为常见。
awesomerobot:
……而且新账号注册一直相当稳定
嗯,我认为这并不能保证不会让许多人无法使用服务。
我认为,屏蔽垃圾邮件发送者的 IP 地址这一策略源自美国,那是个人恶意行为和通过有线网络接入互联网的时期。我认为这在当下已非常不合适。
将 IP 地址与维护良好的黑名单进行比对,或将地址的 ASN 与不太可能的来源黑名单(例如云服务商)进行比对,可能会有一定帮助。但如果您希望允许人们使用 VPN 注册,仅基于这些理由进行屏蔽仍然不够妥当。
当然,这可能会给 VPN 带来麻烦,但 VPN 也是滥用行为的主要来源之一……因此,完全不对它们采取行动也是一种负担。理想情况下,我们应该建立某种 IP 信誉系统,这样就不必采取非黑即白的做法。
可以通过 Cloudflare 解决。使用日志浏览器,然后根据 WAF 设置和自定义规则相应地进行拦截和质询:
Hopefully it’s helpful, but I also wrote a general guide to the best settings here:
A Cloudflare staff member also added some pointers and corrections in the comments section.
I’m updating that guide and was trying to see if there was any new advice from Discourse and found this page.
I will be adding these to my managed rules. Thank you!
Here’s an overview of my custom rules. This has really help reduce spam and often times (not always) some of the lowest quality traffic comes in via VPN…
Lee_Ars
(Lee_Ars)
2026 年6 月 5 日 12:27
13
Discourse 官方的 hCaptcha 插件 在此方面能提供巨大帮助。它专门用于缓解机器人注册问题。
(我个人也非常希望看到 Discourse 支持 Cloudflare Turnstile 。鉴于 Turnstile 的免费层级包含无摩擦的非交互模式,而 hCaptcha 实现类似功能则需要升级到每月 99 美元的“专业版”定价——这对于自托管用户来说简直是荒谬至极。)
mcdanlj
(Michael K Johnson)
2026 年6 月 7 日 12:41
14
如果作为一个潜在新用户遇到这种情况,我可能直接就放弃了。
我通常甚至不会删除垃圾用户,而是永久封禁他们。这样我可以更方便地从他们那里收集信息以分析模式,从而在战术变化时迅速做出反应。
如果我封禁某个 IP,他们只需换个新 IP 即可。如果我不封禁,其中一些人会用同一个 IP 回来,这样我就能迅速应对。
同时,我也有很多新的垃圾发送者,他们的注册 IP 和最后使用的 IP 并不相同。
我通过 VPN 接收到了大量合法的使用请求,因此如果继续随意封禁那些实际上并非垃圾发送者的随机 IP,反而会导致随机的失败。
我认为我们应该提供一个选项:在删除垃圾账户时,可以封禁邮箱但不 封禁 IP。封禁 IP 最终会成为一种无法直接衡量的隐性成本。我觉得这非常:见不得光的猴子:。
Ed_S
(Ed S)
2026 年6 月 7 日 16:36
15
同意!
mcdanlj:
我通常甚至不删除垃圾用户,而是永久禁用他们。
嗯,也许我应该试试这样做。自从最近遭遇一波攻击以来,我启用了“新用户需审核”模式,以我目前的规模来说这完全 manageable,并且允许我(或其他版主)在 StopForumSpam 上进行检查。