Codex 重连5次怎么办？原因与 3 种修复方法，附排查顺序

最后更新：2026 年 9 月 5 日 · 作者：AI345 编辑部 · 约 7 分钟读完

一分钟答案：Codex 每次对话前显示 Reconnecting 1/5 到 5/5，通常是 WebSocket 连接在代理环境下握手失败，重试 5 次后才回退到普通 HTTPS。修复顺序：先在 ~/.codex/.env 里配置 HTTP_PROXY/HTTPS_PROXY 代理变量；不行再在 config.toml 里禁用 WebSocket 强制走 HTTPS；最后考虑代理软件开 TUN 模式。多数人改完第一个文件、完整重启 Codex 后就恢复了。

用 Codex 桌面版或 CLI 时，很多人都被这个画面卡住过：每次发消息，屏幕上先滚过 Reconnecting... 1/5、2/5、3/5、4/5、5/5，等几十秒才开始正常回答。换节点、重启软件、重装 Codex 都试过，第二天照样重连。这篇文章把重连 5 次的机制讲清楚，再给出按优先级排好的 3 种修复方法，照着顺序排查，基本都能解决。

Codex 重连5次是什么现象

典型的表现是这样的：

• 每次开启新会话或发送消息前，固定出现 Reconnecting... 1/5 到 5/5 的提示；
• 等 5 次重连跑完之后，Codex 往往又能正常回答；
• 浏览器访问 ChatGPT 网页版一切正常，只有 Codex 出现这个问题。

先说结论：这种现象通常不代表模型不可用、账号异常或 Codex 崩了，而是实时连接在建立阶段出了问题。Codex 支持 Responses API 的 WebSocket 传输，当前开源实现默认最多重连 5 次，单次连接超时 15 秒；5 次全部失败后，才会回退到普通 HTTPS 请求，之后一切照常。这也是为什么"重连 5 次但最终能回答"是这个问题的经典形态。

在 Codex 官方 GitHub 仓库里，标题或内容包含 reconnecting 的 issue 超过 500 条（其中 390 多条仍处于开启状态），WebSocket 连接性是当前最常见的反馈类型之一，所以遇到这个问题的不止你一个。

为什么会重连5次：WebSocket 重试机制

理解机制，排查才有方向。Codex 新版本默认优先用 WebSocket（WSS）传输 Responses API 的响应流，流程如下图：

1. Codex 发起 WSS 连接，15 秒内握手失败（超时或被拦截）；
2. 自动重试，最多 5 次，界面上显示 Reconnecting 1/5 至 5/5；
3. 5 次全部失败后，回退为普通 HTTPS 请求，对话继续。

问题就出在第 1 步。两个最常见的"握手失败"原因：

• 代理没有接管 WebSocket 流量。Codex 桌面应用不像浏览器那样自动走系统代理，它需要显式读到 HTTP_PROXY、HTTPS_PROXY 这类环境变量才会走代理；这些变量没配置，或者代理节点不支持 WebSocket 转发，WSS 握手就会一直失败。
• 公司网络、防火墙或安全软件拦截 WSS。浏览器能上网不代表 WSS 能通，不少企业网络会拦截非标准端口的 WebSocket 握手。

判断方法很简单：HTTPS 能正常用（网页、ChatGPT 网页版都正常），但每次对话前固定重连多次，就优先查 WebSocket 和代理配置，而不是怀疑账号或模型速度。

方法一：给 Codex 配置代理环境变量（推荐先试）

这是覆盖面最广的修法，保留 WebSocket 能力，让 HTTPS 和 WSS 流量都正确走代理。

第 1 步：确认代理端口。 打开代理软件的设置页，找到本机 HTTP 代理监听端口。Clash 系列常见 7890，v2rayN 常见 10808，以你软件里实际显示的为准；注意填 HTTP 代理端口，不要未加确认就填 SOCKS 端口。

第 2 步：创建 .env 文件。 路径：

• macOS / Linux：~/.codex/.env
• Windows：C:\Users\你的用户名\.codex\.env

Windows 用户注意确认文件名是 .env，而不是被隐藏扩展名后的 .env.txt。

第 3 步：写入代理配置（端口换成你自己的）：

HTTP_PROXY="http://127.0.0.1:7890"
HTTPS_PROXY="http://127.0.0.1:7890"
NO_PROXY="localhost,127.0.0.1,::1"

第 4 步：完整重启 Codex。 关闭整个 Codex 桌面应用或 CLI 会话再打开，已有进程不会自动重读 .env。重新发一条消息，观察重连是否消失。

