Codex 502 与上下文压缩失败排查

先保存这些信息

• 错误发生时间，精确到分钟并注明时区。
• 响应中的 Request ID 或控制台错误记录 ID。
• 客户端名称和版本。
• 模型、思考等级、是否流式请求。
• 新对话是否正常，只有原对话是否持续失败。

第一步：建立最小复现

使用同一把 Key、同一模型和同一客户端，新建空白对话，只发送“回复 OK”。

• 最小请求正常、原对话持续失败：优先检查上下文长度、压缩或某条历史消息。
• 同一客户端所有请求都失败：检查客户端配置、Key、网络或平台状态。
• 多个客户端同时失败：更可能是平台网关、账号容量或上游服务异常。
• 只有一个模型失败：更可能是该模型容量、路由或请求参数问题。

也可以使用 curl 最小请求绕开客户端进行对照测试。

第二步：判断是否与长上下文有关

Codex 在对话变长后可能触发本地或服务端压缩。压缩请求通常比普通问答更长，也更容易碰到超时、容量不足或连接中断。

1. 复制必要结论到新会话，不要复制完整历史。
2. 暂时去掉大型日志、二进制内容和重复粘贴的代码。
3. 把思考等级从 max 或 xhigh 降到 high 做一次对照。
4. 关闭不必要的工具调用后复测。
5. 更新客户端并重新启动，排除旧模型元数据和旧连接状态。

新会话正常并不代表原会话可以自动修复。持续失败的旧会话应保留错误信息后停止高频重试。

第三步：区分容量与网关错误

正确的重试方式

短暂网络错误可以有限重试，但不要并发放大故障。

1. 第一次失败后等待约 2 秒。
2. 第二次失败后等待约 5 秒，并加入少量随机延迟。
3. 仍失败就停止自动重试，记录 Request ID 并换最小请求诊断。

对于非幂等工具操作，自动重试前必须确认前一次操作是否已经执行，避免重复修改或重复提交。

怎样提交有效反馈

建议使用下面的格式联系支持：

时间：2026-07-24 18:20 CST
Request ID：req_xxx
客户端：Codex CLI + 版本号
模型：gpt-5.6-sol
思考等级：xhigh
请求方式：stream=true
最小请求：正常 / 同样失败
现象：新对话正常，原长对话在压缩时持续 502

这些信息可以将排查范围快速缩小到客户端、具体请求、平台路由或上游响应。