前言

使用 Codex 时，有些人会在发送消息后反复看到下面的提示：

1
2
3
4
5
Reconnecting... (1/5)
Reconnecting... (2/5)
Reconnecting... (3/5)
Reconnecting... (4/5)
Reconnecting... (5/5)

3ae80cff6f5b5c196c5e553f3849453b

或者是

1
stream disconnected before completion: The service is temporarily unavailable. Please retry later.

image-20260914203533170

奇怪的是，等它重试完之后，回答有时又能正常出现。

这类现象很容易被误判成模型响应慢、账号异常或者 OpenAI 服务故障。实际上，如果每次都是“连续重连几次，随后恢复正常”，更值得怀疑的是传输链路：普通 HTTPS 请求能够通过，但 WebSocket 长连接没有被当前代理、网关或防火墙正确转发。

本文从 Codex 的传输方式入手，解释问题为什么发生，并给出一个可回退、容易验证的处理方案。

说明：本文讨论的是一种常见原因，并不代表所有 Reconnecting 都由 WebSocket 引起。修改配置前请先备份原文件；如果 OpenAI 服务状态异常、认证失效或整个网络都不可用，本文方案不会解决这些问题。

为什么 HTTPS 正常，WebSocket 却可能失败

Codex 与模型服务通信时，Responses API 可以通过不同的传输方式返回结果：

  • HTTPS 流式传输：客户端发起 HTTP 请求，服务器通过流式响应持续返回事件。
  • WebSocket：客户端建立一条持久的双向连接，在同一连接中持续交换数据。

WebSocket 适合长时间运行、需要持续交互的 Agent 工作流，但它对中间网络设备的要求也更高。企业网关、校园网、透明代理、部分代理节点以及 TLS 检查设备，都可能允许普通 HTTPS 流量通过，却无法稳定处理 wss:// 连接。

于是就会形成这样的过程：

1
2
3
4
5
6
7
8
9
10
11
Codex 发起对话
    ↓
尝试建立 WebSocket
    ↓
连接失败并重试
    ↓
达到重试条件
    ↓
回退到 HTTPS 流式传输
    ↓
回答恢复正常

这也解释了为什么界面先显示多次 Reconnecting，最后却仍然可以得到回答：模型本身未必有问题，真正失败的可能只是优先尝试的传输通道。

先判断是否符合本文场景

在改配置之前，可以先做一个简单判断。

符合以下特征时，WebSocket 兼容问题的可能性较高：

  1. 普通网页和 HTTPS API 可以正常访问。
  2. Codex 几乎每次新建对话都会固定重连数次。
  3. 重连结束后通常还能正常回答。
  4. 更换网络、代理节点或开启 TUN 模式后，现象会发生变化。

如果连登录、模型列表或普通请求都无法完成，应优先检查账号认证、代理端口、DNS、系统时间以及服务状态，而不是直接修改 WebSocket 配置。

核心解决方案：让 Codex 直接使用 HTTPS

Codex 的用户级配置文件位于：

1
~/.codex/config.toml

不同系统对应的常见路径如下：

1
2
3
Windows：%USERPROFILE%\.codex\config.toml
macOS：  ~/.codex/config.toml
Linux：  ~/.codex/config.toml

OpenAI 官方配置参考中，model_provider 用于选择模型提供方；model_providers.<id>.supports_websockets 用于声明该提供方是否支持 Responses API 的 WebSocket 传输；wire_api 当前使用 responses。

备份现有配置

Windows PowerShell：

1
Copy-Item "$env:USERPROFILE\.codex\config.toml" "$env:USERPROFILE\.codex\config.toml.bak"

macOS / Linux：

1
cp ~/.codex/config.toml ~/.codex/config.toml.bak

如果配置文件还不存在，可以先创建 .codex 目录和空的 config.toml。

添加一个禁用 WebSocket 的提供方

在 config.toml 中加入以下内容：

1
2
3
4
5
6
7
model_provider = "openai_http"

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

其中最关键的是：

1
supports_websockets = false

它告诉 Codex：当前模型提供方不支持 Responses API 的 WebSocket 传输，因此不要再尝试建立 WebSocket 连接。

其余字段的作用如下：

配置项 作用
model_provider 选择下方定义的 openai_http 提供方
name 提供方的显示名称
wire_api = "responses" 继续使用 Responses API
requires_openai_auth = true 沿用 OpenAI 认证
supports_websockets = false 禁止该提供方使用 WebSocket

TOML 层级很重要：model_provider = "openai_http" 必须是顶层配置，不要误写进 [model_providers.openai_http] 表中。如果文件里已经存在 model_provider，请修改原值，不要重复定义同一个键。

完全退出并重新启动 Codex

保存文件后，关闭所有 Codex 窗口和仍在运行的 Codex 进程，再重新启动。仅关闭当前对话不一定会重新加载用户级配置。

代理应该怎么处理

禁用 WebSocket 只能绕开 WebSocket 通道，它不会自动解决“HTTPS 本身也无法访问”的问题。如果你的网络环境需要代理，还要确保 Codex 进程能够继承正确的代理设置。

以本地 HTTP 代理端口 7890 为例，可在启动 Codex 的同一终端中临时设置：

Windows PowerShell：

1
2
3
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
codex

macOS / Linux：

1
2
3
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
codex

端口必须以你的代理软件实际显示为准，常见值可能是 7890、10809 等。

部分版本或第三方启动方式会从 ~/.codex/.env 读取代理变量，但 OpenAI 当前公开的稳定环境变量文档没有把 ALL_PROXY 或 .env 代理加载列为稳定接口。因此，更稳妥的做法是使用系统代理、代理软件的 TUN 模式，或从已经设置好 HTTP_PROXY / HTTPS_PROXY 的终端启动 Codex。

如何验证是否修复

重启 Codex 后，新建一个对话并发送一条简单消息，观察以下结果：

  • 不再依次出现 Reconnecting (1/5) 到 (5/5)。
  • 首个响应事件更快出现。
  • 连续新建多个对话，表现保持稳定。
  • 工具调用和长回答仍能正常流式输出。

建议至少测试三次，避免把偶然的网络恢复误认为配置已经生效。

如果问题仍然存在，可以按下面的顺序继续排查：

  1. 检查 config.toml 是否存在重复的 model_provider。
  2. 确认 supports_websockets = false 位于正确的 provider 表中。
  3. 确认修改的是用户级 ~/.codex/config.toml，而不是项目目录中的 .codex/config.toml。官方文档明确说明，项目级配置不能覆盖 model_provider 和 model_providers。
  4. 暂时切换网络或代理节点，判断是否为节点侧限制。
  5. 检查认证状态和 OpenAI 服务状态。
  6. 恢复备份配置，确认故障是否与本次改动有关。

不建议禁用 WebSocket的情况

如果当前网络能够稳定处理 WebSocket，而且你依赖长连接带来的低延迟或持续交互能力，就没有必要关闭它。

supports_websockets = false 更适合作为兼容性方案：用较通用的 HTTPS 流式传输换取稳定性。它不会把 Responses API 改成旧接口，但会放弃 WebSocket 传输本身可能带来的部分实时交互优势。

如果换成支持 WebSocket 的网络环境后想恢复，只需把 model_provider 改回原来的提供方，或恢复此前备份的 config.toml。

参考资料