Codex 为什么总是先重连 5 次才开始回答？一次讲清并给出可回滚修复方案

摘要： Codex用户常遇到连接延迟问题，表现为新对话前需经历5次WebSocket重连(Reconnecting...)，严重影响使用效率。该问题源于网络环境对WebSocket不稳定，客户端默认优先尝试WebSocket通道，失败后才切换至HTTPS。解决方案是通过修改config.toml配置文件，显式指定使用HTTPS传输并禁用WebSocket（添加supports_websockets

像风一样自由2020

5375人浏览 · 2026-04-22 00:30:00

像风一样自由2020 · 2026-04-22 00:30:00 发布

Codex 为什么总是先重连 5 次才开始回答？一次讲清并给出可回滚修复方案

在这里插入图片描述

最近不少同学在用 Codex 时会遇到一个很影响体验的问题：

发起新对话或执行 /new 后，界面先出现多次 Reconnecting...
往往要等到第 5 次之后，才开始正常回答
有时还会看到“从 WebSocket 回退到 HTTPS”的提示

这个问题最烦人的地方不在于“完全不能用”，而在于：

它会稳定浪费你每次开工前的几十秒。

如果你一天开很多轮任务，这个时间损耗会非常明显。

这篇文章不讲空话，直接给你一套可复现、可验证、可回滚的处理方案，并把副作用讲清楚。

一、问题现象到底是什么

典型现象是：

你发起请求后，长时间没有正式输出
中间不断显示 Reconnecting... 1/5、2/5、…、5/5
之后才进入正常回复，或者提示回退到 HTTPS 传输

在社区 issue 里，这类现象不是个例。
例如：openai/codex#14297（后被标记为重复并合并到 #14209），以及与 WebSocket 超时/回退相关的 #13710。

二、为什么会这样：先走 WebSocket，失败后再回退

从公开 issue 中的日志和复现现象看，比较一致的链路是：

客户端优先尝试 WebSocket 通道
当前网络环境对 WebSocket 不稳定（握手、策略、链路质量、代理等原因）
客户端执行多次重连重试
重试耗尽后，才切到可用的 HTTPS 通道

所以你体感到的是：

“每次都要先卡一段重连时间，再开始干活。”

注意：这里的“5 次重连”与“等待时间”是基于问题复现与日志表现的工程结论，不是官方协议文档里承诺的固定值。

三、最直接的处理思路：显式使用 HTTPS provider，禁用 WebSocket

如果你的网络环境里 WebSocket 经常不稳定，最稳妥的思路是：

不要等它反复失败，直接让它走 HTTPS。

对应做法是在 config.toml 里增加一个自定义 provider，并明确：

wire_api = "responses"
supports_websockets = false

配置示例（可直接用）：

# 顶部增加或修改
model_provider = "openai_https"

# 文件末尾增加
[model_providers.openai_https]
name = "OpenAI"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false