风险评分原因：逐字段解读 detection_methods

一位客户在结账时被拦截，写信来问为什么。“我们的供应商说是 92 分”会让对话不欢而散。“您的连接来自一台在列的 VPN 服务器，且其 OpenVPN 端口处于开放状态”则是一个您可以坚持、可以改变主意、也可以据此调整的答案。这就是可解释欺诈评分带来的价值：原因代码，而不仅仅是一个数字。

本页就是这些答案的词典。关于数字本身的含义以及各区间的位置，请先阅读什么是 IP 欺诈评分以及如何解读。下面我们会展示计算方法，逐项追踪一个真实响应的原因，介绍五项减分原因，并列出我们评分代码可能返回的每个 detection_methods 值、其权重以及触发条件。

风险评分原因的累加方式：分值乘以置信度，然后限幅

在 GeoIPHub 的评分中，每项原因的贡献是其分值乘以其置信度，评分就是四舍五入后的总和，并限定在 0 到 100 之间。上面没有任何隐藏的模型。这是我们 API 中的评分步骤（scoring.service.ts），精简到只剩计算部分：

有两个细节容易让人误解。第一，响应中的 confidence 并不是欺诈的概率。它随着原因的数量及其平均大小而增长，所以四项分值适中的原因可能比一项分值很大的原因带来更高的置信度。没有任何原因的查询返回 0.1。第二，detection_methods 的顺序是代码检查它们的顺序，而不是按大小排列。不要把第一项当成主要原因。

其他供应商以不同方式提供原因。MaxMind 的 minFraud 响应带有 risk_score_reasons：作用于风险评分的乘数，每个都带有 ANONYMOUS_IP 之类的代码，MaxMind 还指出它们“通常只针对中高风险交易返回”（“are usually only returned for medium to high risk transactions”）。Socure 的 Sigma Identity Fraud 将一个介于 0.001 和 0.999 之间的评分与原因代码配对，这些代码“提供详细信息，帮助您了解影响欺诈风险评分的因素”。GeoIPHub 的原因是可累加的分值，并且每项影响了评分的原因都会被列出，无论评分高低。

我们验证了这套计算在实时数据上成立。下面七次无密钥查询于 2026-10-29 UTC 04:43:09 至 04:43:54 之间运行，间隔约七秒，每个评分和置信度都能由其原因精确还原：

追踪一个真实响应：AhrefsBot 得 35 分，review

AhrefsBot 的 5.39.1.230 得分 35、review，因为三项原因加了 63.5 分，而它的已验证爬虫匹配减去了 28.5 分。它是最好的教学案例，因为它的原因朝两个方向拉扯。下面是 UTC 04:43:09 那次查询（meta.last_classified_at 为 2026-10-29T04:43:09.547Z）的精简响应，数值未经修改：

每项原因对应一行计算：

去掉爬虫匹配，总和就是 63.5，四舍五入为 64：step up。已验证的网段文件把一个真实的、自报身份的爬虫从验证挑战降到了记录在案的 review。它没有把它降到 allow，因为减分原因是一个权重，而不是白名单。同一地址上的 Spamhaus 列入记录仍然会被计入。

这个响应错在哪里

四项原因中有一项是我们的缺口。no_ptr_datacenter 表示该地址没有反向 DNS，但 UTC 04:44 运行的 dig -x 5.39.1.230 返回了 proxy-fr005-cip7.ahrefs.net。这项原因读取的是我们存储的 PTR 记录，而那条记录缺失了。

修复这个缺口并不会降低这个评分，代码说明了原因。我们的 PTR 分类器会把任何包含“proxy”的主机名视为代理模式。所以如果存储了这条记录，no_ptr_datacenter（+5）会被 rdns_proxy（+14）取代，评分将升至至少 44。这仍然是 review，但原因是 Ahrefs 为其爬虫出口选择的主机名，而不是匿名化工具。这两点我们都已记录。请把 no_ptr_datacenter 和各项 rdns_* 原因视为弱证据，这也正是它们的权重所表明的。

减分原因：五项可以减分，并且止于零

减分原因带有负分值，因此会降低总和，但评分永远不会低于 0。GeoIPHub 的评分配置中有六项这样的原因，目前有五项可以触发：

