快速判断：按后缀对号入座

在动手排查前，先依据报错冒号后的完整后缀确定方向，不同后缀对应的环节与优先操作如下：

  • 后缀为10061且目标为127.0.0.1：指向本地桥接未监听，优先检查配置与端口监听。
  • 后缀为error sending request、timeout、reset或TLS：属于链路中途断开，优先做两条路径对照。
  • 后缀为An error occurred while processing your request或response failed：服务端通用错误，保留request ID并查看状态页。
  • 后缀为error decoding response body：响应体解码失败，转入decoding专项排查。
  • 仅有裸报错、无更多后缀：可能与会话或入口差异有关，做会话与入口对照。

对照上表即可初步判断报错落在哪一类，再按下文四类拆解逐项操作。

后缀分类：四类形态与两条边界

冒号后的内容是分类依据，常见形态可归为四类：

  • 连接拒绝类（os error 10061）：请求未到达远端，需确认目标是本地还是外部。
  • 发送失败类（error sending request、timeout、connection reset、TLS）：请求在中途被断开。
  • 服务端通用类（An error occurred while processing your request、response failed event received）：客户端无可用信息，应保留request ID。
  • 解码类（error decoding response body）：响应体中途损坏。

同时有两条边界需要注意：官方配置参考中的stream_idle_timeout_ms与stream_max_retries等参数，其含义仅限于自建provider场景；同一状态码不可并案处理，同为10061，指向本地与指向外部属于不同环节。

分场景排查的6个操作

每一步均给出适用条件、判定标准与后续去向；恢复一次并不等于确定根因。

步骤一：保住现场，核对已执行操作

适用于所有入口，属编辑建议级。操作上保留完整错误正文、时间、模型、版本与请求ID，查看文件差异与已完成操作，未完成部分给出续接指令，并用只读请求验证。判定标准是请求完整回答且无重复写入等副作用才算恢复，横幅消失不算数。需注意流断开不代表本地工具停止，before completion也不代表已收到正文。完成后进入后缀分流，不要重跑有副作用的任务。

步骤二：新会话做对照

适用于旧会话失败的情况，属临时恢复级。保持账号、模型、网络一致，新建空会话发送只读请求；可用时带任务摘要继续，勿复制大上下文。判定标准为新会话连续完成请求，并记录旧会话是否仍失败。

步骤三：跨入口对照桌面端、CLI与IDE

适用于某入口反复重连的情况，多人有效但根因未明。在相同设备、网络、账号下发送同一条只读请求，记录版本与结果。判定时只需区分单入口或多入口失败即可，这属于诊断而非修复。分支处理上，服务端通用类（response failed）应保留嵌套error与request ID，查看状态页择时重试；decoding类转入decoding细分排查专文。

步骤四：10061指向127.0.0.1时查桥接监听与配置残留

适用于完整错误含连接拒绝且配置指向本地地址的情况，单人有效级。操作上查看生效的用户配置、选中profile与环境变量的base URL，勿只看项目文件；确认地址是否为自己预期的桥接并检查端口监听；确需桥接时用原有可信方式恢复服务。判定标准为端口监听且Codex经该路径完成实际请求才算恢复；不再需要本地覆盖时，备份后一次只还原一项可疑配置并重启验证。需注意恢复反馈来自单个桥接案例，不证明官方服务或海外出口有问题；勿复制远程脚本，企业网关不可擅删。

步骤五：固定变量做两条路径对照

适用于后缀为timeout、reset、TLS或发送失败的情况，多人有效但根因未明。保持设备、账号、模型、客户端与请求不变，对照两条可用路径；已配置网络转发的，确认Codex进程流量真走预期路径；每条路径有限重复，差异可重复才查DNS与TLS设置。判定标准是得到可重复的路径差异或一致失败，而非换网可修复。两条都失败时应停止换节点，转查客户端、账号、服务端或网关。

步骤六：仅自建provider核对流式兼容与超时重试

仅适用于自建网关或第三方桥接，属官方文档级。核对网关是否支持Responses、SSE或WebSocket路径；比对断开时间是否与自有网关超时一致；按管理员策略调整stream_idle_timeout_ms与stream_max_retries。判定标准为请求持续完成、两端日志无对应断开才算通过。需注意参数定义不等于调大即修复，增大重试不是根治，也不自动适用于内置ChatGPT连接。

另有低优先级案例：单人重启路由器后约10个任务正常，根因未明。

链路对照：出口如何影响流式长连接

Codex的流式响应与WebSocket长连接一次可持续数分钟，任何一环中断都会落到这句报错；网页能打开只代表短连接可用，证明不了长流能走完。共享出口存在三重威胁：出口信誉低被额外校验；时段拥塞导致传输超时；会话中途出口跳变，切节点等于主动重置连接。

出口对照应看三项硬指标：

  • 固定归属：全程使用同一出口。
  • 底层运营商资源：骨干级线路保障跨网质量。
  • 可对照验证：小批量验收后再放量。

只有当路径差异可重复时，网络才进入处置清单。如需了解海外AI网络方案，可访问 https://www.ipxss.com/ 。

常见问题

  • 是账号或IP被封了吗：不能仅凭这句判断。同一报错跨账号、会话、入口、网络组合多样，有案例同网络切账号失败率差约7倍，应按后缀分流逐个排除。
  • 断流后已生成的内容会丢吗：不一定。before completion不代表已收到正文，部分输出可能还在缓存；续接前核对已执行操作，进展固化到文件更稳。
  • 新建会话能彻底解决吗：不能指望。有反馈称新会话只暂时有效后复发，也有案例与最简单请求同样失败，对照只缩范围，不等于根治。
  • os error 10061指向127.0.0.1需要重装Codex吗：不需要。多指向本地桥接或代理端口未监听，或配置残留无用的base URL覆盖。查配置、确认端口监听，一次还原一项。

总结

Codex stream disconnected before completion不是单一故障：后缀指向本地桥接、链路、服务端或会话状态，按后缀分流才能收敛。各恢复手段均有条件与反例，换会话、换路径只提供线索。当断流与路径可重复相关时，应对照固定归属通道；注册IPxSS账号，按小批量验收验证链路。