结账环节的 AI 购物代理欺诈：如何通过 IP 阻止 bot 欺诈而不误伤真实订单

如今，转化率最高的结账流量和代价最高的欺诈来自同类网络。Adobe 发现，2026 年 3 月，访问美国零售网站的 AI 流量“转化率比人类访客高 42%”，而一年前它的转化率还低 38%（Adobe 数据，经 TechCrunch 报道）。与此同时，2025 年自动化流量已超过全部网络流量的 53%（Imperva 2026 年恶意 bot 报告）。

HUMAN Security 报告称，“目前 2.3% 的代理活动发生在结账页面”，并且良性自动化与恶意自动化的比例之间“只相差 0.5 个百分点”（HUMAN，2026 年 3 月）。仅凭行为无法将它们区分开。

下面是四次真实查询、为什么 User-Agent 比对是您的工作，以及一张能保住真实代理订单的评分与操作对照表。

为什么在结账时拦截数据中心和代理 IP 两头落空

一刀切地拦截数据中心之所以失败，是因为它既有漏洞，又代价高昂。说它有漏洞，是因为代价高昂的攻击根本不需要数据中心地址。HUMAN 表示，“自 2022 年以来，盗卡量激增了 250%”，而“登录后的账户入侵尝试同比增长了三倍多”（HUMAN）。GeoIPHub 不检测住宅代理，因此来自家庭连接的欺诈必须靠您的请求频率和支付数据来捕获。我们关于住宅代理欺诈的解读说明了原因。

说它代价高昂，是因为它会误伤您想要卖货的对象：

• 真正的代理运行在云网络上。 下面那个经过验证的 ChatGPT-User 地址位于 Microsoft 的 AS8075 上，并被标记为 datacenter_ip。
• Apple iCloud Private Relay 用户共享中继出口地址，这些地址运行在 Cloudflare 等合作伙伴网络上。
• 运营商级 NAT 让许多用户共用一个地址。 RFC 6598 为此保留了 100.64.0.0/10 作为共享地址空间。Cloudflare 测得“CGNAT IP 被限流的频率是非 CGNAT IP 的三倍”，而 CGNAT 地址的平均 bot 比例反而更低，为 7%，对比 13.1%（Cloudflare）。

所以，连接类型是一项加权输入，而绝不是直接拒绝的理由。我们的基于 IP 的 bot 检测专题通过五次真实查询，展示了每个 IP 标记能证明什么、不能证明什么。

四个结账调用方，四次查询：我们在 2026 年 10 月 23 日看到的结果

一个经过验证的代理地址得分 0，结果为 allow，几乎任何云服务器也是如此。我们在 2026 年 10 月 23 日 05:03:52 至 05:04:07 UTC 之间运行了四次无密钥查询，每次间隔 5 秒：

• ChatGPT-User： 104.208.184.193，即 104.208.184.192/28 的第一个主机地址，而该段是 OpenAI chatgpt-user.json 中的第一个前缀。我们在 05:03 UTC 获取了该文件。它列出了 234 个 IPv4 前缀，没有 IPv6，creationTime 为 2026-10-20。
• Google 用户触发的抓取程序： 107.178.192.1，位于 Google user-triggered-fetchers.json 中的 107.178.192.0/27 内。
• 普通云服务器： 45.33.32.156，即 scanme.nmap.org，Linode 上的一台公共测试主机。它不是代理。
• iCloud Private Relay： 104.28.46.99，Cloudflare 上的一个 Apple 中继出口地址。

下面是 ChatGPT-User 的查询结果，经过精简，保留了嵌套结构，数值未作改动：

两个托管信号被触发：datacenter_ip 和 no_ptr_datacenter。减分信号 verified_crawler 将总分拉低到 0。这个地址没有反向 DNS，无论是实时的还是存储的，因此 OpenAI 的 IP 段文件是唯一的证明。Google 抓取程序呈现相同的模式，得分也是 0，不同之处在于它的主机名可以解析，因此触发的是 rdns_hosting 而不是 no_ptr_datacenter。

