OpenRouter 请求超时怎么办？先定位连接、响应还是流中断
按连接失败、HTTP 错误和流式中断定位 OpenRouter 超时，检查客户端重试与代理限制，保留证据并避免重复执行。
Ofox 
OpenRouter 请求超时，先判断它停在连接前、首个响应前，还是流式输出途中。 保存错误正文、时间和可获得的请求 ID，再决定延长等待还是调整调用方式。
本文把通用 HTTP 与客户端排查方法用于 OpenRouter 请求，没有进行新的 OpenRouter 实际调用，也不据此声称平台发生故障或某个供应商应负责。
三种现象，分别处理
| 现象 | 保存证据 | 下一步 |
|---|---|---|
| 无法建立连接 | DNS、TLS 或连接错误及时间 | 检查网络和 endpoint 配置 |
| 服务端返回 HTTP 错误 | 状态码、错误正文、请求 ID | 按实际错误处理，不统称超时 |
| 输出开始后中断 | 最后完整事件、持续时间、结束状态 | 标记结果不完整，检查客户端和代理时限 |
限流与超时不是同一问题。Kimi 的 429 错误可先看对应限流排查（英文）。
先检查客户端
记录 SDK 名称与版本、endpoint、模型、是否开启流式输出。确认 SDK 是否自动重试：看起来的一次调用，可能已经发送多次请求。应用服务器或托管代理也可能有更短的时限。
如果现有监控支持，分别看连接耗时、首字节耗时和总耗时。流式请求收到响应头，不代表完整生成成功。不要把 API key、授权头或用户私密内容贴进公开工单。
缩小到一次可复现请求
- 保存原错误和时间。
- 使用已获授权的小输入，以及账户已可用的模型。
- 明确记录重试次数；诊断时只按客户端文档支持的方式关闭自动重试。
- 每次只改变一个变量，例如代理、流式开关或输入大小。
- 比较其他路由时核对其参数，不假定另一网关的配置可以直接照搬。
小请求成功能缩小范围，却不能证明生产可靠性；失败也需要日志才能定位是哪一层。
参考文档要保留适用范围
OpenAI 错误说明可帮助区分连接错误、超时和返回的 API 错误，但它描述的是 OpenAI 服务及 SDK，不是 OpenRouter 的服务保证。实际修复应依据当前网关响应和所用客户端文档。
2026 年 9 月 16 日拍摄的 OpenAI 官方页面，保留英文界面。这不是 OpenRouter 控制台截图，也不是我们复现出的 OpenRouter 故障。
重试前检查是否会重复执行
只重试适合重复的操作，设定次数上限，并遵守文档中的重试指导。客户端断开时，上游可能已完成工作，应用也可能已执行模型返回的工具操作。重新发送代理任务前，核对应用状态与可见的请求记录。
未完整接收的输出应保持“不完整”状态，不能把第二次完整答案直接拼到第一次残缺答案后。类似编码场景可参考 Codex 流中断与检查点。
提交支持记录时附上 UTC 时间、模型、脱敏请求 ID、客户端版本、流式设置、时限、尝试次数及小请求结果。需要进一步核对路由和扣费时，使用API 服务商验证清单。换服务商后成功，也不能单独证明之前故障的责任归属。
常见问题
- 流式请求返回 HTTP 200 就算完成了吗？
- 不算。响应头成功返回后，流仍可能中断。还要检查协议结束状态和应用实际结果。
- 把超时时间调大一定能解决吗？
- 不能。它可能帮助正常但耗时较长的请求，却不能修复连接问题、明确的 API 错误或客户端故障。
- 超时请求一定不收费吗？
- 不能这样推断。客户端没有收到结果，不代表上游没有执行；需要核对用量和扣费记录。
