OpenRouter 美国区域内路由：设置方法与限制

OpenRouter 的美国区域内路由，不只是“优先选择美国供应商”这么简单，它真正解决的是数据驻留问题。但这项能力也有明确限制：仅面向 Business 和 Enterprise 套餐；如果某个模型没有符合条件的美国端点，请求会直接失败，而不会绕道全球节点完成。

30 秒看懂是否值得用

如果组织必须确保提示词处理始终在美国境内，同时又希望继续使用多个模型供应商，OpenRouter 美国区域内路由值得纳入评估。对于普通公开数据工作负载，它通常没有必要；此外，它也不能替代零数据留存设置，更不能省略对供应商条款的审查。

OpenRouter 于 2026 年 9 月 9 日宣布推出美国路由，此前已经提供欧盟端点。官方公告表示，发送至美国主机名的请求，在整个请求生命周期内都会在美国完成解密和处理。

可以将美国路由用于敏感服务，同时让低风险流量继续走全球路由；迁移不必一次完成。

区域端点究竟控制了什么

区域主机名决定 OpenRouter 在哪里解密和处理请求，也决定请求可以交由哪些供应商端点处理。OpenRouter 还表示，服务器工具会根据司法管辖区进行评估；如果某个工具会把数据发送到所选区域之外，系统会将其禁用，而不是悄悄改用全球基础设施。

模型厂商来自哪个国家，并不能说明网关在哪里解密数据，也不能证明推理发生在哪里。

OpenRouter 描述的处理路径如下：

1. 请求首先到达 us.openrouter.ai。
2. TLS 终止、解密、网关处理以及符合条件的服务器工具处理都在美国完成。
3. 路由时只考虑在美国运行的供应商端点。
4. 符合条件的供应商在美国执行推理。
5. 如果不存在符合条件的路由，OpenRouter 返回 404 No endpoints found supporting your data region.。

这种“失败即停止”的行为非常关键。全球回退当然能提高可用性，但会破坏严格的数据驻留策略；对于区域请求，OpenRouter 选择优先保证驻留位置，而不是保证请求一定完成。

“相比供应商国籍，更重要的是实际数据路径、日志策略、子处理者、托管区域，以及能否强制执行零数据留存。”——r/openrouter 用户 u/MembershipEmergency7

这正是采购评估应该采用的视角。区域路由回答了 OpenRouter 所承诺的处理位置问题，但合同、留存策略、子处理者、审计导出和安全事件流程，仍然需要单独审查。

如何发送一条美国区域路由请求

配置 OpenRouter 美国区域内路由，通常只需要更换 API 基础 URL，不必重写请求。同一个 API 密钥、请求体、模型 ID、供应商偏好、回退设置和隐私参数都可以继续使用。

1. 确认套餐权限

OpenRouter 将区域内路由列为 Business 和 Enterprise 客户功能。公开的定价页面显示，按量付费使用收取 5.5% 的平台费用，但没有公布美国路由单独的自助服务附加费；在制定预算前，应确认 Business 套餐或合同价格。

2. 查找美国区域可用的模型

通过区域主机名查询模型端点。返回的目录只包含至少拥有一个符合条件的美国供应商端点的模型。

curl https://us.openrouter.ai/api/v1/models \
  -H "Authorization: Bearer $OPENROUTER_API_KEY"

区域模型目录会随着供应商和部署变化而变化。因此，模型发现应当纳入部署检查，而不是只维护一份更新一次的静态表格。

3. 使用美国基础 URL 发送请求

curl https://us.openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/llama-3.3-70b-instruct",
    "messages": [
      {"role": "user", "content": "Summarize this internal policy."}
    ]
  }'

示例中的模型来自 OpenRouter 的主权 AI 文档。投入生产前，仍应通过实时美国区域目录确认它当前可用。

4. 使用 Guardrails 强制限定区域

应用配置可能随着时间发生偏移。根据 OpenRouter 的主权 AI 文档，Guardrails 可以将工作区、团队、成员或 API 密钥的 allowed_data_regions 设置为 us；如果请求发往不允许的主机名，系统会在处理前返回 HTTP 403。

对于受监管应用，将工作区默认值设为美国区域是更稳妥的基线，因为这样不依赖每位开发者都记得使用区域主机名。对于敏感服务，还可以通过单独的密钥规则设置比工作区默认值更严格的限制。

