IP 欺诈评分达到多少该拦截？

不存在统一的 IP 欺诈评分拦截阈值：同一个评分，可能在登录时放行，在注册时标记待审，在结账时转入 3-D Secure。 GeoIPHub 的 0 到 100 评分默认是：25 以内放行，50 以内待审，75 以内二次验证，75 以上拦截。本文按操作调整这些界线，并在 2026 年 10 月 22 日用五个公开地址做了测试。

一个评分，三扇门：我们用阈值测试的五个 IP

同样的 API 判定结果，在每扇门前的落点各不相同，而两个评分上限决定了共享地址最高能到哪里。2026 年 10 月 22 日 UTC 04:56，我们用无需密钥的 API 查询了五个公开地址，并把每个结果映射到下一节的起始阈值上。最后两行不是查询结果，而是我们评分配置中设定的上限。

这张表里有四点值得据此行动。

• 两个 100 分的原因不同。 Tor 出口的检测方法是 tor_exit、datacenter_blocklisted、no_ptr_datacenter 和 known_spammer：一个有垃圾邮件历史的匿名工具。Mullvad 服务器的是 known_vpn_server、wireguard_open、datacenter_with_vpn_proxy 和 no_ptr_datacenter，其中 threat.is_spammer 为 false，也没有 DNS 黑名单记录。如果您的客户使用 VPN，那么把仅因 VPN 而触发的拦截改为 MFA 的登录规则是站得住脚的，而这条规则永远不会对 Tor 出口生效。
• 中间那一行正是按操作设定阈值发挥价值的地方。 评分 35 的 AhrefsBot 能通过登录，在注册时被标记，在结账时转入 3-D Secure。然而一个经验证的 SEO 爬虫根本没有理由提交这些表单，这一点仅凭评分是看不出来的。
• 这一行在两周内发生了变化。 同一个地址在 10 月 8 日的评分是 23，10 月 19 日是 59（step_up），其检测方法中有 abusive_listed。到 10 月 22 日该方法消失，评分变为 35，登录也从 MFA 降为普通登录。我们在如何调查一个 IP 地址中详细分析了这个地址。请把评分、检测方法和日期与每次决策一并存储，并在依据旧结论行动之前重新查询。
• 共享地址无法达到拦截。 Private Relay 的上限是 60（relay_max_score），所以永远越不过默认的拦截线 76。CGNAT 的上限是 50（cgnat_max_score），正是待审区间的上沿。我们最严格的拦截线，即结账的 66，有意设在两者之上。如果设在 60 或以下，被设上限的中继用户可能仅仅因为共用地址而被拒绝。

两个放行行说明评分是累加的。中继的 relay_ip 信号是 10 分、置信度 0.85，四舍五入后为 9。Linode 服务器的 datacenter_ip 是 20 分、置信度 0.5，即 10。托管只是值得留意的理由，而不是拦截的理由；中继则应当放行，我们在如何检测 Private Relay 和 WARP 流量中对此有说明。

登录、注册和结账的 IP 欺诈评分起始阈值

随着错误放行的代价上升，起始阈值会逐步收紧拦截线：登录 76，注册 71，结账 66。请把它们当作起点，并用您自己的欺诈数据调优。

对于界限分明的情况，请把评分与几条基于信号的规则结合使用：

• 当 detection.is_tor 为 true 时，对任何操作都拦截。 这是唯一仅凭原因就足以拒绝的情形。
• 当 detection.is_relay 或 threat.is_cgnat 为 true 时，永远不要仅凭评分硬性拦截。 这里的上限已经保证了这一点；这条规则是为了防止以后有人调低拦截线时保护您。
• 在结账时，把 review 当作 step_up 处理。 我们的 IP 欺诈检测 API 教程提供了经过测试的 Node 和 Python 代码来实现这一覆盖，并包含查询超时时的容错处理。

想了解各类地址在注册时会返回什么，以及能抓住评分放过的流量的按前缀速率限制，请阅读注册环节的虚假账户检测。

想了解各个区间的含义以及单个评分是如何构成的，请从如何解读 IP 欺诈评分开始。

Tor 出口评分 100，检测方法说明了原因

下面是 185.220.101.1 的真实响应的精简版，查询时间为 2026 年 10 月 22 日 UTC 04:56：

fraud_score 为 100，超过了表中的每一条拦截线，因此登录、注册和结账都会拒绝它。仅靠三个原因就能到达这个分数：tor_exit（45 分，置信度 0.99）、known_spammer（40 分，置信度 0.9）和 datacenter_blocklisted（30 分，置信度 0.75）相加为 103，再被上限截为 100。detection.is_vpn 为 false，因为 Tor 是单独标记的，所以您可以对 detection.is_tor 硬性拦截，同时仍对普通 VPN 用户发起验证挑战。

第四个原因反映的是我们这边的一处缺口。no_ptr_datacenter 表示该地址没有反向 DNS，然而 dig -x 185.220.101.1 在当天早上 UTC 04:57 返回了一个 Tor 出口主机名。我们的数据库缺少这条存储的记录，修复已记入日志。结论依然成立，因为另外三个信号就足够了，但这也是一个很好的理由：规则应当建立在您信任的信号上，而不是原始总分上。

为什么一刀切的全局阈值行不通

单一阈值之所以失败，是因为每个端点面对的攻击各不相同。登录页要承受撞库攻击：Verizon 2025 DBIR 发现，撞库平均每天占所有认证尝试的 19%（中位数），最严重的一天高达 44%。结账页面临盗刷测试，注册页面临虚假账户。另据 Cloudflare Radar 2025 年度回顾，2025 年 12 月 2 日，人类产生的 HTML 请求只占 47%。

