ChatGPT API 请求超时，不一定意味着 API 服务不可用。请求可能卡在 DNS 解析、TCP/TLS 建连、代理转发、服务端处理或响应读取中的任一环节；也可能是客户端超时时间过短，或者重试策略放大了问题。排查时应先记录请求发往哪个端点、何时开始失败、客户端收到什么错误，再逐层验证，不要一上来就反复更换密钥或线路。
本文面向开发者整理一套可复现的检查流程：先确认端点与认证配置，再区分连接超时和读取超时，之后检查 DNS、代理出口、重试与用量限制。服务状态、接口行为和政策都可能变化，具体参数及可用性请以 API 官方文档和状态页面为准。
先识别故障：超时发生在哪个阶段
“请求超时”是客户端对等待时间的概括，并非单一错误。客户端可能尚未连上目标服务器就超时，也可能已建立连接、发送请求后迟迟没有收到完整响应。先查看异常类型、HTTP 状态码和请求耗时阶段，有助于决定下一步检查网络还是应用配置。
| 表现 | 可能发生的阶段 | 优先检查 |
|---|---|---|
| 连接超时 | DNS、路由、TCP 建连或代理连接 | 域名解析、出口网络、防火墙、代理配置 |
| 读取超时 | 请求已发出，等待响应或响应数据 | 服务状态、请求负载、客户端读取超时设置 |
| 401 或 403 | 服务端已返回认证或权限响应 | 密钥、项目权限、组织或接口访问要求 |
| 429 | 请求受到速率或用量限制 | 响应头、配额、并发量与调用频率 |
| 5xx 或网关错误 | 服务端或请求路径上的网关返回错误 | 官方状态、请求时间、重试与请求标识 |
有些 SDK 会把底层连接错误统一包装成超时异常，所以应同时查看异常链、HTTP 响应和客户端日志。若已经收到明确的 401、403 或 429 响应，就不应把问题当成纯网络超时处理；服务端能够返回状态码，说明请求至少到达了某个响应环节。反过来，没有状态码也不能单凭这一点断定是线路故障。
- ✅ 记录请求开始时间、端点、模型或操作类型、错误类别及耗时阶段。
- ✅ 对照同一时间的官方服务状态，确认是否存在已知事件。
- ❌ 不要在日志、工单或截图里暴露 API 密钥、授权头和完整敏感请求内容。
核对端点、密钥与请求配置
先检查请求地址是否是当前项目和所用 SDK 支持的 API 端点。不同接口的路径、请求体和返回格式可能不同；例如 Responses API 与 Chat Completions API 不能只靠替换路径就假定参数完全兼容。确认代码没有把网页产品地址、代理服务地址或旧版接口路径误当成 API 端点，也要留意环境变量中是否残留了开发环境的自定义 base URL。
密钥配置应从安全的环境变量或密钥管理工具读取。核对运行进程实际加载的变量名称和部署环境，避免本地终端中有值、容器或服务进程里却为空。若刚轮换过密钥，还要确认启动中的旧进程是否仍在使用旧值。认证失败通常会有明确的服务端响应；此时重试同一个请求并不会修复凭据问题。
- 打印脱敏后的目标主机、接口路径和 SDK 版本，不打印密钥本身。
- 核对请求方法、必要请求头及请求体字段是否符合当前接口文档。
- 确认项目、组织或其他访问范围配置与密钥所属环境一致。
- 用最小化请求复现问题，再逐项恢复模型参数、较大的输入和业务逻辑。
最小化请求的价值在于减少变量：如果简单请求能完成，而加入较大的上下文、工具调用或复杂输出格式后才变慢，就应进一步比较输入大小、服务端处理时间和响应体读取方式。不要在排查中将生产密钥复制到公共在线调试工具；必要时在受控环境中创建权限合适的测试凭据，并按组织的密钥管理流程处理。
区分连接、读取与整体超时
HTTP 客户端通常将超时拆成连接超时、读取超时，部分实现还提供写入超时和连接池等待超时。连接超时限制客户端建立到目标的连接所等待的时间；读取超时限制等待响应数据的时间；连接池超时则可能表示没有可用连接。把所有值都设置成一个很短的整体期限，容易让正常的网络波动或较长的模型响应被误判为故障。
应按照 SDK 和 HTTP 库的文档设置明确的超时边界，并结合应用的交互要求决定等待策略。同步接口若要求尽快返回，整体等待时间可以更保守；后台批处理通常可以容忍更长等待，但也应设置上限、记录耗时并允许任务恢复。流式响应还要检查客户端是否在等待首段数据时使用了合适的读取超时，不能把“首字节未到”和“后续数据间隔较长”混为一谈。
比较时要保持测试条件一致：同一个端点、同一类请求、相同网络环境，只改一个超时参数。若延长读取时间后请求最终成功，说明原有等待上限可能不适合该任务，但这并不证明网络一定稳定；若连接阶段仍然失败，单纯延长响应读取时间通常无济于事。
检查 DNS、代理与出口线路
确认客户端进程实际使用的 DNS 和代理设置。命令行工具、浏览器、容器和后台服务可能读取不同的代理变量或系统设置；浏览器能访问某网站，并不能证明运行 API 调用的进程也走同一条路径。检查环境中的 HTTP、HTTPS 代理变量、SDK 的代理参数、容器网络设置，以及是否有其他网络软件覆盖系统路由。
DNS 排查应关注目标主机能否解析、解析结果是否随网络环境异常变化，以及应用是否使用了预期的解析器。可以在运行 API 程序的同一台主机或容器内进行解析与连通性检查，并比较切换网络前后的结果。解析成功只说明域名得到地址，不代表 TLS 握手、代理转发或 API 请求已成功；也不要把某一次解析结果写死到生产配置里，除非官方文档明确要求。
若使用代理，逐项确认代理地址、端口、认证方式和 TLS 转发是否匹配。不要同时启用多个代理工具或在应用层、系统层重复代理，除非明确知道连接链路；代理之间的循环转发、错误的环境变量和证书检查配置，都可能造成建连失败。排查证书问题时应检查系统时间、证书链和企业网络策略，不应通过关闭 TLS 验证来绕过告警。
对于需要跨境访问 API 的开发环境，可在确认目标服务、当地法规和服务条款的前提下，使用合规且稳定的网络出口。评估出国加速器等网络接入方案时，重点看它是否与开发环境的代理方式兼容、是否能保持连接路径一致，以及能否提供必要的故障排查信息；不要把出口切换等同于 API 服务可用性保证。
设计重试、退避与并发控制
重试适用于短暂网络故障或可恢复的服务端错误，不适用于所有响应。对于连接中断、部分网关错误等情况，可以按 SDK 文档配置有限次数的重试，并采用逐步增加等待时间的退避方式；在多个任务同时重试时加入随机抖动，减少它们在同一时刻再次涌向服务端的情况。具体哪些错误可重试，应以官方接口说明和 SDK 的错误分类为准。
遇到 429 时，先检查响应中的限制信息和用量状态，再调整调用频率、并发数或任务队列。盲目快速重试会制造更多请求，可能延长恢复时间。认证、权限或请求格式错误则应先修正配置，而不是重试。对于可能产生重复副作用的业务操作，还应使用应用层的幂等设计或请求去重机制，避免客户端不确定请求是否被处理时重复执行。
- 为每个任务设置有限重试次数和总等待上限，避免无限循环。
- 按错误类型决定是否重试，避免对认证错误和参数错误持续重发。
- 限制并发，观察队列长度、响应时间和服务端限流提示之间的关系。
- 记录每次尝试的时间、状态类别与请求标识，便于区分首次失败和重试结果。
还要把客户端重试与业务队列重试区分开。SDK 可能已经在内部重试，应用外层又重复提交，最终实际请求次数会高于代码表面看到的次数。排查时查阅所用 SDK 当前版本的默认行为，并在日志中标记尝试序号；如果无法确认默认重试是否开启，先在测试环境明确配置，再比较结果。
稳定出口 IP 与持续调用的关系
相对稳定的出口 IP 有助于让一段时间内的请求路径更一致，也便于网络白名单、企业防火墙规则、审计记录和故障对比。若出口频繁变化，某些依赖来源地址识别的系统可能需要额外核对配置；但是否支持 IP 白名单、允许哪些来源地址，以及凭据与地址如何关联，应以 API 提供方的当前文档为准。不要假定更换到固定出口就会自动提高接口配额或消除超时。
稳定出口也不能替代监控。建议为每次请求记录时间、接口类别、客户端版本、耗时阶段、错误类型、重试次数和服务端返回的请求标识；密钥、授权头、个人数据及完整提示内容应脱敏或避免采集。将失败时间与官方状态信息、部署变更和网络出口变更对照，可以区分服务端波动、程序更新和本地网络问题。
遇到持续故障时，整理一份可复现但不泄露凭据的报告：说明使用的 SDK 与版本、目标接口、发生时间范围、错误类别、是否收到 HTTP 状态、连接和读取超时配置，以及更换网络后是否仍可复现。不要提交完整密钥或未经清理的请求日志。官方状态与服务政策可能调整，最终判断以官方信息为准；若问题涉及账号权限或用量状态，也应通过正式支持渠道确认。