LeisureLinux · 微信公众号文章

x402：把沉睡 28 年的 HTTP 402 状态码唤醒的网页支付协议

2026-07-10 18:20 AI/Agent 阅读原文（微信）↗

沉睡 28 年的 HTTP 402 ，终于被 x402 这套协议叫醒了。它是 AI Agent 时代原生支付的事实标准。——Coinbase, 2025.05

1997 年 RFC 2068 把 HTTP 402 "Payment Required" 状态码写进规范时，互联网还找不到一个能稳定支持它的支付系统。28 年后，Coinbase 在 2025 年 5 月把这个沉睡的代码正式激活——它叫 x402 ，目前已经成为 AI Agent 时代"机器对机器"小额支付的事实标准。

本文解读 x402 的前世今生：协议怎么工作、谁在用它、安全风险如何解决、它的采用路线图走到哪了。最后附名词解释和参考文献。

📌 本文看点

28 年沉睡史

协议机制 + JS

安全 + 路线图

THE 28-YEAR WAKE

一个意外的发现：HTTP 402 沉睡了 28 年

1997 年的 RFC 2068 在定义 HTTP 状态码时，留了一个 402 "Payment Required"。它的意图很明确：给未来的互联网一个原生处理小额支付的状态码。

但这个意图被现实搁置了：

支付基础设施缺失

28 年前能用的支付手段都是信用卡 / 网银，单笔手续费就超过几分钱。"为了一篇文章付 0.01 美元"既不划算也没渠道。

没有标准用法

浏览器、服务器、网关都不知道该拿 402 怎么办，RFC 写了"reserved for future use"就一直 reserved。

失败尝试无数

2003 年 W3C 成立过 Micropayments Working Group，试图定义一套浏览器侧微支付方案，最终不了了之；2018 年有人用 Bitcoin Lightning Network 探索过类似的"按请求付费"，也没形成标准。

x402 在 2025 年 5 月由 Coinbase 推出后，终于给了这个老状态码一个能跑起来的协议： USDC 这类稳定币 + 多链结算 + HTTP 原生 header 流。状态码本身没变，变的是它背后的支付基础设施终于成熟了。

HOW IT WORKS

x402 是怎么跑起来的

x402 的整个交互可以压缩成 4 步 HTTP 请求-响应循环，全部复用现有 HTTP 头，没有自定义端口、没有新协议。

第 1 步：客户端请求受保护资源

这是普通的 GET / POST，没有任何特殊 header。客户端（可能是 AI Agent，可能是浏览器）向 https://api.example.com/v1/data 发起请求。

第 2 步：服务器返回 HTTP 402 + 支付说明

服务器把资源判定为"付费内容"，响应一个 HTTP 402 \"Payment Required\" 。这个响应里关键新增了两块内容：

HTTP header：PAYMENT-REQUIRED——base64 编码的 JSON，描述这次需要付多少钱、收款的链上地址、接受的稳定币、所在网络。
HTTP header：WWW-Authenticate——保留传统浏览器挑战语义。

json · PAYMENT-REQUIRED (base64 decoded)

{

\"amount\": \"0.10\",

\"currency\": \"USDC\",

\"network\": \"eip155:84532\",

\"payTo\": \"0xAbC...123\",

\"scheme\": \"exact\"

}

第 3 步：客户端签名付款并重试

客户端钱包解析出支付条款后，离线签名一个稳定币转账授权（通常用 EIP-3009 transferWithAuthorization 或 Solana 的类似机制），把签名后的 payload base64 编码后塞进 PAYMENT-SIGNATURE header，再次请求同一个 URL。

这里有个细节：付款通常不是立即链上确认，而是把授权凭证提交给 facilitator （结算服务，Coinbase 自营或第三方），由 facilitator 验证签名、广播上链、最终清算。

第 4 步：facilitator 验证 + 服务器交付资源

facilitator 校验：

契约一致性

金额、收款人、收款链是否一致。

防重放

nonce 是否已用过（防重放攻击）。

签名合法

签名是否合法、授权未撤销、余额是否足够。

整套流程在 2\~5 秒内完成。Solana 等快链可以做到 400ms 内确认。

JS DEMO