成熟的系统已经按区间处置。Cloudflare 的机器人评分范围是 1 到 99，客户可以编写规则，依据它来拦截、挑战或放行（Cloudflare 机器人评分）。OWASP 指出，IP 封禁“不应作为唯一或主要的防御手段，因为很容易被规避”（OWASP 撞库攻击速查表）。同一页面还引用了微软的分析：MFA 本可以阻止 99.9% 的账户被入侵。这使得登录的二次验证区间成为廉价的保险。NIST SP 800-63B 指出，意外的地理位置或 IP 地址封锁“可能促使采用额外的基于风险的控制”，但并不“替代身份验证因素”（NIST SP 800-63B）。

GeoIPHub 基于 36 项加权原因构建可解释的 0 到 100 风险评分，并在 scoring.detection_methods 中列出每一项触发的原因。其中有些会降低评分：住宅 ISP 原因减去 17 分（置信度 0.85 时减 20），经验证的爬虫减去 28.5 分（置信度 0.95 时减 30）。

过低的阈值会误伤共享地址和隐私地址

出于“保险起见”而设得过低的拦截线，会把出于正常理由共享或隐藏地址的客户拒之门外：

• VPN 用户。 在 Security.org 的 2026 年 VPN 报告中，针对 2026 年 8 月 1,008 名美国成年人的调查显示，42% 的人表示出于个人或工作目的使用 VPN。一般隐私（56%）和一般安全（51%）是最主要的原因。
• 运营商级 NAT。 RFC 6598 将 100.64.0.0/10 保留给 CGNAT，Cloudflare 指出，在它后面，“成百上千个客户端看起来可能都来自同一个 IP 地址”。Cloudflare 还发现，CGNAT IP 被限速的频率是其他 IP 的三倍，尽管机器人比例的中位数几乎相同：4.8% 对 4.7%（Cloudflare 谈 CGNAT）。
• iCloud Private Relay。 运营着中继跳点的 Cloudflare 表示，使用 IP 地址进行欺诈防范的网站“可以信任”Private Relay 连接，因为 Apple 会验证设备和账户（Cloudflare 谈 Private Relay）。

GeoIPHub 返回 detection.is_mobile、detection.is_relay 和 threat.is_cgnat，并在返回评分之前应用 CGNAT 上限 50 和中继上限 60。

评分对象必须是正确的 IP，否则任何阈值都没有意义

如果您评分的是被伪造的 X-Forwarded-For 值，调优好的阈值在运行之前就已经被击败。RFC 7239 警告说，Forwarded 头“不能保证正确”，因为途中的任何节点（包括客户端）都可以修改它（RFC 7239）。MDN 的规则是，任何涉及安全的 X-Forwarded-For 用法“只能使用由受信任代理添加的 IP 地址”，方法是从最右侧的条目开始，按您运行的代理数量向前数（MDN：X-Forwarded-For）。我们会对您发送的任何 IP 评分，所以请先根据您信任的代理链推导出该 IP。

用您自己的结果来调优阈值

从表格出发，然后用证据逐条调整界线。为每次决策记录评分、recommended_action、detection_methods 和日期，几周后将它们与已确认的欺诈和拒付进行对比。如果您的结账线 66 让评分在 55 到 65 之间的拒付漏了过去，就调低它，但只要您还服务 Private Relay 用户，就不要降到 60 或以下。如果 51 到 70 的注册验证很少抓到恶意账户，就调高这条线。

免费套餐每天包含 1,500 次查询，且包含全部字段。如需手动检查单个地址，IP 欺诈评分检测工具无需写代码即可显示相同的评分和原因。

如需了解更完整的信号集，请参阅我们的指南：检测匿名流量而不封禁真实客户、住宅代理与数据中心代理欺诈对比、阻止账户接管和撞库攻击、在兑换环节检测促销和优惠券滥用，以及 IP 信号在支付欺诈检测体系中的位置。

常见问题

IP 欺诈评分达到多少适合拦截？

不存在统一的通用阈值。GeoIPHub 的默认区间在 76 及以上拦截。我们建议的起始阈值是：登录沿用 76，注册降到 71，结账降到 66，因为一笔欺诈性的无卡支付订单，其代价远高于让用户重新输入一次密码。其他服务商的评分尺度不同，因此请按各自服务商的区间来理解其阈值。

IP 欺诈评分 75 是什么意思？

在 GeoIPHub 的 0 到 100 评分尺度上，75 是 step_up 区间的上限，拦截从 76 开始。应当对其发起验证挑战，而不是悄悄放行，并查看 scoring.detection_methods，因为由 VPN 信号得到的 75 和由黑名单历史得到的 75 需要不同的应对。真正的 Tor 出口根本不会停在 75：在我们 2026 年 10 月 22 日的查询中，185.220.101.1 的评分为 100，处置为 block。

应该自动拦截 VPN 和代理用户吗？

不应该。在 Security.org 2026 年 8 月对 1,008 名美国成年人的调查中，42% 的人表示出于个人或工作目的使用 VPN，隐私和安全是最主要的原因。请把 VPN 标记视为发起二次验证的理由，而不是自动拒绝，并把硬性拦截留给 Tor 出口以及有垃圾邮件或黑名单历史的地址。

仅凭评分，iCloud Private Relay 或 CGNAT 用户会被拦截吗？

按 GeoIPHub 的默认设置不会。Private Relay 地址的评分上限为 60，运营商级 NAT 地址的上限为 50，都低于默认的拦截线 76。只要把每条拦截阈值都设在 60 以上，共享地址仅凭评分就只会被要求验证，绝不会被拒绝。

为什么结账的拦截阈值比登录低？

结账环节的错误放行会让货物被盗刷的银行卡买走，最终以拒付的形式回流；而登录环节的错误放行仍需通过密码和任何第二因素。因此结账从 66 开始拦截，登录则从 76 开始。