OpenRouter 连接失败怎么排查：从 401 到 429 的分层检查

OpenRouter 把多个模型供应商放在一个接口后面，报错也继承了这个结构：有的是你自己的 key 或余额问题，有的是上游供应商限流，有的才是网络。判断的第一步不是换代理 IP，而是拿到确切的 HTTP 状态码。下面按状态码分四层排查，每层给一个检查动作和一条记录字段。

先记录状态码和响应头，再判断故障位置

客户端弹的"请求失败"没有信息量。用一条最小请求把真实状态码逼出来：

```bash
curl -i https://openrouter.ai/api/v1/chat/completions \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"你的模型名","messages":[{"role":"user","content":"hi"}]}'
```

记录 HTTP 状态、响应头、响应体中的 error 字段及请求 ID（若返回）。没有 HTTP 响应可能是 DNS、连接、TLS 或超时阶段的问题；拿到 HTTP 响应也不代表故障已定位。通用连接检查可用智能检测助手。

根据 401、402 和 403 检查密钥、余额与权限

状态码本身不足以证明请求在哪一层失败。查看 OpenRouter 返回的错误内容和请求 ID，并将 407（代理认证响应）与 API 凭据错误分开记录。代理认证方式见代理白名单和账号密码怎么选。

遇到 429 时区分速率限制与免费模型额度

429 可能与平台速率限制、模型供应商限制或账户/模型条件有关。若响应含 Retry-After，按其指示等待；没有该头时不要据此判定额度耗尽，应检查错误体、请求 ID、账户状态和模型信息。错误码见 OpenRouter 错误文档，并可核对服务状态页。

若响应提示速率限制或额度问题，应按账户规则降低请求或等待恢复；不以更换 IP 绕过平台限制。代理连接类错误另按网络阶段排查，参见代理错误排查说明。

认证和额度正常后，再排查超时、TLS 与 DNS

排除前两层后，剩下的才轮到网络：

• 连接超时：可能在本机网络、代理连接、上游服务或等待响应阶段
• TLS 握手失败：核对证书链、客户端信任配置和中间层日志
• DNS 解析失败：记录由哪一侧解析及实际查询结果
• 连接重置：结合发生阶段、请求 ID（如有）和客户端/代理/服务端日志判断

按实际失败阶段查看 DNS、TCP 连接、TLS、HTTP 响应和流式响应；curl -v 可提供单次终端请求的线索，但不能替代 OpenRouter 请求 ID、错误体及服务端/代理日志。没有相应证据时，不把某种现象归结为唯一原因。

遇到 403 时核对模型权限、区域策略和服务状态

网络或地区变化可以作为排查时记录的环境信息，但当前文档没有证据支持将多账号共用出口直接判定为 403 或风控原因。遇到 403 时应查看响应体、请求 ID、模型权限与区域策略，并核对 OpenRouter 状态页；如怀疑网络影响，用受控对照和日志验证，不预设平台规则。

排查记录可包含请求时间、状态码、响应头、错误体、请求 ID、模型、流阶段及网络路径；分享前移除 API Key、个人数据和其他敏感字段：

该记录用于区分网络、账户、模型和上游问题，不单独证明某一原因。

FAQ

429 要等多久

有 Retry-After 时按其指示等待。没有该头时查看错误体、账户状态和模型限制，再依据服务文档控制重试；连续出现 429 不能单独证明配额耗尽。

同一个 key 在别的网络能用说明什么

说明该 key 在另一条网络下可用，但当前失败仍可能来自网络路径、区域策略、请求差异或服务状态。比较两次请求的错误体、请求 ID、模型参数和服务端日志，不据此单独判断 IP 信誉。

换网络能解决 401 吗

通常应先检查 API 凭据、响应体和权限；更换网络不能修复无效密钥。结合请求返回判断，不将 401 当作代理故障。

若受控测试显示网络路径影响连接稳定性，可按实际需求评估静态住宅代理 IP；它不能解决账户、模型权限或额度问题，也不能据此保证 403 消失。