JS 代码层示意：用 fetch 一行接入

如果你想在自己的 Web/Node 项目里接入 x402，最简洁的方式是用官方 SDK。一段最小化示例（用 ethers + fetch 包装）：

. . . javascript · client.js

import { wrapFetchWithPayment } from \'@x402/fetch\';

import { x402Client } from \'@x402/core\';

import { ExactEvmScheme } from \'@x402/evm\';

import { ethers } from \'ethers\';

async function getSigner() {

if (typeof window.ethereum === \'undefined\') throw new Error(\'No wallet\');

 const provider = new ethers.BrowserProvider(window.ethereum);

 return provider.getSigner();

}

async function payAndFetch(url) {

 const signer = await getSigner();

 const client = new x402Client({ signer, schemes: [new ExactEvmScheme()] });

 const fetchWithPay = wrapFetchWithPayment(client);

// 拦截 402，自动签名重试

 const res = await fetchWithPay(url);

 return res.json();

}

payAndFetch(\'https://api.example.com/premium\')

.then(data => console.log(\'已付费拿到内容：\', data));

上面是协议主流调用方式的简化演示。完整 SDK 在 @x402/core 、 @x402/evm 、 @x402/express 等 npm 包里，源码完全开源。

.      .      .      javascript · server.js (Express)

import express from \'express\';

import { paymentMiddleware } from \'@x402/express\';

const app = express();

app.use(paymentMiddleware(\'0xMyWallet...\', {

\'/api/premium\': {

amount: \'0.10\', currency: \'USDC\',

network: \'eip155:84532\', // Base Sepolia 测试网

facilitator: \'https://x402.org/facilitator\',

}));

app.get(\'/api/premium\', (req, res) => {

// 仅在 paymentMiddleware 验证通过后才执行

res.json({ secret: \'这是你付费后才能看到的内容\' });

});

app.listen(3000);

PROBLEMS SOLVED

x402 解决了哪些老问题

x402 不是第一个想做"HTTP 微支付"的协议，但它是第一个真正跑通大规模采用的。它一次性解决了老一代微支付方案的多个痛点：

老问题	过去的尝试为何失败	x402 的解法
单笔手续费太高	信用卡 / PayPal 单笔 ≥ 0.30 美元	稳定币链上转账费 \< 0.001 美元
没有原生 HTTP 集成	需重写协议或浏览器插件	直接复用 HTTP 402 + 标准 header
机器友好标准缺失	每个公司一套私有 API	标准化 PAYMENT-REQUIRED JSON schema
需要先注册账户	API key、信用卡绑定、KYC	钱包即身份，无需注册
结算延迟大	信用卡清算要 T+1 \~ T+3	链上 2\~5 秒，Solana 400ms
无 AI 原生支持	API key 配 agent 麻烦且不优雅	钱包 + facilitator 让 Agent 自主签名

最后一条最关键：x402 是为 AI Agent 设计的原生支付协议。Agent 需要按次调用 LLM / 数据 API / 算力，传统的"申请 key → 绑定信用卡 → 算钱"流程完全不适合。

ROADMAP & ADOPTION

Adoption 路线图：2025 → 2026 走到哪了

x402 的采用速度比预想中快得多。下面是几个关键时间点：

2025·05 Coinbase 发布 x402 v1

主网上线，AI Agent 第一次能用 HTTP 402 自动付款。

2025·12·11 x402 v2 发布

改进 PAYMENT-REQUIRED schema，新增 upto 授权模式（最大授权额度）和跨链路由。

2025 年底累计 1 亿笔交易，年化约 6 亿美元

对一个上线仅 7 个月的支付协议，体量增长曲线相当陡。

2026·04·02 x402 Foundation 在 Linux Foundation 下成立

创始成员包括 Coinbase、Cloudflare、Stripe、Visa、Mastercard、Google、Microsoft、AWS——这几乎是支付 + 互联网 + 云三条赛道的全部头部公司。

2026·05·11 v2.1 Batch Settlement 扩展

用密码学凭证 + 批量链上兑现，实现"亚分"级（sub-cent）延迟极低的 Agent 支付。

2026·07·01 Cloudflare Stablecoin Monetization Gateway

让任何部署在 Cloudflare 上的 API 一键开启按请求付费，waitlist 已开放。

2026·10 (预期) Multi-Party Payment (MPP) GA

日本与 APAC 企业市场预计上线数百个 x402 Bazaar endpoint。

1.19 亿+

Base 单链 x402 累计交易（2026·03）

\$6 亿/年

整个 x402 生态年化交易额

SECURITY MODEL

安全问题：x402 是怎么扛住攻击的

一个真正能跑起来的支付协议，必须直面三种典型攻击：重放、欺诈、合规失效。

6.1 重放攻击（Payment Replay）

！威胁

攻击者截获一次合法的 PAYMENT-SIGNATURE，对其他资源重复使用同一笔付款凭证。

→ x402 的解法

唯一 nonce：每次付款授权附带唯一 nonce，facilitator 维护已用 nonce 数据库，发现重复立即拒绝。
短过期时间：授权 payload 有 30\~120 秒的过期时间。
绑定收方/路径：授权绑定特定收款人 / 金额 / 资源路径，即使 nonce 重放也不匹配当前 challenge。

6.2 欺诈交易（Fraudulent Transactions）

！威胁

恶意 Agent 用被盗钱包或低额刷量攻击付费 API。

→ x402 的解法

托管 facilitator内置 KYT、OFAC 制裁名单筛查和异常行为模式识别。
第三方反欺诈服务如 t54 的 x402-Secure 在 settlement 之前评估 Agent 行为画像。
链上不可逆提供一层事后追溯能力。

6.3 钱包与密钥泄露

！威胁

Agent 自动签名的私钥被窃取，攻击者可以随意付费调用受害方 API。

→ x402 的解法

硬件钱包 / MPC 钱包作为 Agent 的金库
单笔额度限制+ 白名单收款人缩小密钥泄露后的损失面。
定期轮换会话密钥，配合链上 nonce 防重放。

6.4 合规与监管

！威胁

Agent 自主付款可能绕过传统 KYC 和反洗钱控制，引发监管风险。

→ x402 的解法

协议本身是技术规范，不强制某种合规方案，但 Coinbase 官方 facilitator 已经集成 KYT。
Linux Foundation 下的 x402 Foundation 已经把合规框架设计列入 v3 路线图。
稳定币本身受 GENIUS Act（美国）/ MiCA（欧盟）等新法规约束。

💡 支付安全公司 Halborn 在 2026 年对 x402 facilitator 做了独立审计："协议设计稳健，但 facilitator 实现需要持续审计。"

∞

THE END

不完美：x402 的真实短板

再好的协议也不是银弹。x402 当前还面临四个真实短板：

生态集中度高：Cloudflare 的 Monetization Gateway 用得最多，但目前是等待名单制，对非 CF 用户门槛较高。
钱包用户体验：Agent 调用方需要自己保管钱包，私钥管理不当就是安全事故。
监管不确定：不同司法管辖区对"机器自主付款"的合规定义还在演进，跨境支付仍可能踩到灰色地带。
AI Agent 滥用风险：缺乏授权滥用的上层标准，理论上 Agent 可以被诱导反复付款到恶意服务。

这些是 v3 路线图重点解决的问题，但短期内集成方仍需自带风险控制层。

互联网正在从"为人类设计的按月订阅"切换到"为 Agent 设计的按次付费"。

 **后记：**本文基于 x402 官方规范 (x402.org)、Coinbase Developer Platform 公告、Linux Foundation x402 Foundation 成立公告、Cloudflare Monetization Gateway waitlist、Halborn 安全审计及 Allium Analytics 数据综合整理。"AI Agent 复用风险"段落为综合分析观点，非协议官方表述。半年内如协议升级到 v3 或 facilitator 实现有重大变化，本文部分结论可能需要更新。

---

本文完。欢迎关注 LeisureLinux，获取更多深度技术解读。

📖 名词解释

HTTP 402 Payment Required：1997 年 RFC 2068 定义的 HTTP 状态码，原本为微支付设计，x402 之前从未被标准化使用过。

Stablecoin（稳定币）：与法币挂钩的加密货币，常见如 USDC（1 USDC ≈ 1 USD），避免加密币价格波动。x402 默认主要使用 USDC。

Facilitator（结算服务商）：x402 中负责验证付款签名、把交易广播上链、确认结算的中介服务。Coinbase 的官方 facilitator 是主流实现。

EIP-3009：以太坊提案标准，定义了离线签名授权机制（transferWithAuthorization），让钱包无需联网就能预先签发"未来某时某刻转账 X 给 Y"的授权。

PAYMENT-REQUIRED / PAYMENT-SIGNATURE：x402 新增的两个 HTTP header。前者描述付款条件（金额/收款人/币种），后者携带签名后的付款凭证。

Nonce：付款授权里的唯一标识符，防止同一笔授权被重复使用（防重放攻击）。

KYT（Know Your Transaction）：实时检查链上交易是否涉及制裁地址、混币器、异常模式等。Coinbase facilitator 内置。

OFAC Screening：美国财政部外国资产控制办公室（OFAC）的制裁名单筛查。合规必备。

Batch Settlement：x402 v2.1 引入的批量结算扩展，用密码学凭证聚合多笔付款后一次性链上结算。

A2A x402 Extension：Google 在 2026 年推出的官方扩展，让 A2A（Agent-to-Agent）通信协议的 Agent 用 x402 结算付款。

x402 Bazaar：x402 Foundation 维护的"市场"，列出已支持 x402 的 API endpoint。

Linux Foundation：1999 年成立的非营利组织，托管大量开源基础设施项目，x402 Foundation 于 2026 年挂靠其下。

📚 参考文献 / References

x402 官方网站 / 协议规范 · x402.org · 访问于 2026-07-10
Coinbase Developer Platform · 'x402: Internet-native payments' · coinbase.com · 2025-05 发布
RFC 2068 · 'Hypertext Transfer Protocol——HTTP/1.1' · IETF · 1997 · HTTP 402 状态码原始定义
x402 Foundation @ Linux Foundation · linuxfoundation.org · 2026-04-02 成立公告
Cloudflare · \"Stablecoin-Powered Monetization Gateway\" · cloudflare.com · 2026-07-01 waitlist
Google A2A x402 Extension · a2a.dev · 2026
Halborn Security Audit Report · x402 Facilitator 安全审计 · halborn.com · 2026
Allium Analytics · \"x402 Adoption Metrics 2026\" · allium.so · 2026-03
Aei.org · \"The Machine Economy: AI Agents Need Their Own Money\"
Stablecoin Insider · \"GENIUS Act and Its Implications for x402\"

如果你觉得今天这篇 x402 解读有收获，欢迎 点赞、在看、转发 三连，我们下篇见。

END

Web 4.0：当 AI Agent 成为互联网的"一等公民"

从 SNI 泄露到 ECH 全链路加密：OpenSSL 4.0 强制驱动的 DNS 架构演进

2026 系统架构演进：50个核心概念及规范 (2026版)

架构师的清醒指南：系统设计本质是"权衡"的艺术

常见问题（FAQ）

Q1：x402 是什么？ A1：Coinbase 在 2025 年 5 月推出的协议，唤醒了沉睡 28 年的 HTTP 402 "Payment Required" 状态码，成为 AI Agent 时代「机器对机器」小额支付的事实标准。

Q2：它具体怎么工作？ A2：一个 4 步 HTTP 循环：客户端请求资源 → 服务器返回 402 + PAYMENT-REQUIRED（base64 编码 JSON，含金额/收款地址/稳定币/网络）+ WWW-Authenticate → 客户端完成支付 → 服务器放行资源。

Q3：为什么 28 年前做不到，现在才行？ A3：此前缺支付基础设施（单笔手续费就超过几分钱）、无标准用法；如今 USDC 等稳定币 + 多链结算 + HTTP 原生 header 流成熟，才让这个老状态码跑起来。

Q4：安全和手续费怎么解决？ A4：用稳定币做微支付，多链结算；协议的安全模型与采用路线图在原文有专门章节展开。

本文整理自微信公众号 LeisureLinux 的原创内容（Linux / AI / 安全硬核技术）。

· 阅读原文（微信公众号）

· 关注公众号 LeisureLinux，第一时间获取技术深度内容。