Codex 每次对话都 Reconnecting？我最后发现不是登录问题

最近用 Codex 的时候，遇到一个很烦的问题：

每次新开对话，或者发出一条消息后，它都会先卡在：

Reconnecting... 1/5

Reconnecting... 2/5

...

Reconnecting... 5/5

等它重连完，才开始正常回答。

一开始我以为是登录态失效、网络不稳定，或者 Codex 服务端偶发抽风。但排查后发现，真正的问题其实在传输方式上。

问题根因

Codex 默认会优先尝试使用 WebSocket 连接。

如果当前网络环境、代理工具或系统代理没有让 Codex 进程正确走代理，WebSocket 连接就可能超时。

于是流程变成这样：

先尝试 WebSocket↓WebSocket 连接失败↓开始 Reconnecting，最多重试 5 次↓最后 fallback 到 HTTP/SSE↓HTTP/SSE 正常工作，开始回答

所以它不是完全连不上，而是“先走了一条不通的路，失败几次后才换到能用的路”。

这也是为什么它最后能回答，但每次开头都要等一段时间。

常见绕法：禁用 WebSocket

网上有一种方案，是在 Codex 配置里自定义一个 HTTP-only provider，例如：

model_provider = "openai_http"[model_providers.openai_http]supports_websockets = false

这个方案确实可以绕过 WebSocket，让 Codex 直接走 HTTP。

但它有一个潜在问题：改了 model_provider 之后，旧会话可能会因为 provider 不同，在界面里“看起来不见了”。

如果你只是想解决重连，不一定要走这条路。

更稳的方案：不改 provider，只补代理环境

我最后采用的是另一个方案：

不修改 model_provider，只给 Codex 明确声明代理环境变量。

也就是在 Codex 的环境配置文件里写入类似下面的内容：

http_proxy=http://127.0.0.1:你的代理端口https_proxy=http://127.0.0.1:你的代理端口all_proxy=http://127.0.0.1:你的代理端口HTTP_PROXY=http://127.0.0.1:你的代理端口HTTPS_PROXY=http://127.0.0.1:你的代理端口ALL_PROXY=http://127.0.0.1:你的代理端口ws_proxy=http://127.0.0.1:你的代理端口wss_proxy=http://127.0.0.1:你的代理端口WS_PROXY=http://127.0.0.1:你的代理端口WSS_PROXY=http://127.0.0.1:你的代理端口no_proxy=localhost,127.0.0.1,::1NO_PROXY=localhost,127.0.0.1,::1

这里的核心不是“强行禁用 WebSocket”，而是让 Codex 的 HTTP、HTTPS、WebSocket 请求都能明确走本机代理。

配置完后，重启 Codex，再试一次新对话。

如果问题确实是 Codex 进程没有正确继承代理环境，重连等待会明显改善，甚至直接消失。

为什么这个方案更适合我

因为它没有改 Codex 的 provider。

也就是说：

不影响旧会话展示

不改变模型提供方配置

不绕开 Codex 默认传输逻辑

只是补齐进程级代理环境

这比直接切到 HTTP-only provider 更温和。

如果后续网络环境正常支持 WebSocket，Codex 仍然可以按默认方式工作。

如果这样还不行

如果加了代理环境变量后，还是反复 Reconnecting...，那就要继续检查代理工具本身：

代理端口是否正确

当前代理是否支持 WebSocket

是否需要开启 TUN 模式

Codex 是否真的读取到了环境配置

系统代理和终端代理是否不一致

是否有安全软件或网络策略拦截 WebSocket

有些情况下，HTTP 请求能走通，但 WebSocket 不一定能走通。

这也是这个问题容易误判的地方。

欢迎大家关注我——普通人的 AI 副业，也可以加我微信，我们一起讨论。