5. 不仅测试成功，也要测试失败

用一个美国目录中支持的模型测试一次，再用一个不在美国目录中的模型测试一次。针对区域路由返回的 404 设置专门告警，避免运维人员为了“修复”问题，直接把基础 URL 改回全球端点。

别把这些隐私控制混为一谈

美国区域内路由解决的是地理位置问题；ZDR、数据收集过滤和供应商条款解决的是其他风险。合规设计可能需要同时启用这四类措施，但打开其中一项，并不代表其他措施也自动生效。

OpenRouter 的供应商日志文档特别说明了一个重要区别：用户可以根据供应商的训练或数据收集政策进行过滤，但留存要求不会自动转化为路由规则。团队仍需自行评估供应商条款。

一条严格的请求可以同时使用区域路由和隐私参数：

{
  "provider": {
    "zdr": true,
    "data_collection": "deny"
  }
}

每增加一项限制，符合条件的供应商集合就会进一步缩小。最终出现 404 或可选模型减少，是策略生效后的结果，不一定意味着路由出了故障。

上线前，先验证真实工作负载

生产审核应当验证实际路由及其失败行为，而不能仅凭“美国供应商”这几个字就通过。现实中的难点在于可审计性：OpenRouter 已经说明了地理位置保证，但公开资料并没有提供一份统一的、覆盖所有模型和供应商的矩阵，同时列出延迟、留存条款、缓存行为和合同证据。

可以按以下顺序完成审批：

1. 使用与生产环境相同的账户和隐私设置查询美国模型目录。
2. 选择所需模型，并记录 OpenRouter 显示的符合条件的供应商端点。
3. 在工作区或 API 密钥层面启用美国区域 Guardrails。
4. 如果工作负载同时要求两项能力，则启用 ZDR 并拒绝数据收集。
5. 通过采购流程确认供应商当前的留存条款和子处理者。
6. 记录模型、实际服务供应商、请求 ID、状态、延迟以及与策略相关的失败。
7. 测试一个不可用模型，并确认没有任何代码路径会通过 openrouter.ai 重试。
8. 当模型、供应商偏好或隐私规则发生变化时，重新执行检查。

社区反馈也说明了为什么上线后仍需持续观察路由。在一场 Reddit 讨论中，u/Cooperman411 表示：“我找不到 Deepseek 这个供应商，因为我开启了 ZDR（零数据留存）。”这只是个案，不是基准测试，但它确实说明隐私控制可能会排除原本预期的路由。

不要直接套用其他工作负载报告的缓存命中率或延迟数据。供应商选择、隐私过滤条件、提示词形态、模型部署和流量状况都可能改变结果；应当使用贴近生产环境的请求进行测量。

什么情况下值得购买美国区域内路由

OpenRouter 美国区域内路由适合那些需要“失败即停止”的美国处理边界，同时又愿意接受模型目录缩小、以换取多模型访问能力的组织。个人开发者以及没有正式数据驻留要求的团队，通常应继续使用全球端点，因为区域功能需要更高等级的套餐，而且可能降低可用性。

选择它的理由应当是数据驻留，而不是想当然地追求速度：OpenRouter 尚未发布美国端点的通用延迟基准，而且区域内的供应商池可能不同。

OpenRouter 美国区域内路由 FAQ

工具调用也会留在美国吗？

OpenRouter 表示，它会根据司法管辖区评估服务器工具，并禁用那些会把数据发送到所选区域之外的工具。部署前，应针对工作负载实际需要的具体工具完成验证。

这个保证涵盖所有元数据吗？

发布材料明确讨论了提示词、补全结果、请求处理、供应商路由和服务器工具。对于组织政策要求覆盖的账单记录、滥用监测数据、日志、备份及其他元数据，应向 OpenRouter 询问合同层面的详细说明。

个人账户可以使用美国端点吗？

现有文档将区域内路由限定为 Business 和 Enterprise 套餐，并未覆盖 Free 或普通按量付费层级。没有套餐权限的开发者仍然可以使用隐私和供应商路由控制，但这些控制不能替代区域处理保证。

只有在区域模型目录、Guardrails 拦截机制、经过隐私过滤的供应商池以及供应商条款全部通过审核后，才应批准上线。如果其中一项检查失败，就调整模型或重新设计工作负载；使用全球回退会直接破坏数据驻留边界。