一文详解Codex提示Reconnecting waiting for network的原因与解决方法
AI砖家
本文讨论 Codex（CLI / 桌面端 / IDE 扩展）在复杂网络环境—— 企业内网、公司防火墙、安全网关、统一代理 —— 下出现Reconnecting... waiting for network提示的原因与排查方法。核心是一个典型的长连接兼容性问题，不涉及任何特定网络环境的绕过。
0. 先说结论
Reconnecting... waiting for network（有时演进为 Reconnecting 1/5 … 5/5）不是模型在 “思考”，而是 Codex 与服务端之间的传输连接没能建立或被中断，正在按指数退避策略自动重连。
在企业办公网络中，最常见的原因有两个：
- 防火墙 / 安全网关 / 代理服务器能转发普通 HTTPS 请求，却没有正确放行或维持 WebSocket（
wss://）长连接； - 应用进程没有继承系统或企业统一代理配置，导致它按 “直连” 方式发起连接而失败。
理解了 Codex 的传输与重连机制，这两类问题都有标准、正当的解决方式（联系网络管理员放行、让应用读取系统代理、或改用 HTTP 流式传输）。
1. 这句话到底在说什么
完整提示通常是：
Reconnecting... waiting for network Reconnecting... (1/5) Reconnecting... (2/5) Reconnecting... (3/5) Reconnecting... (4/5) Reconnecting... (5/5)
有时卡上几十秒后，答案又正常返回了。这个 “等一会儿能用” 的特征，容易被误判成模型响应慢。
实际上，这是 Codex 的传输层自愈（transport-level self-healing）提示：它明确告诉你 “连接中断，正在重建”，而不是程序死机。把重连进度暴露出来，本身是高可用设计的一部分，避免用户误以为卡死而手动结束进程。
2. 原理：建连、重连与降级
2.1 两种传输通道：WebSocket 与 HTTPS 流式
Codex 调用 Responses API 时，结果可通过两种通道返回：
| 传输方式 | 形态 | 特点 | 对中间网络设备的要求 |
|---|---|---|---|
WebSocket（wss://） | 持久的双向长连接 | 延迟低，适合长时间、持续交互的 Agent 工作流，默认优先使用 | 高：网关 / 防火墙需能稳定维持长连接 |
| HTTPS 流式 | 普通 HTTP 请求 + 流式响应 | 通用性最好，几乎所有网络环境都能通过 | 低：与普通网页请求一致 |
关键在于：WebSocket 对防火墙、安全网关、反向代理、流量审计设备的要求更高。这些设备通常默认放行普通 HTTPS，却可能没有为 wss:// 长连接做相应配置（连接空闲超时过短、未放行升级握手、不支持连接保活等），从而出现 “网页能开、普通接口能调，唯独长连接一直重连” 的现象。
2.2 连接失败 → 指数退避重连
在 Codex 的错误分类中，ConnectionFailed、Timeout、Stream、Io 等属于可重试错误（retryable）。连接失败会被单独归为一档：
- 按 ** 指数退避（exponential backoff）** 逐次拉长等待间隔，等待上限由最大重连延迟参数封顶；
- 每次尝试都通过
Reconnecting... (n/max)暴露进度。
所以 1/5 → 5/5 本质是反复尝试重建长连接，每次都要先等待超时，整体时间被拉长。
2.3 重试耗尽 → 传输降级（WS → HTTPS）
当普通重试超过上限仍未成功，Codex 会触发传输降级：从 WebSocket 回退（fallback）到 HTTPS 流式传输，降级成功后继续执行。这解释了 “重连几次后又能正常回答” 的现象：
发起对话
↓
优先尝试建立 WebSocket
↓
握手失败，指数退避重试 1/5 … 5/5
↓
重试耗尽，回退到 HTTPS 流式传输
↓
回答正常返回 ✅
模型本身可能始终正常，失败的只是它优先选择的传输通道。
3. 常见原因分类
| # | 原因 | 典型特征 |
|---|---|---|
| ① | 防火墙 / 网关未放行 WebSocket | 普通 HTTPS 请求正常，长连接建立失败；切换网络（如手机热点）后现象变化 |
| ② | 应用未继承企业 / 系统代理配置 | 浏览器正常，独立进程形式的客户端却连接超时 |
| ③ | 认证状态失效（MFA / 登录态） | 请求已到达服务端，却被判为未授权而断开 |
| ④ | 本地网络或服务端波动 | DNS 异常、系统时间错误、服务端临时不可用 |
4. 解决方案
用户级配置文件位置：
- Windows：
C:\Users\<用户名>\.codex\config.toml - macOS / Linux：
~/.codex/config.toml
修改后需完全退出并重启客户端才会生效。
方案一：先做基础网络连通性排查
在调整配置前，先排除最基础的问题：
- 确认当前网络稳定，必要时切换网络（如有线 / 无线 / 手机热点）对比现象是否变化；
- 检查 DNS 是否能正常解析、系统时间是否准确（时间错误会导致 TLS 握手失败）；
- 确认所用服务本身状态正常，排除服务端临时故障。
方案二：让应用遵守系统 / 企业代理
在使用统一代理的企业网络中，浏览器通常已通过自动配置脚本（PAC）或系统代理正常联网，但独立进程形式的客户端可能没有读取该配置，从而按直连方式失败。较新版本的 Codex 提供了开关，使其直接读取操作系统的代理设置。
在 config.toml 中加入（已有 [features] 段则只添加下面一行，段落头在整个文件中只能出现一次）：
[features] respect_system_proxy = true
说明：
true为小写布尔值，不加引号；- 该选项用于让应用遵循系统已有的代理配置，适用于企业统一代理环境；旧版本若没有此项，请先升级客户端；
- 保存后完全退出并重启。
方案三：网络设备不支持 WebSocket 时，改用 HTTP 流式传输
如果确认普通 HTTPS 可通、但 WebSocket 始终无法建立（常见于策略较严格的企业网络），可以定义一个不使用 WebSocket 的提供方，让客户端直接走 HTTP 流式通道，省去全部重连等待。
在 config.toml 中加入：
model_provider = "openai_http" [model_providers.openai_http] name = "OpenAI HTTP" wire_api = "responses" requires_openai_auth = true supports_websockets = false
| 配置项 | 作用 |
|---|---|
model_provider = "openai_http" | 顶层配置，选择下面定义的提供方 |
name | 显示名称 |
wire_api = "responses" | 继续使用 Responses API |
requires_openai_auth = true | 沿用原有认证方式 |
supports_websockets = false | 核心：声明不使用 WebSocket，改走 HTTP 流式 |
注意：
model_provider必须是顶层键，不要误写入[model_providers.openai_http]表；若已存在该键则修改原值，不要重复定义；- 需修改用户级配置文件，项目目录下的配置无法覆盖
model_provider与model_providers； - 这是用通用性换取稳定性的兼容性方案，网络环境支持 WebSocket 后可随时还原。
修改前建议备份原文件：
cp ~/.codex/config.toml ~/.codex/config.toml.bak
方案四：联系网络管理员放行长连接
在企业网络中，WebSocket 无法使用的根本解决方式是由网络 / 运维团队在防火墙、安全网关或反向代理上为相应域名放行 wss:// 连接，并调大空闲连接超时、关闭对长连接的中途拦截。这属于正常的企业网络策略调整，建议携带明确的报错信息和目标域名提工单处理。
方案五：认证状态失效时重新登录
若请求已到达服务端却被判为未授权而断开，常见于账号启用了 ** 多因素认证（MFA）** 后，本地旧的登录会话失效，而客户端未重新完成验证。
处理方式：
- 在浏览器中正常登录对应服务，进入 Settings → Security，确认多因素认证状态；
- 完全退出客户端（结束后台进程，而不仅是关闭窗口）；
- 重新启动客户端并重新登录，使其建立新的有效会话。
5. 排查路径图
6. 如何确认已修复
重启后新建对话发送一条简单消息，观察：
- 不再依次出现
Reconnecting (1/5)到(5/5)； - 首个响应更快出现，直接进入正常处理状态；
- 连续新建 3 个对话均稳定（避免把偶然恢复误判为配置生效）；
- 工具调用与长回答的流式输出正常。
仍异常时按序自查：配置中是否存在重复的 model_provider 或重复的 [features] 段；supports_websockets = false 是否位于正确的表内；修改的是否为用户级配置；当前网络是否对长连接有限制。
7. 常见误区
“重连是模型在思考。” 思考阶段与网络重连是两种不同状态，后者明确属于连接层。
“浏览器正常，客户端就一定正常。” 独立进程不一定继承系统 / 浏览器代理，且 WebSocket 与普通 HTTPS 的网络设备要求不同。
“等它重连完能用就无需处理。” 每次请求都先经历多轮超时等待，明显影响效率，应从网络策略或传输方式上根治。
8. 小结
Reconnecting... waiting for network 是传输层自愈提示：连接失败 → 指数退避重连 → 重试耗尽后从 WebSocket 降级到 HTTPS；
企业网络中最常见的根因是网关未放行长连接与客户端未继承代理配置；
正当的解决路径：基础连通性排查 → respect_system_proxy 读取系统代理 → 必要时 supports_websockets = false 改用 HTTP 流式 → 联系管理员放行 wss → 认证失效则重新登录；
修改配置后务必完全重启，并连续测试 3 次确认。
到此这篇关于一文详解Codex提示Reconnecting waiting for network的原因与解决方法的文章就介绍到这了,更多相关Codex提示Reconnecting waiting for network内容请搜索脚本之家以前的文章或继续浏览下面的相关文章，希望大家以后多多支持脚本之家！