Codex 又 Reconnecting？不用重装，改一行配置就行

内容分享3小时前发布赛博大蟑螂-

0 1 0

用 Codex Desktop 的朋友，或多或少都遇到过这个场景：

打开一个新会话，敲下第一行提示词，发送。然后对话框里开始走马灯——“Reconnecting 2/5”“Reconnecting 3/5”……有时候卡在 5/5 半天，有时候重连完倒是能正常回答。

一次两次还能忍，每次新会话都来这么一出，体验直接从“丝滑”掉到“闹心”。

有人第一反应是重装软件。有人怀疑是网络问题，一通折腾。还有人干脆换回 web 版。

但说实话，这件事跟软件本身没太大关系。问题出在 Codex 默认走的那条“路”上——WebSocket。

为什么 Codex 一上来就“断片”

要搞清楚这个问题，得先知道 Codex Desktop 是怎么跟后端 AI 模型“说话”的。

Codex 支持两种通信方式：

第一种：WebSocket（默认优先）

建立一条长连接通道，服务器可以随时往客户端推数据。一次握手后持续通信，延迟低。

第二种：HTTP/SSE（备选降级）

走标准的 HTTPS 请求，服务器以 SSE 流式返回数据。本质上是普通的 HTTP 协议。

Codex 的默认策略是：能用 WebSocket 就用 WebSocket，连不上或升级失败再降级到 HTTP/SSE。

问题就出在这里。

WebSocket 连接的第一步叫做“协议升级”（WebSocket Upgrade）。客户端先发普通 HTTP 请求，请求服务器把协议从 HTTP 切换成 WebSocket。这个 upgrade 过程涉及从 HTTP 到 WebSocket 的状态转换，需要中间网络节点正确识别和转发 upgrade 头。

在许多网络环境下，这个 upgrade 请求会超时或被丢弃。Codex 的重试机制是：升级失败？再试一次。直到 5 次都用完了，才老老实实走 HTTP/SSE 降级路径。

这就解释了为什么每次首次请求都会被 Reconnecting 刷屏——那不是网络炸了，是 Codex 在 WebSocket 升级上反复碰壁，5 次后才肯走备选方案。

而且这只是首次请求时才发生。一旦降级成功，后续对话走 HTTP/SSE 就一路畅通了。

改一行配置，问题就解了

知道了根因，解法就很简单：不让 Codex 在 WebSocket 上白费功夫，直接告知它“这条路不通，走 HTTP/SSE”。

具体怎么做？修改 Codex 的配置文件 config.toml，新增一个只走 HTTP/SSE 的 provider。

第一步：找到 config.toml

Codex Desktop 的配置文件一般位于：

macOS：~/Library/Application Support/Codex Desktop/config.toml

Windows：%AppData%/Codex Desktop/config.toml

Linux：~/.config/Codex Desktop/config.toml

用文本编辑器打开它。

第二步：修改配置

在文件中找到或添加以下内容：

[ai]

model_provider = “openai_http”

[[ai.providers]]

id = “openai_http”

name = “OpenAI HTTP”

requires_openai_auth = true

supports_websockets = false

核心就三样东西：

1. model_provider = “openai_http” —— 告知 Codex 使用 HTTP provider

2. supports_websockets = false —— 关键配置，声明不走 WebSocket

3. requires_openai_auth = true —— 继续使用已有账号认证

第三步：保存并重启

保存文件，完全退出 Codex Desktop 再重新打开。新建会话发一条消息，如果正常返回、没有 Reconnecting，说明配置生效。

验证：怎么确认真的走 HTTP/SSE 了？

改完配置后，你可以在 Codex 的开发者工具或日志中看到通信方式的区别。

改之前：首次请求有明显延迟（WebSocket 升级尝试），伴随多条重连日志。

改之后：请求立即响应，没有延迟，没有重连提示。

如果你熟悉浏览器开发者工具，可以在 Codex 窗口内打开 DevTools（Cmd+Option+I），查看 Network 面板。走 WebSocket 时会有 wss:// 类型的请求，走 HTTP/SSE 时则是普通的 https:// 请求加上 text/event-stream 响应类型。

当然，最直观的验证方式还是看第一次请求有没有 Reconnecting 提示。