x402 把 HTTP 402 带回边缘网络：代理如何为 API 按次付费

预计阅读时间：10 分钟

Cloudflare 和 AWS 在两周内都把 x402 稳定币微支付能力接入了边缘网络，这件事值得后端和平台工程师留意。它不是又一个“支付按钮”，而是把 HTTP 里长期闲置的 402 Payment Required 重新拿出来，用在代理到服务的自动付费场景：AI agent 调 API、抓数据、调用推理服务时，可以按请求支付低于一美分的费用。

这类能力一旦放到边缘节点，支付判断、访问控制和服务调用就可以离用户与代理更近。但它也带来一个现实问题：技术路径正在变清晰，企业财务、税务和发票流程还没有同步成熟。

HTTP 402 从占位符变成协议入口

402 Payment Required 多年来更像 HTTP 规范里的保留座位。x402 的思路是让服务端在资源需要付费时返回 402，并在响应里告诉客户端：需要付多少钱、用什么资产、付到哪里、如何提交付款证明。

对 agent 来说，这比传统订阅制 API key 更自然。一个代理可能只需要调用一次数据接口、一次模型评估、一次文件转换。为了几次调用创建账户、绑定信用卡、走月结，并不符合机器到机器交互的节奏。

x402 试图把流程压缩成：

客户端请求资源。
服务端返回 402 Payment Required 和付款要求。
客户端完成稳定币微支付。
客户端带付款凭证重试请求。
服务端验证后返回资源。

来源摘要提到 Coinbase 报告 x402 第一年有 1.69 亿笔交易。这个数字说明至少在实验和早期生产场景里，按请求微支付已经不是纯概念。

为什么边缘网络是关键位置

Cloudflare 和 AWS 都把 x402 放进边缘网络，这个选择很合理。边缘层本来就处理 TLS、缓存、WAF、限流、身份验证和路由。把“这个请求是否已经付款”也放在这里，能减少后端服务重复实现支付网关逻辑。

可以把它理解成一层新的访问控制：

免费资源：正常放行。
付费资源：边缘返回 402。
已付款请求：边缘验证凭证后转发到源站。
异常请求：继续走限流、风控或拒绝策略。

这对 API 服务商尤其有吸引力。过去你可能要维护套餐、账户、账单、欠费停机、额度系统。x402 更适合另一种粒度：一个请求就是一个计费单元，价格可以低到传统银行卡网络无法经济处理的程度。

边界也很明显。微支付解决的是“机器能不能自动付这一小笔钱”，并不自动解决企业采购、成本归集、税务发票、退款和审计。摘要里提到企业税务和开票缺口仍未解决，这是采用时不能绕开的点。

可以这样实践：用 HTTP 402 模拟 x402 付费握手

下面是一个最小可运行示例，用 Node.js 模拟 x402 风格的握手。它不连接真实区块链，也不代表 Cloudflare 或 AWS 的实现细节，只演示服务端如何用 402 返回付款要求，以及客户端如何带付款凭证重试。

运行前需要本机安装 Node.js 18 或更高版本。

创建 server.mjs：

import http from "node:http";

const PORT = 8787;
const EXPECTED_PROOF = "demo-paid-receipt-123";

const server = http.createServer((req, res) => {
  if (req.url !== "/premium-data") {
    res.writeHead(404, { "content-type": "application/json" });
    res.end(JSON.stringify({ error: "not_found" }));
    return;
  }

  const paymentProof = req.headers["x-payment-proof"];

  if (paymentProof !== EXPECTED_PROOF) {
    res.writeHead(402, {
      "content-type": "application/json",
      "x-accept-payment": "x402-demo"
    });
    res.end(JSON.stringify({
      error: "payment_required",
      protocol: "x402-demo",
      amount: "0.001",
      asset: "USDC",
      network: "base",
      payTo: "0xDemoMerchantAddress",
      retryWithHeader: "x-payment-proof"
    }, null, 2));
    return;
  }

  res.writeHead(200, { "content-type": "application/json" });
  res.end(JSON.stringify({
    dataset: "edge-priced-api",
    rows: [
      { region: "iad", latency_ms: 12 },
      { region: "sin", latency_ms: 31 }
    ]
  }, null, 2));
});

server.listen(PORT, () => {
  console.log(`demo API listening on http://localhost:${PORT}`);
});

启动服务：

node server.mjs

另开一个终端，请求付费资源：

curl -i http://localhost:8787/premium-data

你会看到类似响应：

HTTP/1.1 402 Payment Required
content-type: application/json
x-accept-payment: x402-demo

{
  "error": "payment_required",
  "protocol": "x402-demo",
  "amount": "0.001",
  "asset": "USDC",
  "network": "base",
  "payTo": "0xDemoMerchantAddress",
  "retryWithHeader": "x-payment-proof"
}

模拟客户端完成付款后重试：

curl -i \
  -H 'x-payment-proof: demo-paid-receipt-123' \
  http://localhost:8787/premium-data

这次服务端返回 200 和付费数据。真实系统里，x-payment-proof 不应该是固定字符串，而应该是可验证的链上交易、签名凭证或由支付协调方签发的证明。边缘函数可以在转发请求前完成验证，把源站从支付细节里解耦出来。

在边缘落地时要设计哪些接口

如果要把这个模式改造成生产方案，可以从三个接口开始拆：

# x402-policy.yaml
routes:
  - path: /premium-data
    price:
      amount: "0.001"
      asset: USDC
      network: base
    settlement:
      merchant_address: "0xYourMerchantAddress"
    access:
      proof_header: x-payment-proof
      cache_paid_result_seconds: 30

这份 YAML 不是某个厂商的真实配置，而是一个工程化切分示例。它把路由、价格、结算地址和付款凭证位置放在一起，便于边缘层加载策略。

实际实现时建议至少补上这些能力：

幂等性：同一笔付款不要因为客户端重试被重复消费。
过期时间：付款证明应有有效期，避免被长期复用。
价格版本：服务端返回的价格需要可追踪，避免请求和支付期间价格变化。
风控限制：低价不等于无限调用，仍然需要限流和异常检测。
审计日志：记录请求 ID、付款 ID、路由、金额和验证结果。

采用建议：先放在低风险、低客单价 API 上

x402 的吸引力在于它把“agent 调用服务并即时付费”变成 HTTP 层可以表达的动作。Cloudflare 和 AWS 的边缘实现说明，这个方向正在从协议讨论进入基础设施层。

但现在不适合把它直接塞进所有企业核心交易链路。更稳妥的切入点是：公开数据 API、一次性工具服务、模型评估接口、开发者沙箱、低价高频的机器调用场景。这些地方对账户体系依赖较弱，也更能体现微支付的价值。

上线前可以用这份检查表压一下风险：

是否能解释每一笔请求级收费的业务含义？
是否有税务、发票和企业报销处理方案？
是否支持退款、争议处理和错误扣费追踪？
是否能把付款验证放在边缘，同时保留源站审计？
是否有 fallback，例如传统 API key、套餐或账单账户？

x402 让 HTTP 402 重新有了工程意义。真正的挑战不是返回一个新状态码，而是把微支付、边缘访问控制和企业财务现实接在一起。