Codex 每次都重连5次——可能是 WebSocket 没走代理
每次打开 Codex，提交问题后都要先看一遍：
Reconnecting… 1/5Reconnecting… 2/5Reconnecting… 3/5Reconnecting… 4/5Reconnecting… 5/5等上一两分钟，它又突然恢复正常，开始回答问题。
这种情况通常不是模型响应慢，也不一定是账号或服务出了问题。更常见的原因是：普通 HTTP 请求可以正常通过代理，但 WebSocket 连接没有走通。
为什么失败几次后又能用了？
Codex 的实时通信可能使用 WebSocket。OpenAI 的 Responses API 本身也支持通过 WebSocket 建立长连接。OpenAI 官方文档
问题在于，一些代理软件只接管普通 HTTP/HTTPS 流量，没有正确处理 WSS，或者 Codex 没有读取到对应的代理配置。于是就出现了下面的过程：
尝试建立 WebSocket 连接 ↓代理没有正确转发，连接超时 ↓连续重试多次 ↓放弃 WebSocket，回退到普通 HTTP ↓HTTP 可以正常通过代理，Codex 恢复工作所以它并非完全无法连接，而是在 WebSocket 重试阶段白白等了一段时间。具体的重试次数和超时时间可能随 Codex 版本变化，但“反复 Reconnecting，最后又能使用”是比较典型的代理链路问题。
推荐解决办法：让 WebSocket 也走代理
如果不想关闭 WebSocket，可以在 Codex 的配置目录中创建 .env 文件，为它补上代理环境变量。
文件位置如下：
| 系统 | 文件路径 |
|---|---|
| macOS / Linux | ~/.codex/.env |
| Windows | C:\Users\你的用户名\.codex\.env |
Windows 用户需要特别注意：文件名必须是 .env，不能是 .env.txt。如果资源管理器隐藏了扩展名，看起来叫 .env 的文件，实际可能仍然带有 .txt 后缀。
在文件中填写：
HTTP_PROXY="http://127.0.0.1:你的代理端口"HTTPS_PROXY="http://127.0.0.1:你的代理端口"NO_PROXY="localhost,127.0.0.1,::1"例如代理软件显示的 HTTP 或混合端口是 7897，配置可以写成：
HTTP_PROXY="http://127.0.0.1:7897"HTTPS_PROXY="http://127.0.0.1:7897"NO_PROXY="localhost,127.0.0.1,::1"这里的 7897 只是示例，必须换成代理软件实际提供的端口。通常应填写 HTTP 端口或混合端口，不要直接照搬 SOCKS 端口。
保存文件后，彻底退出 Codex，再重新打开。仅关闭窗口有时不够，最好确认后台进程也已经结束。
怎么判断是否生效？
重新启动 Codex 后发送一条简单消息，观察连接过程：
-
如果不再出现连续五次
Reconnecting，说明代理配置已经生效。 -
如果仍然重复重连，先检查端口是否正确，以及
.env是否被保存成了.env.txt。 -
如果普通 HTTP 代理仍无法承载 WebSocket，可以尝试代理软件的“系统代理”“增强模式”或 TUN 模式。
-
公司网络、证书检查软件和防火墙也可能拦截 WSS，此时需要检查网络策略，而不只是更换端口。
其他问题
配置了.env之后，不挂代理似乎会导致回答变慢的问题
总结
Codex 反复显示 Reconnecting… 1/5，随后又能正常回答，通常意味着两条连接路径的表现不同：WebSocket 没有通过代理，普通 HTTP 却可以。
解决思路很直接：在 ~/.codex/.env 或 Windows 用户目录下的 .codex\.env 中设置 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY，让 WebSocket 握手也通过正确的代理链路。
配置成功后，Codex 就不必先重试几轮再回退到 HTTP，启动后的等待时间也会明显缩短。
支持与分享
如果这篇文章对你有帮助，欢迎分享给更多人或打赏支持！