云服务器这一行才是关键。它的 10 分仅来自 datacenter_ip，处于 allow 区间（25 及以下）。如果该请求携带的是 ChatGPT-User User-Agent，评分仍然会显示 allow。只有 verified: false 和 name: "none" 能表明这一声明是假的。这就是为什么决策一栏写的是加强验证，而不是放行。

中继地址得分 9，唯一的方法是 relay_ip。中继的上限是 60，因此 Private Relay 用户永远不会达到 block。我们的地理定位显示为安哥拉罗安达，但我们在 2026 年 10 月 12 日检查时，Apple 的出口数据源显示为赞比亚卢萨卡，因此应按国家级别来判断中继用户。

在 05:09 UTC，我们还查询了 136.121.16.1，即 Google user-triggered-agents.json 中的第一个 IPv4 主机。该文件涵盖 Google-Agent，Google 称其“供托管在 Google 基础设施上的代理使用，用于浏览网页并根据用户请求执行操作”（Google）。它被验证为 GoogleUserTriggeredAgent，得分 0，结果为 allow。它还触发了 fcrdns_mismatch，尽管实时 dig 能够正向确认其主机名。这是我们的 bug；它没有影响评分，我们已将其记录在案。

这只是一个上午的五次查询，并不是基准测试。IP 段会变动，因此在复制某个数值之前，请重新运行这些查询。

User-Agent 比对是您代码的工作，而不是 API 的

API 证明某个地址属于哪个 bot，而您的代码证明请求声称的是同一个 bot。IP 查询永远看不到 User-Agent，因此 GeoIPHub 无法独自标记伪造的代理。您的结账处理程序持有该请求头，必须由它来进行比对。

两边的名称并不相同。OpenAI 的 User-Agent 标识是 ChatGPT-User，而 API 返回的是不带连字符的 ChatGPTUser。Google 的标识是 Google-Agent，而 API 返回的是 GoogleUserTriggeredAgent。直接比较字符串会失败，因此请维护一个小映射表：

结果为 false 就是上面云服务器那一行的情况：无论评分多少，都要加强验证或拒绝。完整的 nginx 和 Express 执行方案，以及一个伪造 GPTBot 的测试，见我们关于是否应拦截 AI 爬虫的指南。

在为 IP 打分之前先验证代理的签名

有效的协议凭证或签名优先于任何 IP 信号。有三种机制能比 IP 段文件更确切地回答“这是谁发送的”。

Agentic Commerce Protocol（ACP，代理式商务协议）。 Stripe 于 2025 年 9 月 29 日发布了 ACP，这是一个“由 Stripe 和 OpenAI 共同开发”的开放标准；其规范仓库采用 Apache-2.0 许可。其 Agentic Checkout RFC 将 Authorization bearer 令牌、API-Version 以及每个 POST 请求上的 Idempotency-Key 标为必需，Signature 和 Timestamp 为推荐项。Stripe 表示，其 Shared Payment Tokens“限定于特定商家和购物车总额”，这限制了被盗令牌能买到的东西。

Web Bot Auth。 代理按照 RFC 9421 HTTP Message Signatures（标准轨道，2024 年 2 月）对每个请求签名。Cloudflare 的 Web Bot Auth 文章使用 Signature、Signature-Input 和 Signature-Agent 请求头，以及签名方公布的 Ed25519 密钥。

卡组织的代理计划。 Visa“与 Cloudflare 合作”，在 HTTP Message Signature 标准之上构建了其 Trusted Agent Protocol，用于将可信代理与“恶意自动化和流氓 bot”区分开（Visa，2025 年 10 月 14 日）。Cloudflare 同日发布的公告称，“Mastercard 正在将 Web Bot Auth 纳入 Mastercard Agent Pay。”

在 ACP 调用中，RFC 指出由 ChatGPT 调用您的结账端点，因此建立连接的 IP 属于代理平台，而不是购物者。在这条通道上验证凭证，把 IP 评分留给直接的网页流量。我们的通过 IP、rDNS 和 Web Bot Auth 验证 AI 爬虫和代理指南逐一介绍了每项检查。