已验证爬虫的扣减在 Googlebot 的查询中清晰可见。datacenter_ip 加了 10 分，verified_crawler 减去了 28.5 分，API 返回 0。剩下的负 18.5 被丢弃。它不会作为抵扣额度留给之后的原因，这是正确的行为：一个已验证的网段不应能掩盖僵尸网络列入记录。verified_crawler 背后的 19 个网段文件及其日期和白名单生成器，列在我们的已验证爬虫 IP 列表中；如何通过 IP 验证 Googlebot 详细介绍了 Google 的文件。

我们无法在实时地址上向您展示住宅扣减，因为公布对家庭连接的查询会暴露一个家庭的身份。所以这里用文字描述代码路径。住宅类原因依赖反向 DNS：只有当某条线路的 PTR 主机名匹配 dsl、pool 或 dynamic 等家庭模式时，我们的代码才会将其视为住宅线路。匹配时，除非该线路同时被标记为移动或 CGNAT，否则 residential_isp（-17）和 rdns_residential（-16）会一起触发，合计负 33。移动或 CGNAT 线路会以 mobile_carrier（-12）代替 residential_isp，因此这一对合计负 28。如果某条家庭线路的 ISP 不公布反向 DNS，或者以我们无法识别的模式为主机命名，则两项扣减都得不到。在没有其他不利因素的情况下，它的评分就是 0。评分是一样的，所以这个缺口只有在其他原因触发时才有影响。

这些扣减也会反转。如果一条住宅线路带有代理、Tor 或 VPN 协议证据（仅有 IPsec 标签不算），residential_isp 就会被 residential_with_threat（+21.25）取代。移动线路同理，会变为 mobile_with_threat（+16）。一旦这个“家庭”开始转发流量，因看起来像家庭而获得的扣减就会被撤回。

扣减旁边还有两个上限。中继地址的上限为 60，因此 iCloud Private Relay 出口永远不会达到 block；我们在如何检测 Private Relay 和 WARP 流量中解释了如何检测以及为什么应当放行它。被我们 CGNAT 步骤标记的地址上限为 50，除非它自身带有 VPN、代理、Tor、VPN 协议、僵尸网络或滥用证据。

逐字段列出每个 detection_methods 值

GeoIPHub 的评分代码可以给出 41 项原因，其中 36 项目前可能出现在响应中。下表列出全部 36 项及其分值、置信度和贡献，并按每项原因回答的问题分组。

该地址是匿名化工具吗？ 这些原因来自 Tor Project 的出口列表、服务商公布的服务器列表、我们自己的协议探测以及一份第三方代理列表。探测覆盖 SOCKS5、SOCKS4、HTTP CONNECT、HTTP 正向代理、OpenVPN、IKE（v1 和 v2）、PPTP 和 L2TP。没有 WireGuard 探测。

该地址是否有过不良行为？ 这些原因来自三个 DNSBL 区域以及我们的滥用和僵尸网络数据源。

它是服务器基础设施吗？ 托管指的是 853 个精心整理的托管 ASN 之一、我们加载的 10 家云服务商的某个网段，或一个任播网段。三项 datacenter_* 原因中只会触发一项，从最强的开始。

它的反向 DNS 说明了什么？ 这些原因用简单的模式读取存储的 PTR 主机名，这就是为什么每一项的分量都很轻。

它是哪种线路，是否为已知爬虫？ 网络类型原因总是成对出现中的一项：没有匿名化证据时的扣减，或有匿名化证据时的加罚。

代码知道但从不返回的五项原因

有五个名称存在于 GeoIPHub 的评分代码中，但目前不可能出现在响应里，所以不要编写等待它们出现的规则：

• spoofed_crawler（+42.75）。我们的管道中没有任何环节会设置它，而且一次查询只能看到 IP，永远看不到 User-Agent。把声称的 bot 名称与 threat.crawler 进行比对，要在您自己的代码中完成。
• honeypot_hit（+33.25）。蜜罐计数是一个始终为 0 的占位值。
• known_vpn_asn（+22.5）。我们的代码只有在地址本身已经是 VPN 时才把一个网络标记为 VPN，因此总是 known_vpn_server 胜出。
• rdns_cgnat（-10.5）。我们的主机名分类器没有 CGNAT 模式。
• shadowsocks_suspected（+10）。我们没有 Shadowsocks 探测，加载的服务商列表中也没有任何一份标记 Shadowsocks。

配置文件中还有另外 11 个查询路径从不读取的权重，所以这些名称也不会出现在响应中。我们宁愿列出一项休眠的原因，也不愿让您通过苦等去发现它。

