本插件利用 ProxyTracer API 在 Discourse 中检测和阻止 VPN、Tor 及代理流量。
功能特性
- 提供精细控制，可在用户新注册、现有用户认证或全局针对所有网站访客时阻止 VPN、Tor 和代理用户。如果您允许 VPN、Tor 和代理用户访问论坛内容，则可以节省 API 请求，仅启用注册和认证阶段的保护。
- 采用缓存机制存储最近的 IP 地址评估结果，从而减少 API 请求并降低延迟。您可以在设置中控制 IP 地址评估结果的保留时长。
- 若发生 API 超时或网络故障，插件将优先保障用户访问权限，以防止大规模锁定。此行为可通过选项进行更改。
- 内置对精确 IP 地址和 CIDR 子网白名单的支持。
配置步骤
- 从 ProxyTracer 仪表板 获取标准 API 密钥。
- 进入 Discourse 管理面板：管理 → 插件 → ProxyTracer，查找 ProxyTracer 的设置项。
- 在
ProxyTracer API Key 字段中输入您的 API 密钥。
- 通过切换
Enabled during Signup（注册时启用）、Enabled during Login（登录时启用）和/或 Enabled for All Visitors（对所有访客启用）来启用保护参数。
- 将任何受信任的 IP 地址或 CIDR 范围添加到
Whitelisted IPs（白名单 IP）列表中。
- （可选）根据您的服务器具体流量需求，调整 API 超时时间和 Redis 缓存持续时间限制。
- （可选）自定义被阻止用户看到的阻止消息。例如，您可以添加联系网站管理员的说明，以防用户认为阻止不当，或他们并非通过代理、Tor 或 VPN 访问网站。
设置项
包含设置项及其说明的表格
| 名称 |
说明 |
| API 超时（毫秒） |
等待 API 响应的时间上限，超过此时间则视为超时。 |
| 缓存持续时间（小时） |
在再次检查 API 之前，记住某个 IP 地址的时长。 |
| 错误时开放访问 |
如果 API 崩溃或超时，仍允许用户注册或登录，以防止锁定所有用户。 |
| 注册时启用 |
在新用户尝试注册时阻止代理和 VPN。 |
| 登录时启用 |
在现有用户尝试登录时阻止代理和 VPN。 |
| 对所有访客启用 |
阻止代理和 VPN 访问或查看论坛上的任何页面。（警告：此选项会检查每一位访客，并大量消耗您的 API 配额）。 |
| 阻止消息 |
用户被阻止时显示的确切错误消息。 |
| 白名单 IP |
被严格允许绕过阻止的 IP 地址或 CIDR 范围（例如：192.168.1.0/24）。 |
网络配置：Cloudflare 与反向代理
为确保 ProxyTracer 有效运行，Discourse 应用程序必须接收真实的客户端 IP 地址。
为确保正确的 IP 地址转发，您可以参考这些 详细说明。
紧急访问
如果您将自己锁在系统外，可以按照这些 简单步骤 恢复访问权限。
如果您想进行测试，可以注册 ProxyTracer 并获取一些免费的 API 积分用于测试。
4 个赞
你问的是注册时的免费积分吗？如果是的话，那只是一次性充值。
1 个赞
这难道不会完全违背该插件的初衷吗？任何人都可以使用安全模式。
2 个赞
Moin
6
这取决于具体情况。有一个站点设置允许您禁用安全模式，这对于受控主题组件以及其他用户不应轻易禁用的组件/插件（如广告、访客门禁等）很有帮助。但如果您已退出登录，这也会使管理员使用安全模式变得更加困难。我认为他们仍然可以通过 管理员登录 来启用它。
对于此插件，我怀疑安全模式是否有帮助。安全模式仅禁用插件的前端部分，而此插件完全由 Ruby 编写。因此，我认为禁用 JavaScript 自定义并无太大帮助。这一事实让我对该插件略存疑虑，同样令我怀疑的是，它包含了一个 about.json 文件，仿佛它是一个主题组件。但最终，每个人都要对自己在论坛上安装的代码负责。
4 个赞
您完全正确，我可以通过在 freshly 启动的 Discourse 实例上进行测试来确认这一点。我随即更新了文档，添加了实际有效的操作说明，即登录服务器并手动禁用该插件：
cd /var/discourse
./launcher enter app
rails c
SiteSetting.proxytracer_enabled = false
exit
exit
我可以确认，当“对所有访问者启用”设置处于开启状态，且有人尝试通过 VPN/代理连接并访问安全模式时，安全模式将无法访问。
确实，对于标准插件而言，about.json 是多余的，我已将其从仓库中移除。
感谢 @Moin 的所有反馈。如果您有任何其他意见或建议，欢迎在此留言。代码完全开源，欢迎任何贡献：GitHub - ProxyTracer/discourse-proxytracer。
1 个赞
eisammy
(Sammy)
8
@ProxyTracer 当我尝试使用 Cloudflare Warp 登录时，返回的是“未知错误”，而不是被拦截的提示。
发现得很及时！这个问题应该在 0.1.1 版本中已修复。能否确认升级后问题是否已解决？
1 个赞
eisammy
(Sammy)
10
我正在测试你们的服务，想了解一下它与 ‘templates/cloudflare.template.yml’ 是否存在冲突，以及该插件是否会支持 Discourse 核心版本的后续更新。
我想知道，在一个注重隐私保护的社区里，如何找到一种折中方案，以免失去像我这样的用户。
感谢进行测试！README.md 中关于 Cloudflare 集成 的文档明确建议包含 "templates/cloudflare.template.yml"，因为这是确保论坛位于 Cloudflare 之后时，Discourse 能够提取用户真实 IP 的必要条件。因此，这与该模板并不冲突，实际上包含它是必需的。
是的，我们致力于跟进 Discourse 的核心更新，以确保与较新版本的完全兼容。
2 个赞
我在想，如果增加一个选项——不直接封禁用户，而是要求他们通过 hCaptcha 验证，并将此选项设为默认设置——是否会是一个很好的折中方案？因为它增加了恰到好处的门槛，既能提高垃圾信息发送者和封号规避者的操作难度，又能让那些希望通过 VPN、Tor 等工具保护自身在线隐私的合法用户正常使用。当然，对于那些仍希望完全封禁上述网络的管理员来说，他们依然可以保留原有的封禁选项。大家怎么看？
1 个赞
eisammy
(Sammy)
14
非常感谢！我刚刚在沙盒环境中做了一个测试，运行得非常完美。
你们是否考虑添加与移动网络 IP/ASN 相关的功能？在我的论坛中，经常遇到这种情况：用户从宽带网络切换到运营商的 4G/5G 网络以获取不同的 IP，从而试图绕过 Discourse 中的注册或登录限制。
如果能识别出 IP 是否属于移动运营商的 ASN，并可选地允许在注册/登录过程中以不同方式处理这些 IP，将会非常有用。
也许这有点超出了 ProxyTracer 的范围，因为它不一定与 VPN/代理有关，但对于解决 Discourse 如何处理每个 IP 的账户数量限制这一特定问题来说，会很有帮助。
eisammy
(Sammy)
15
就 hCaptcha 而言，我在自己的安装中已经在使用了，效果非常好！也许可以将 Discourse 核心中已有的那个插件与你的插件结合起来，作为额外功能？
我认同完全封锁的想法，毕竟这正是目标所在。不过，针对固定和移动网络的 IPv4 和 IPv6，通过设置验证挑战来限制访问似乎非常有用，因为 AI 特别喜欢在论坛上注册账号。
你好，感谢你能考虑我的回复。这确实是一件让我非常感兴趣的事情，我认为对于用户和管理员双方来说，这是一个特别敏感的实施方案。
说实话，我觉得自己就像是一个正在完成验证码（CAPTCHA）以证明自己是人类的机器人，故意表现得像个机器人一样。我在相关主题中提到过，Anubis 的实现方式（POW）在我看来要更令人愉悦且实用得多。
我理解这超出了本项目的范围，但就我目前的分析来看，使用你提到的那种验证码是可行的，而且从字面意义上说，它完全不会阻碍那些重视隐私、希望在不被拒之门外的前提下做出贡献的用户。
eisammy
(Sammy)
17
该插件还可以提供的另一项信息是，哪个账户曾尝试通过 VPN/代理进行登录。