为什么仅靠 IP 白名单是脆弱的，即便对真正的代理也是如此

手工维护的白名单会失效，因为代理地址是共享的，而且一直在变动。Cloudflare 说得很直白：“以 IP 地址段来代表某个产品或某群用户的逻辑是脆弱的”。它还补充说，连接“可能由多个用户共享，例如隐私代理和 VPN 的情况”，而且云 IP 段“会随时间变化”（Cloudflare）。

OpenAI 自己的文件就显示了这种漂移：

2026 年 10 月 6 日的数量来自我们对 GPTBot、OAI-SearchBot 和 ChatGPT-User 的比较。OpenAI 还提到 ChatGPT-User：“由于这些操作是由用户发起的，robots.txt 规则可能不适用”（OpenAI）。

我们这边也有延迟。GeoIPHub 每天重新获取 19 个官方 IP 段文件并重建查询数据库，因此一个新前缀最多可能需要大约两天才能通过验证。请将 IP 段匹配视为强有力的佐证，当代理发送签名时，优先使用签名。

AI 购物代理欺诈：支付环节的威胁

有三种攻击推动着结账环节的 AI 购物代理欺诈，而它们看起来都不像合法代理订单那样，一个买家对应一个购物车。

• 盗卡测试（枚举攻击）。 一波波小额或仅授权的尝试，拒绝率很高。Visa 表示，枚举攻击造成“每年 11 亿美元的欺诈损失”，并且“33% 被枚举的账户在五天内遭遇了欺诈”（Visa，2024 年 5 月）。
• 账户接管。 利用被盗的登录凭证，用已保存的银行卡购物。Imperva 表示，金融服务业占“账户接管事件的 46%”（Imperva 2026）。我们的账户接管防御指南介绍了登录端的应对。
• 抢购倒卖。 在热门限量发售时囤积有限库存的 bot。

分散在许多地址上的盗卡测试能绕过按 IP 计数的计数器，因此还要按 ASN 和按 BIN 统计拒绝次数和不同银行卡的数量。

将 0 到 100 的评分对应到结账操作

只有当每个区间都对应一个固定操作时，0 到 100 的评分在结账环节才有用。GeoIPHub 可解释的风险评分涵盖 IP 方面的输入，而 scoring.detection_methods 会列出每个被触发的信号。其余部分由您的代码和支付数据提供：

然后将各区间对应到操作：

上限让共享地址不会进入 block。中继地址的上限为 60，因此不会仅凭评分被拒绝；对于 API 识别为运营商级 NAT 的地址，上限为 50。ACP 也自带盗卡测试信号：delegate-payment RFC 会发送类型为 card_testing 的 risk_signals，操作为 blocked、manual_review 或 authorized。这由代理平台填写；您的评分仍是一项独立的检查。我们关于登录、注册和结账的 IP 欺诈评分阈值的文章在另外五个地址上测试了这些区间。

升级验证，而不是拦截：3-D Secure 会转移责任

将中间区间转入 3-D Secure，而不是直接拒绝，因为加强验证能保住订单，并且通常会转移拒付风险。Trust Payments 的 3-D Secure v2 责任指南指出，在成功认证之后，“在大多数情况下，发生欺诈性拒付时由发卡机构承担责任”。它也提醒，“交易认证成功并不保证责任转移或授权成功。”

加强验证给真实买家留了一条通道，同时迫使盗卡测试者证明自己持有这张卡。我们关于 VPN 检测误报的指南介绍了还有哪些人会落入这个中间区间。

代理是否获得授权，是法律问题，而不是技术问题

更难的问题是，该代理究竟是否可以向您购买。2026 年 3 月 9 日，美国加利福尼亚北区联邦地区法院批准了 Amazon 针对 Perplexity 的初步禁令。据 The Register 报道，法官写道，Perplexity 的 Comet 代理“在获得 Amazon 用户许可、但未经 Amazon 授权的情况下进行访问”（The Register）。Perplexity 提出上诉，2026 年 8 月 4 日，第九巡回上诉法院撤销了该禁令，并将案件发回地区法院，目前仍在审理中。

