CodeX 老卡在“正在重新连接 5/5”？先别怪模型，一招绕开 WebSocket 直接走 HTTP

明明只让 CodeX 改一行代码，它却先花 30 秒表演“正在重新连接 1/5 … 5/5”，然后再来一轮“正在思考……”。你盯着终端，心里默念：它是在深度推理，还是单纯在摸鱼？

答案是：它在反复尝试连一条不通的路。 模型压根儿还没开始干活，网络层先帮你把超时重试全走了一遍。这跟你网速快不快没关系，跟你的代理或网络环境对 WebSocket 的支持有关系。CodeX 默认会优先走 WebSocket，但如果中间某个节点不支持或连接不稳定，它就得把 5 次重试跑满，再回退到 HTTP，然后才真正开始处理你的请求。

这一招的核心思路很简单：直接告诉 CodeX——别优先走 WebSocket，改用 HTTP / Responses 方式通信。 跳过那段反复失败的链路，省下几十秒无效等待时间。

问题到底出在哪一层？

很多人遇到这个情况，第一反应是“今天模型是不是又 overload 了”。但换个网络环境——比如手机热点——如果立刻变流畅，基本就能确认问题不在模型推理，而在连接链路。

人话解释一下 CodeX 的通信机制：

CodeX 和服务器之间有两种主要通信方式。

一种是 WebSocket。它的好处是保持长连接，适合需要持续对话、工具多次调用、流式输出的场景，体验更实时。但它对网络环境挑剔：代理不支持、防火墙拦截、某些节点对 WebSocket 握手不友好，都会导致连接失败。

另一种是普通的 HTTP / Responses。它没那么多前提条件，只要网络能通就能用，兼容性更好。但代价是每次请求可能多一点点额外的连接开销——这个开销绝大多数情况下远小于反复重连 5 次的时间。

CodeX 的默认行为是：先尝试 WebSocket，不行再回退到 HTTP。问题就出在这个“先尝试”的阶段。如果网络环境不适合 WebSocket，这 5 次重试就是白等的。

所以你看到的“正在重新连接 5/5”，大概率不是模型在反复思考同一个问题，而是连接层在不断尝试建连。模型层还没被唤醒。

理解了这层，解决方案就很直白了：跳过 WebSocket 优先尝试，直接让它走 HTTP / Responses。

实操配置：新增 HTTP Provider，关闭 WebSocket 优先

配置修改并不复杂，但有几个细节要注意，不然容易改完没生效。

第一步：定位配置文件

CodeX 的配置文件是 config.toml，不同系统的路径如下：

  • Windows：C:\Users\你的用户名\.codex\config.toml
    快捷方式：在文件资源管理器地址栏输入 %USERPROFILE%\.codex，然后找 config.toml。

  • Mac / Linux：~/.codex/config.toml

如果不确定路径，可以打开 CodeX 直接问它：

“

“请帮我定位当前 CodeX 的 config.toml 配置文件路径，只告诉我路径，不要修改文件。”

它会直接返回准确位置，省得自己翻。

第二步：备份——别觉得多余

改动配置文件之前，复制一份备份。这事看着不起眼，但万一改完连终端都起不来，至少能秒回退。

可以直接复制同目录下的 config.toml，重命名为 config.toml.bak。或者把原文件内容全选复制到记事本里存一份。

第三步：添加 HTTP / Responses Provider

打开 config.toml，在合适位置新增一个 provider。不要直接覆盖已有配置。 如果你原本有 model_provider 等配置，先保留，只做新增和顶部引用修改。

参考配置：

model_provider = "openai_http"

[model_providers.openai_http]
name = "OpenAI HTTP"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

这几项的含义拆开看：

  • model_provider = "openai_http"
    这行放在配置文件顶部（或全局位置），告诉 CodeX 默认使用哪个 provider。注意名字要与下方定义的方括号标题完全一致。

  • [model_providers.openai_http]
    定义一个新的 provider，名字叫 openai_http。方括号里的名字就是顶部 model_provider 引用的值，拼写必须完全一致。

  • wire_api = "responses"
    指定通信走 Responses API 方式，不走旧的 completions 之类。这个字段决定了底层 API 路由。

  • requires_openai_auth = true
    保留 OpenAI / ChatGPT 登录授权方式。如果你用的是其他认证方式，按实际情况调整，但绝大多数人保持 true 就行。

  • supports_websockets = false
    关键配置。明确告诉 CodeX：这个 provider 不支持 WebSocket，不要尝试。这样它就绕过了优先尝试 WebSocket 的阶段，直接走 HTTP。

常见踩坑点：名字写错。顶部写 model_provider = "openai_http"，但方括号写成 [model_providers.chatgpt_http]，那配置就不会生效。CodeX 找不到对应的 provider 定义，可能沿用默认行为，相当于白改。

第四步：重启 CodeX

保存配置文件后，关闭当前 CodeX 终端，重新打开一个新终端，再启动 CodeX。