基于原因而不是原始数字编写规则

学习这些名称的实际意义在于：基于原因编写的规则能经受住我们数据中的缺口，而基于总分编写的规则则不能。我们的登录、注册和结账的拦截阈值设定了各个区间；在区间之内，几条原因级别的规则就能完成大部分工作：

• 把 tor_exit、socks5_open、http_proxy_open 和 botnet_c2 单独视为强信号：每一项都增加 33 分或更多，并且来自某个列表或我们自己的探测。
• 不要仅凭 no_ptr_datacenter、fcrdns_mismatch 或任何 rdns_* 原因采取行动。它们只有 2 到 24 分，读取的是可能缺失或过时的存储主机名。
• 把 verified_crawler 与 threat.crawler.verified 以及与 User-Agent 所声称的 bot 相符的 operator 一起解读，永远不要依据 threat.crawler.name。一个位于垃圾邮件列表上的已验证爬虫（例如 2026 年 10 月 29 日的 AhrefsBot）应当进入您的爬取白名单，而不是进入您的结账流程。
• 把 wireguard_open 视为列表证据，而不是探测结果。它表示服务商公布的列表声明该服务器运行 WireGuard。
• 每次决策都记录完整的 detection_methods 数组。这正是客服人员或拒付审核人员会索要的审计记录。

下面是用代码实现的样子，只使用真实存在的字段：

原因还能告诉您证据来自哪里，这在客户提出异议时很重要。known_vpn_server 加上 vpn_confidence 95 表示来自服务商自己的列表；我们在如何识别 IP 背后的 VPN 服务商中解释了如何命名服务商以及每个置信度值的含义。关于探测方面，VPN 和代理检测的工作原理介绍了分量最重的匿名化原因来自哪里，而 IP 数据字段完整列表记录了响应的其余部分。

亲手算一次评分

把任意地址粘贴到 GeoIPHub 的免费 IP 欺诈评分检查工具中，复制它的原因，然后根据上面的表格重新算出这个数字。如果您算出的总和与我们的评分不一致，那么我们之中有一方存在 bug，我们很想知道是哪一方。

常见问题

scoring.detection_methods 包含什么？

每一项改变了评分的原因名称，按 GeoIPHub 评分代码检查它们的顺序排列，而不是按大小排列。每个名称在我们的评分配置中都有固定的分值和置信度，评分就是各项分值乘以置信度之和，四舍五入并限定在 0 到 100 之间。GeoIPHub 的代码可以给出 41 项原因；目前有 36 项可能出现在响应中。

为什么已验证的爬虫仍然得到 review 评分？

因为在 GeoIPHub 的评分中，verified_crawler 是一个权重，而不是白名单。它减去 28.5 分（置信度 0.95 时的负 30 分）。位于 5.39.1.230 的 AhrefsBot 在 2026-10-29 还带有一条 Spamhaus 列入记录，因此垃圾邮件和黑名单原因的分值超过了这项扣减：结果是 35 分、review，而如果没有爬虫匹配，它会得到 64 分（step up）。

评分会低于零吗？

加权和可以，评分不可以。2026-10-29，位于 66.249.66.1 的 Googlebot 的加权和为负 18.5（datacenter_ip 加上 verified_crawler），GeoIPHub 的 API 返回了 0。这部分负余额不会作为抵扣额度结转给其他任何原因。

wireguard_open 是否意味着 GeoIPHub 完成了一次 WireGuard 握手？

不是。GeoIPHub 没有 WireGuard 探测。wireguard_open 表示 VPN 服务商自己公布的服务器列表把该服务器标记为 WireGuard。我们的探测覆盖 SOCKS5、SOCKS4、HTTP CONNECT、HTTP 正向代理、OpenVPN、IKE（v1 和 v2）、PPTP 和 L2TP，因此 openvpn_open、pptp_open、l2tp_open、socks5_open 和 http_proxy_open 是探测结果。

为什么一个有反向 DNS 的地址上会出现 no_ptr_datacenter？

这项原因读取的是 GeoIPHub 存储的反向 DNS 记录，而不是实时查询，而这些记录存在缺口。2026-10-29，它在 AhrefsBot 5.39.1.230 和 Tor 出口 185.220.101.1 上触发，而 dig -x 对两者都能解析。它只值 5 分，所以请基于您信任的原因来编写规则，而不是基于原始的原因数量。