那项裁决并没有解决这个问题。IP 检查告诉您是谁发送了请求。您的服务条款决定该发送方是否可以购买。

IP 检查在结账环节的不足之处

IP 信号只覆盖结账全貌的一部分，以下是已知的缺口：

• 不检测住宅代理。 来自家庭连接的欺诈需要依靠您的请求频率和支付数据。
• 看不到 User-Agent。 API 永远不会标记伪造的代理；这要靠您代码中的名称比对。
• IP 段延迟和 DNS 缺口。 一个新前缀可能需要大约两天才能通过验证，而且今天上午我们就看到了一次误报的 fcrdns_mismatch。
• 运营商级 NAT 目前不会按 IP 段被标记。 我们在 2026 年 10 月 22 日查询 100.64.0.1 时，它并没有被标记为 CGNAT。暂时不要基于该标记构建规则。

在任何规则变更之后，按细分人群跟踪误报，例如 iOS Safari、移动运营商和 Private Relay。我们关于 IP 地理定位到底有多准确的说明解释了为什么国家比城市更可靠。

将其放入您的结账处理程序

在服务器端的结账端点中接入，分四步：

1. 首先验证任何 ACP 凭证或 Web Bot Auth 签名，并让有效者进入可信通道。
2. 查询建立连接的 IP，方法见我们的使用免费 API 为您的应用添加 IP 欺诈检测指南。
3. 用 User-Agent 映射表比对 threat.crawler.name。未通过的代理声明需要加强验证或被拒绝。
4. 将 scoring.recommended_action 对应到区间表，并在此基础上加上您的银行卡和 ASN 频率检查。

当某个决策看起来不对时，使用如何调查一个 IP 地址中的步骤找出原因。从您自己的结账日志中挑一个本周自称 ChatGPT-User 的地址开始。查询它，并将 crawler.name 与其声明进行比较。

常见问题

为了阻止 bot，我应该在结账时拦截所有数据中心或代理 IP 吗？

不应该。真正的代理运行在云网络上：2026 年 10 月 23 日，一个位于 Microsoft AS8075 上、经过验证的 ChatGPT-User 地址得分为 0，结果为 allow。一刀切的拦截还会拒绝 Private Relay 和运营商级 NAT 用户。在评分中给托管因素适当权重，并将中间区间转入 3-D Secure。

在支付环节，如何区分合法的 AI 购物代理和欺诈 bot？

先验证身份：ACP 凭证或符合 RFC 9421 的 Web Bot Auth 签名。如果没有，就查询 IP，它会返回 threat.crawler.verified 和 bot 名称，然后让您的代码将该名称与请求所声称的 User-Agent 进行比对。

为什么对 AI 代理而言，仅靠 IP 白名单是脆弱的？

Cloudflare 指出，爬取服务的连接可能是共享的，例如隐私代理和 VPN 的情况，而且云 IP 段会随时间变化。在我们于 2026 年 10 月 6 日和 10 月 23 日的两次获取之间，OpenAI 的 chatgpt-user.json 从 230 个 IPv4 前缀增加到了 234 个。

0 到 100 的 IP 风险评分应如何对应结账决策？

allow（25 及以下）直接放行，review（50 及以下）和 step_up（75 及以下）转入 3-D Secure，block（高于 75）拒绝或暂缓。未通过验证的代理声明无论评分多少，都要进行加强验证。

转入 3-D Secure 加强验证会比拦截更损害转化率吗？

拦截必然会失去这笔订单；加强验证则给真实买家留了一条通道。Trust Payments 表示，在成功认证之后，大多数情况下由发卡机构对欺诈性拒付承担责任，但这一点并不能保证。

拦截 AI 代理在我的商店购物合法吗？

这取决于授权情况，以下内容不构成法律建议。2026 年 3 月，一家联邦法院批准了 Amazon 针对 Perplexity 的初步禁令，法官认为 Perplexity 的 Comet 代理在获得用户许可、但未经 Amazon 授权的情况下访问了 Amazon。第九巡回上诉法院于 2026 年 8 月撤销了该禁令，此案仍在审理中。