Codex 每次启动都卡在 Reconnecting？可能是 WebSocket 没走代理
最近折腾 Codex 的时候，遇到一个很烦人的现象：
1 | Reconnecting... 1/5 |
最迷惑的是，它最后并不是完全不能用。
前面会卡住一会儿，反复重连。等你开始怀疑账号、模型、网络、客户端是不是哪里坏了，它又突然正常开始回答。
这种问题最难受的地方就在这里：不是彻底失败，而是每次都要先罚站一会儿。
现象
典型表现一般是：
- 打开 Codex 后，第一次提问或者等待模型响应时，会出现多次
Reconnecting... - 通常会重试 5 次
- 每次重试中间都会卡一段时间
- 重试结束后，Codex 又能继续工作
所以它很容易误导排查方向，让人以为是：
- 模型响应慢
- 账号异常
- OpenAI 服务不稳定
- Codex 客户端出问题
- 代理软件没开好
但很多时候，真正的问题可能是：WebSocket 没有正常走代理。
为什么会这样
Codex 默认会优先尝试使用 WebSocket，也就是 WSS 协议，和服务器建立实时连接。
如果 WebSocket 连接成功，体验会更实时。但在一些代理环境里，尤其是终端环境、Windows 代理、Clash、v2rayN 这类组合下，可能会出现一种情况：
HTTP / HTTPS 请求能正常走代理，但 WebSocket 不一定能正常走代理。
于是流程就变成了这样：
1 | 先尝试 WebSocket |
所以我们看到的现象就是：前面一直 Reconnecting，后面又恢复正常。
这不一定是账号突然好了，也不一定是模型突然变快了，而是 Codex 最后回退到了 HTTP。
方案一：禁用 WebSocket，强制走 HTTP
如果只是想快速解决这个问题，可以直接让 Codex 不再优先尝试 WebSocket。
打开 Codex 配置文件：
macOS / Linux：
1 | ~/.codex/config.toml |
Windows：
1 | C:\Users\你的用户名\.codex\config.toml |
在配置文件里添加或修改：
1 | model_provider = "openai_http" |
然后在文件末尾添加：
1 | [model_providers.openai_http] |
保存之后，重启 Codex。
这段配置的意思很简单：新建一个只走 HTTP 的 provider，并明确告诉 Codex 不要使用 WebSocket。
如果问题确实出在 WebSocket 代理上，重启后一般就不会再出现开头那一串重连了。
这个方案的副作用
需要注意一点：Codex 的历史会话可能会按 provider 分组。
从默认 provider 切换到 openai_http 后，原来 provider 下的部分历史会话可能暂时看不到。
这不一定代表历史记录丢了，只是 provider 变了，显示分组也跟着变了。如果后面想恢复，把配置改回去即可。
方案二：配置 .env，让 WebSocket 也能走代理
如果想保留 Codex 默认连接方式，可以显式告诉 Codex 代理地址在哪里。
在 Codex 配置目录下创建 .env 文件：
macOS / Linux：
1 | ~/.codex/.env |
Windows：
1 | C:\Users\你的用户名\.codex\.env |
Windows 用户要注意，文件名必须是 .env，不是 .env.txt。如果系统隐藏了文件后缀，很容易看起来叫 .env，实际却是 .env.txt。
.env 内容可以这样写：
1 | HTTP_PROXY="http://127.0.0.1:你的代理端口" |
比如 Clash 常见端口是 7890：
1 | HTTP_PROXY="http://127.0.0.1:7890" |
v2rayN 常见端口可能是 10808：
1 | HTTP_PROXY="http://127.0.0.1:10808" |
端口不要照抄，一定要以自己代理软件里显示的 HTTP 代理端口为准。
配置好之后，重启 Codex 再试。
这个方案的思路不是禁用 WebSocket，而是让 Codex 启动时就拿到代理环境变量，这样 WebSocket 握手也有机会正常走代理。
方案三：开启代理软件的 TUN 模式
还有一个更彻底的办法，是在代理软件里开启 TUN 模式。
TUN 模式不是只代理某个终端，也不是只靠环境变量，而是从虚拟网卡层面接管系统流量。理论上，Codex 的 WebSocket、HTTPS 以及其他请求，都更容易被代理软件接住。
但我不建议一上来就开 TUN。
它的影响范围比较大，可能会影响：
- 其他软件联网
- 公司内网访问
- 本地开发服务
- 局域网设备访问
- 某些 App 的网络行为
也就是说，Codex 可能好了，别的软件又开始出问题。
所以 TUN 更适合作为兜底方案：前两个方案都不行，再考虑它。
建议排查顺序
如果只是想最快恢复使用：
- 先用方案一，禁用 WebSocket，强制 Codex 走 HTTP。
- 如果想保留默认连接方式，再用方案二，给 Codex 配好代理环境变量。
- 如果前两个都不行，再考虑 TUN 模式。
我的倾向是：先用 openai_http 快速验证问题是不是 WebSocket，再决定要不要回头把代理环境变量配完整。
小结
如果 Codex 每次启动或首次响应时都出现：
1 | Reconnecting... 1/5 |
但最后又能正常回答，那它大概率不是账号问题，也不是模型问题。
更常见的原因是：
1 | WebSocket 没有正常走代理 |
处理思路也就两条：
- 要么禁用 WebSocket，直接走 HTTP
- 要么把代理环境变量配好，让 WebSocket 也能走代理
能用 openai_http 解决的，就先别把问题想复杂。网络问题有时候就是这么朴素，但它折磨人的方式一点也不朴素。