需要固定处理方时，在请求中设置供应商允许名单，并检查最终发出的请求和实际处理记录。仅调整优先顺序，不足以证明请求不会交给名单外的供应商。 如果业务要求“指定端点不可用就停止”，验收重点应包括失败路径，而不只是成功返回文字。
本文针对 OpenRouter Chat Completions HTTP 接口，官方资料复核日期为 2026-10-03。配置是需替换占位符的示例，没有执行付费推理、模拟供应商故障或测量缓存命中率。若还在比较接入路线，先看 OpenRouter 与厂商直连的采购检查表。
如何屏蔽 OpenRouter 的某个供应商
单次请求中，在 JSON 请求体加入 "provider": {"ignore": ["REPLACE_WITH_PROVIDER_SLUG"]}，并将占位符替换为当前供应商 slug。only 是允许名单，ignore 是排除名单，order 是优先顺序。
要在账户范围屏蔽，使用 OpenRouter 隐私设置。账户与请求的排除名单合并生效，请求不能清除账户屏蔽；屏蔽更多供应商会减少故障恢复选项。这些规则已于 2026-10-21 核对 官方路由文档。
操作前先写明必须排除谁，以及是否接受其他处理方。随后检查脱敏后的最终请求，包括重试，并按下文核对实际处理记录。如果没有合适路由，保留失败记录，不要在重试时移除限制。这里提供的是验收方法，没有执行推理或故障实测。
先写出允许发生的结果
把下面这张表填进项目配置说明，让开发和采购使用同一个验收口径。
| 业务选择 | 成功时应看到什么 | 不可用时如何处理 |
|---|---|---|
| 只是偏好 A | 可以接受其他处理方，日志能解释选择 | 在事先认可的范围内恢复服务 |
| 只接受 A | 每个已验收结果都能归因到 A | 显示暂不可用，排队或人工处理 |
| 接受 A、B，优先 A | 每次结果均来自 A 或 B | 两者都不可用就停止 |
| 只接受某个具体端点 | 证据能对应端点，不能只显示公司名 | 无法证实端点时不算通过验收 |
“必须回答”和“必须使用某个处理方”发生冲突时，产品要先决定保留哪项约束。不要让重试代码临时做这个决定。
配置中最容易混淆的字段
按 官方 Provider Routing 文档，order 设置尝试顺序，only 限制允许名单；allow_fallbacks: false 可配合 order 把尝试范围限制在指定列表。require_parameters: true 排除不支持所需参数的供应商。
基础供应商 slug 可能匹配多个地区或变体，具体端点应从模型页复制完整 slug；特殊服务层级另有规则。请求名单还受账户允许名单限制，两者没有交集时文档规定返回 404。以上配置均不能代替业务结果校验。
单一端点的请求模板
先在目标模型页面确认当前支持的端点，把下面两个大写占位符替换为实际值。此模板故意只用一个 model，也不添加模型候选列表。
{
"model": "REPLACE_WITH_MODEL_ID",
"messages": [
{ "role": "user", "content": "Return the word ready." }
],
"stream": false,
"provider": {
"only": ["REPLACE_WITH_EXACT_ENDPOINT_SLUG"],
"allow_fallbacks": false,
"require_parameters": true
}
}将它作为 JSON 请求体发送到 https://openrouter.ai/api/v1/chat/completions，在服务端添加 Authorization: Bearer <你的密钥> 与 Content-Type: application/json。不要把密钥放进网页、截图或版本库。这里使用的是 HTTP 字段名；通过 SDK 或第三方客户端配置时，要核对该工具如何传递扩展参数。
第一步的短输入只用于排查路由。之后换成一条脱敏的真实业务样本，例如提取订单号、币种和金额，并写出期望字段。返回 ready 并不意味着结构化输出、工具调用或流式响应已通过验证。
找出应用里的第二层回退
OpenRouter 还支持通过顶层 models 列表尝试其他模型，这是 模型回退机制。不要把供应商回退开关当成整个应用的停止开关。
沿着“业务调用 → SDK → 自建代理 → OpenRouter”逐层检查，保存脱敏后的最终请求体，而不是只截取配置页面：
- 比较首次请求与重试请求，确认
provider对象没有被丢弃或改写。 - 查找应用的备用模型、备用 Base URL 和异常捕获分支，确定失败后不会偷偷转到另一条链路。
- 为一个业务任务分配自己的任务 ID，逐次记录尝试；不要把第三次成功显示成第一次调用成功。
- 用本地桩返回失败响应，验证页面提示、队列状态和重试上限。桩测试只能证明应用行为，不能证明真实供应商发生故障时的路由行为。
如果允许两个处理方，给它们各跑同一份业务样本并分别验收。不要因名称属于同一模型系列，就假定输出格式与失败方式完全一致。
一份可以执行的验收记录
下面是建议执行的检查，不是本站的测试成绩。首次真实请求可能产生费用，应使用自己的测试账户与预算。
| 检查 | 保存的证据 | 通过条件 |
|---|---|---|
| 配置传递 | 脱敏的最终 JSON、客户端版本、配置版本 | 允许名单及参数完整到达请求出口 |
| 正常业务样本 | 请求 ID、模型、处理方、字段校验结果 | 来源与结果同时符合预期 |
| 无可用候选 | 在独立测试账户构造无交集名单，记录响应 | 明确失败，应用不移除限制重试 |
| 应用错误分支 | 本地桩的调用次数、队列及界面状态 | 达到约定上限后停止，不执行重复业务动作 |
| 切换发布版本 | 变更前后的配置快照与同题结果 | 新版本没有扩大允许范围 |
不要为了做负例修改生产账户的全局偏好，也不要把拼错模型名得到的错误当作供应商约束生效的完整证据。测试账户不具备所需条件时，将这一项记为“未验证”，保留上线阻碍。
成功请求可保存返回的 generation ID，再按 Generation 查询接口 查询 GET /api/v1/generation?id=<generation-id>，核对 model、provider_name 和 total_cost 等元数据。公司级 provider_name 本身不足以证明具体地区或端点；证据不足时不要填写“地区已验证”。
建议一行记录：任务ID / 尝试次数 / 配置版本 / generation ID / 实际模型 / 处理方 / 结果校验 / 费用 / 未验证事项。不必把用户原始文本存入路由日志。
收到错误后，按证据排查
先核对模型与端点是否仍匹配，再检查账户与请求限制是否冲突，最后查看真实业务参数是否受支持。错误码只提供入口，不能单凭一个 404 就判断原因；保留响应里的错误说明及请求上下文。
如果直接 HTTP 请求符合预期、某个客户端却不符合，比较两者发出的脱敏请求。如果失败只出现在真实业务样本，逐项加入工具或输出格式约束定位差异，不要通过删除全部约束换取“能用了”。
上线条件应写成“来源可核对、结果可验收、失败能停止”。锁定供应商不会自动保证缓存命中、速度、质量或数据驻留；这些目标需要各自的证据。相关入口：OpenRouter 工具说明、API 成本预算。