相信大家在用 Codex 的时候都遇到过这种事：打开 Codex，还没开始问问题，它就先给你整一段固定表演：
Reconnecting…1/5 Reconnecting…2/5 Reconnecting…3/5 Reconnecting…4/5 Reconnecting…5/5
而且不是偶尔，是每次都这样。最离谱的是，转完五圈之后，它又莫名能用了，回答得好好的，就在那儿干等一两分钟，心态都被搞完了。
原因是什么？
一开始以为是梯子不行、账号有问题，甚至怀疑是 Codex 自己崩了。后来翻了半天资料才发现，原因其实不复杂：简单说就是 WebSocket 没走通。
Codex 默认会优先用 WebSocket（WSS 协议）去跟服务器保持实时连接，但很多代理环境下，WSS 握手并不一定能正常走代理。
于是经典的流程就来了：先尝试 WebSocket 连接，失败，再试，又失败，一直试 5 次，每次大概超时 20 秒，加起来差不多一两分钟白给。全失败之后，它才放弃 WebSocket，降级回普通的 HTTP 请求。而 HTTP 反而能正常走代理，所以你就看到了前面疯狂 Reconnecting，后面突然正常的神奇场面。
解法一：强制走 HTTP（最快最直接）
如果你不想折腾代理配置，这个方法最快最直接。直接告诉 Codex：别连 WebSocket 了，全程走 HTTP 就好。
打开 Codex 配置文件：
- macOS / Linux：~/.codex/config.toml
- Windows：C:\Users\你的用户名.codex\config.toml
在文件顶部加一行：
model_provider = "openai_http"
然后在文件末尾加上这一段：
[model_providers.openai_http]
name = "OpenAI HTTP only"
wire_api = "responses"
supports_websockets = false
保存重启 Codex，那个让人烦的 Reconnecting 罚站流程就没了。
有一点小副作用：切到 openai_http 这个 provider 之后，原来的部分历史会话分组可能会暂时看不见，因为历史记录是按 provider 归类的。不是不见了，想回去的时候把配置还原就行。
解法二：配置代理（保留默认连接方式）
如果你不想禁用 WebSocket，希望 Codex 保持原来的连接方式，那就用这个方案：写一个 .env 文件，显式告诉 Codex 代理地址。
文件位置：
- macOS / Linux：~/.codex/.env
- Windows：C:\Users\你的用户名.codex.env
文件内容：
HTTP_PROXY="http://127.0.0.1:你的代理端口"
HTTPS_PROXY="http://127.0.0.1:你的代理端口"
NO_PROXY="localhost,127.0.0.1,::1"
端口换成你自己代理软件的实际端口。比如 Clash 常见的是 7890，v2rayN 常用端口可能是 10808。
这个方案的核心就是让 WebSocket 握手也能正确走代理，这样 Codex 就不用先失败 5 次再 fallback 了，连接会快很多。
解法三：开 TUN 模式（最后兜底）
如果上面两个方法都试了还不行，那就得上更粗暴的办法——在代理软件里开 TUN 模式。
TUN 的逻辑是不再只代理某个软件或终端环境变量，而是从虚拟网卡层面接管系统流量。理论上，Codex 的 WebSocket、HTTPS、各种请求都能被一把接住。
但不太建议一上来就开 TUN，因为它影响面太大了，可能别的软件会受影响，内网服务、本地开发服务、甚至某些 App 的网络行为都会跟着变。最好把 TUN 当兜底方案，前面两个实在不行了再考虑。
建议顺序
想快速解决就用第一个。愿意折腾一下保持原体验的可以试第二个。TUN 模式留到最后。希望这篇分享能帮大家省下那罚站的一两分钟，时间还是留给写代码本身吧。