然后发一个最简单的测试指令：

“

“请用一句话回复：CodeX 连接测试成功。”

观察启动后的第一反应。如果不再先卡一轮“重新连接 1/5 … 5/5”，而是直接开始处理，说明配置生效了。

如果仍然卡，别急着放弃，后面有排查流程。

不想手动改？直接把需求丢给 CodeX 帮你改

如果你对配置文件不熟悉，或者懒得自己动手，可以把下面这段提示词直接发给 CodeX，让它自己改自己：

“

请帮我检查并修改 CodeX 配置，目标是减少“正在重新连接 5/5”的问题。

要求：

  1. 先定位我的 ~/.codex/config.toml 文件；
  2. 先备份为 config.toml.bak；
  3. 不要删除我已有配置；
  4. 新增一个名为 openai_http 的 provider；
  5. 配置 wire_api = “responses”；
  6. 配置 supports_websockets = false；
  7. 如果我使用的是 ChatGPT / OpenAI 登录授权，请保留 requires_openai_auth = true；
  8. 修改完成后告诉我改了哪些内容；
  9. 最后让我重启 CodeX 测试。

这个方式适合不想折腾文本编辑器、或者担心改错格式的人。CodeX 会先定位文件、备份、再新增配置，最后给你一份改动清单。你只需要确认并重启。

改完没效果？按顺序查这几个地方

这招不是万能的。如果你改完配置，重启后依旧看到“正在重新连接 5/5”，按以下顺序排查，基本能定位问题。

① 检查配置是否真正生效

重新打开 config.toml，核对几个关键点：

  • 顶部 model_provider = "openai_http" 和下方 [model_providers.openai_http] 名字是否完全一致（包括大小写和下划线）；
  • supports_websockets = false 这一行是否确实存在，没有被注释掉（前面没有 #）；
  • 配置文件保存后，是否有其他进程把配置覆盖回去了（比如某些同步工具）。

如果配置没问题，但依然走 WebSocket，可以尝试在 CodeX 启动时加环境变量强制指定，但最稳定的方式还是确保配置文件被正确加载。

② 升级 CodeX 版本

旧版本可能存在 WebSocket 回退逻辑的 bug，或者对 supports_websockets = false 的支持不完善。

如果你是通过 npm 安装的，可以执行：

npm install -g @openai/codex@latest

如果通过其他包管理器安装，用对应的更新命令。升级后再重启测试。

③ 检查代理和网络环境

这是最可能的原因。如果你的代理本身对 WebSocket 就不稳定，即使配置了不优先走 WebSocket，CodeX 在某些场景下仍可能尝试 WebSocket（比如工具调用或长时间对话）。

你可以做几个快速测试：

  • 切换到全局代理模式，而不是 PAC 模式；
  • 更换节点，尤其避开某些对长连接不友好的地区节点；
  • 如果用了 Clash、Surge 等代理工具，检查是否对 wss:// 协议做了特殊拦截；
  • 暂时关闭防火墙或安全软件，排除误拦截；
  • 换成手机热点，对比一下速度差异。如果热点下明显变快，基本就是当前网络链路的问题。

有些代理工具对 HTTP/HTTPS 支持很好，但对 WebSocket 的握手协议处理得不太好，尤其是多层代理叠加的时候。这时候即使 CodeX 配置了 supports_websockets = false，某些内置调用链路仍可能尝试 WebSocket，导致间歇性卡顿。

④ 新建会话测试

有时旧会话里缓存了旧的 provider 信息或上下文，导致配置虽改了但当前会话没加载。

关掉当前终端，重新进入项目目录，全新启动 CodeX，再发测试指令。避免加载历史会话的残留状态。

⑤ 检查是不是公司网络或防火墙限制

公司网络通常对 WebSocket 这类长连接协议有更严格的限制。如果你在公司环境，可以试试回家后用同一配置测试。如果家庭网络正常，那基本确认是公司网络策略问题。

这种情况下，单纯改 CodeX 配置可能只能缓解一部分问题，根本解决需要调整网络代理策略，或者使用支持 WebSocket 转发的隧道工具。

为什么有些人不改也能用？

这个问题很常见：网上有人说“我什么都没改，一直都很快”，有人说“改了也没用，还是卡”。为什么体验差异这么大？

这跟网络路径有很大关系。CodeX 默认优先走 WebSocket，如果你的网络链路恰好对 WebSocket 很友好，握手一次成功，就不会触发重试机制，你完全感知不到这个问题。如果链路经过某些对 WebSocket 不友好的节点，就会卡在重试阶段。

所以这不是 CodeX 的 bug，而是默认行为在不同网络环境下的副作用不同。

这个配置的本质是改变优先级，而不是禁用 WebSocket 功能。它让 CodeX 在不适合 WebSocket 的环境下少走弯路，减少无效等待时间。如果你的网络环境本身就支持 WebSocket，保持默认即可，不必多此一举。