仍然重连时逐项检查：代理软件是否在运行；.env 是否放对了目录；Windows 文件名是否真的是 .env；端口是否和软件设置一致；当前节点是否允许 WebSocket；公司网络是否拦截 WSS 握手。

一个实用技巧：你也可以直接把这段需求发给 Codex 本身，让它帮你定位端口并写好 .env 文件，改完手动重启即可。

方法二：禁用 WebSocket，强制走 HTTPS

如果你的代理环境实在无法稳定支持 WebSocket，或者只想尽快消除等待，可以让 Codex 跳过 WebSocket，直接用 HTTPS。

打开配置文件（macOS / Linux 在 ~/.codex/config.toml，Windows 在 C:\Users\你的用户名\.codex\config.toml），在顶层加上：

model_provider = "openai_http"

再在文件里添加一个仅走 HTTPS 的模型提供方：

[model_providers.openai_http]
name = "OpenAI"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

supports_websockets = false 会禁止这个 provider 使用 WebSocket 传输，Codex 从此直接走 HTTPS，不再有 5 次重连的等待。保存后完整重启 Codex 生效。

两点注意：改之前备份一下 config.toml，避免覆盖已有的模型和 MCP 配置；部分客户端版本按 provider 分组展示历史会话，切换后暂时看不到旧会话不代表被删了，恢复原配置即可。官方配置项的完整说明见 Codex 官方配置文档。

方法三：代理软件开启 TUN 模式

如果前两种方法都无效，可以把代理切到 TUN 模式。TUN 通过虚拟网卡在系统网络层接管流量，不依赖单个应用是否正确读取代理变量，对 CLI 和桌面应用覆盖更全面。

开启步骤：打开代理客户端（Clash Verge、Mihomo Party 等）→ 在"设置 / 网络 / TUN Mode"里打开开关 → 按提示安装服务模式或虚拟网卡（Windows 需要管理员权限）→ 重启终端和 Codex 验证。

代价是影响面大：TUN 会接管全系统流量，可能改变局域网访问、本地开发服务、虚拟机的网络行为。开启后建议检查内网和本地服务是否正常，并按需配置绕过规则。所以 TUN 排在第三位，作系统级兜底，而不是首选。

三种方法对比：怎么选

按"方法一 → 方法二 → 方法三"的顺序试，每改一步完整重启一次 Codex 再验证，避免多变量同时改动分不清哪个生效。

修完还是重连？4 个容易被忽略的原因

1. OpenAI 服务端故障。 重连偶尔是服务端问题，先看 OpenAI 官方状态页有没有故障公告，再等一会儿重试，别急着改配置。
2. 上下文过长导致偶发重连。 社区里有用户反馈：同一个会话历史内容积累太多之后开始频繁重连，新开一个会话就恢复正常。如果你的重连是"老会话重、新会话轻"，先试试新开会话，并考虑压缩或清理长对话。
3. VPN 断连后的"连接黑洞"。 官方仓库有 issue 记录：VPN 断开后 WebSocket 进入假死状态，CLI 长时间停在 Thinking。这类情况重连代理或重启 Codex 进程即可恢复，属于连接状态残留，不是配置错误。
4. 间歇性网络抖动。 如果重连只是偶尔出现、不影响最终回答，多数是节点抖动，换一个更稳定的节点观察即可，不必大动干戈。

另外提醒一句：如果 Codex 报错内容明确是认证失败、额度不足或命令不存在，那不是本文讨论的重连问题。额度相关可以看我们的 Codex 额度与用量查询指南，配置相关可以看 OpenAI Codex 完整使用指南。

总结

Codex 重连 5 次的本质是：WebSocket 在代理或防火墙环境下握手失败，客户端重试 5 次（每次 15 秒）后才回退 HTTPS。它不是账号问题，也基本不用重装软件。记住这个处理顺序就够了：先配 .env 代理变量（方法一），不行就禁用 WebSocket 强制 HTTPS（方法二），最后开 TUN 模式兜底（方法三）；修完仍然偶发重连，再查服务状态、上下文长度和 VPN 断连残留。

改完之后，每次对话省下的几十秒等待，就是这篇文章最实际的收益。关于 Codex 的更多使用技巧，欢迎继续阅读 AI 指南栏目的其他 Codex 教程。

参考资料

• openai/codex 官方开源仓库
• Codex 官方配置参考文档
• Codex WebSocket 断连相关 Issue（GitHub）