打开 Codex,界面先给自己演一轮正在重新连接,1/5,2/5,一路数到 5/5。转圈转到你以为它卡死了。隔一段时间再打开,又来一遍。
第一次碰到会以为账号出问题,或者模型又崩了。次数多了才看明白,这多半跟账号和模型都没关系,是网络通道的事。

Codex 传响应默认走 WebSocket 长连接。电脑上的代理要是没把这个通道接住,它就一遍遍重试,试满五次,才降级走普通的 HTTPS 请求。你看到的那几分钟硬控,就是它在那儿原地重试。
判断也有个很简单的依据。网页打开 OpenAI 一切正常,只有每次对话开头固定重连几次,那多半是代理没接管 WebSocket,别先去怪模型。
解决办法从轻到重有好几档,通常最轻的那一档就够用。
最省事的一档,是给它写一个代理配置文件。Codex 会从用户配置目录读一个 .env 文件。Mac 和 Linux 在 ~/.codex/.env,Windows 在 C:\Users\你的用户名\.codex\.env。先打开代理软件,看清楚本地 HTTP 代理端口,Clash 系常见 7890,v2rayN 常见 10808,以软件里实际显示的为准。然后在文件里补上两行:
HTTP_PROXY=”http://127.0.0.1:端口号”
HTTPS_PROXY=”http://127.0.0.1:端口号”
写完保存,把 Codex 彻底重启,让它重新读一遍配置。多数人到这里,那轮重连表演就停了。

不想自己找端口写文件的,可以把整件事丢给 Codex 自己做。跟它说,检查一下我电脑的本地 HTTP 代理端口,然后帮我创建 ~/.codex/.env 文件,在里面写入 HTTP_PROXY 和 HTTPS_PROXY 两个环境变量,值都设成 http://127.0.0.1:端口号,端口就用你刚查到的那个。它会自己探测端口,自己建文件写配置,你只负责重启一次。
再彻底一点,把 WebSocket 直接关掉,强制走 HTTPS。打开 ~/.codex/config.toml,把 model_provider 改成 openai_http,再加一行 supports_websockets = false。这样它不再尝试 WebSocket,全程走普通 HTTPS,开头那五次重试也就不存在了。副作用是历史会话会按 provider 重新分组,看着像不见了,数据还在,配置改回去就能恢复。
最后一招是兜底,在代理软件里开 TUN 模式。TUN 从网卡这一层接管流量,覆盖面最大,Codex 的 WebSocket 大概率能被接住。它的影响范围也大,其他软件、内网、本地服务的网络行为都可能跟着变,不建议一上来就开,前面两档都不行再考虑。
配完还偶发重连的,按顺序回头查几处。代理软件在不在运行,.env 文件放的位置对不对,Windows 上的文件名有没有被系统存成 .env.txt,端口跟代理软件里设置的能不能对上。公司网络或者防火墙拦了 WebSocket,最省事的那一档通常救不了,直接关掉 WebSocket 更省心。
顺手把 Codex 做一次版本更新,有些重连问题本来就是旧版连通逻辑的毛病。
重连五次不是 Codex 坏了,是它没找着路。给它指条路,它自然就安静了。下次再看到那行正在重新连接,先别急着关掉,把上面那句指令丢给它。