这个方案的代价是什么？

任何绕过 WebSocket 的做法都有代价，只是这个代价在你当前的场景下是否值得。

代价：HTTP 方式每次请求可能需要重新建立连接，在长对话或多轮工具调用场景下，比 WebSocket 的持续连接多一点点握手开销。但这个开销通常是几十毫秒级别。

收益：省去 5 次重试等待，每轮请求可能节省 10-30 秒，尤其是在网络环境较差的场景下。

换算一下：如果你一天触发 50 次 CodeX 请求，每次省 20 秒，一天就是 1000 秒，接近 17 分钟。对于高频使用者来说，这笔账很划算。

而且 CodeX 在 HTTP 模式下依然能正常使用所有工具调用和多轮对话能力，只是底层传输方式不同，上层功能完全一致。

如果问题依旧，可能不只是 WebSocket 的事

把 WebSocket 优先级调低之后，如果“正在思考……”依然很久，那就不是连接问题，而是模型推理本身慢，或者工具调用链路有延迟。

这时可以继续排查：

  • 检查是否在超大代码库中执行任务，上下文过大导致推理缓慢；
  • 检查是否同时调用了多个外部工具，每个工具响应时间叠加；
  • 检查 CodeX 的日志输出，看具体卡在哪个环节。

配置调整解决的是连接阶段的卡顿，模型推理速度不在它的作用范围内。别指望改完配置文件后模型能变快，这跟模型性能无关。

实用摘要 / 操作清单

快速回顾一下整个流程：

  1. 定位问题：看到“正在重新连接 5/5”先别怪模型，它很可能只是在走 WebSocket 重试流程。
  2. 定位配置文件：%USERPROFILE%\.codex\config.toml（Windows）或 ~/.codex/config.toml（Mac/Linux）。
  3. 备份原文件：复制一份 .bak 备用。
  4. 新增 HTTP provider：在配置文件中添加 [model_providers.openai_http]，设置 wire_api = "responses"、supports_websockets = false，顶部引用 model_provider = "openai_http"。
  5. 重启 CodeX，用简单指令测试效果。
  6. 如果无效：按顺序检查配置生效、升级版本、切换网络节点、新建会话。
  7. 如果依然无效：排查是否网络代理本身对 WebSocket 不稳定，或者公司防火墙限制。

一页速览

问题现象 根本原因 解决方案
改小文件却先花 30 秒显示“正在重新连接 1/5 … 5/5” CodeX 默认优先尝试 WebSocket，网络环境不支持导致 5 次重试 新增 HTTP / Responses provider，关闭 WebSocket 优先
改完配置重启后仍卡 配置未生效 / 代理本身问题 / 旧会话缓存 检查配置拼写、升级 CodeX、换节点、新建会话
改完配置后偶尔还卡 CodeX 某些场景仍尝试 WebSocket，或模型推理本身慢 检查日志定位具体卡点，排查工具调用或上下文过大

FAQ

Q1：改了配置之后会影响 CodeX 的其他功能吗？
不影响。工具调用、多轮对话、文件读写等功能完全一致，只是底层通信方式从 WebSocket 切换为 HTTP/Responses。

Q2：我改完之后连 CodeX 都启动不了了怎么办？
用备份的 config.toml.bak 覆盖回去，恢复原始配置，然后重新检查新增配置的格式是否正确。

Q3：每个 CodeX 项目都要单独配置吗？
不需要。config.toml 是全局配置文件，修改一次对所有项目生效。

Q4：为什么我改了配置但顶部 model_provider 还是默认值？
需要手动修改顶部的 model_provider 指向新定义的 provider 名字。只新增 provider 但不改顶部引用，默认仍走原有配置。

Q5：wire_api = "responses" 和 wire_api = "completions" 有什么区别？
responses 是较新的 API 方式，支持更丰富的交互模式；completions 是旧版方式。建议使用 responses，兼容性更好。

Q6：HTTP 模式会比 WebSocket 模式更慢吗？
在连接稳定但 WebSocket 不友好的环境下，HTTP 模式反而更快，因为跳过了重试阶段。在网络极佳且 WebSocket 握手一次成功的环境下，WebSocket 略快，但差距很小。

Q7：我用的是企业版 CodeX，配置路径不一样怎么办？
企业版配置路径可能因部署方式不同而有差异，直接问 CodeX “请帮我定位当前 config.toml 路径”是最快的方式。

Q8：配置改了之后，需要每次重启 CodeX 都重新设置吗？
不需要。配置持久化保存在文件中，重启后自动加载。

图片来源：Unsplash

改配置这件事，本质上是在帮你减少不必要的无效等待。它不解决所有问题，但至少让 CodeX 别再在一条不通的路上反复试探。如果你的网络环境本身就支持 WebSocket，你甚至感知不到这个改动；如果你的环境不那么理想，这 30 秒可能就是每次交互最恼人的那一段。

试试看，让 CodeX 先把活干起来，再谈推理深度。