Codex 一直卡在 Thinking / Reconnecting？WebSocket 与 SSE 排错教程

Codex 卡住时，界面看起来都差不多：一直转圈，一直显示 Thinking，偶尔再冒出一句 Reconnecting... 1/5。

但我把 OpenAI 的配置文档、官方仓库里的几个 Issue 和社区讨论放在一起看，发现这两种情况真不能混着修。

有些中转是 HTTPS/SSE 首包容易卡，打开 WebSocket 之后会好一些。还有一些代理压根带不动 WebSocket，Codex 每次先重连 5 次，最后回退到 HTTPS 才开始正常回复。你要是没分清自己属于哪一种，照着别人的配置抄，很可能越改越慢。

先说明一下：这篇是官方文档和公开故障案例的核对版，不是我拿某一家中转做的亲测广告。官方文档能确认配置项的含义；GitHub Issues 只能证明有人在特定版本和环境里遇到过这些现象，不能自动变成官方认定的统一根因。下面的配置能告诉你该怎么判断、怎么做 A/B，但不能替任何中转保证稳定。

先看你卡住时到底显示了什么

别急着改 config.toml。先盯着界面看一次，把现象归到下面几类。

这里最容易误判的是第一种。

OpenAI 官方仓库里有一例 Windows Codex Desktop 的报告：gpt-5.5 配 xhigh reasoning，提交任务后等了 30 分 38 秒才出现第一段输出。报告者自己的历史数据里，xhigh 也更容易出现长尾等待，但他没有把原因直接定成 WebSocket。

所以，只有 Thinking 三个字，证据还不够。

先做一个 30 秒的短会话测试

新建会话，不带旧聊天上下文，发一句：

只回复 READY，不要调用工具。

结果大致有三种：

1. 几秒内回复：基础链路能用，原来的问题更像长上下文、推理档位或工具任务。
2. 仍然 Thinking 很久，但没有重连：先把 reasoning 从 xhigh 降到 medium 或 low 再测。
3. 立刻开始 Reconnecting...：继续查网络传输和 provider。

这一步看着简单，但很有用。别拿一个已经聊了几十轮、刚跑过一堆命令的会话去测“网络到底通不通”，变量太多。

你走官方登录，还是第三方中转

接下来先确认 Codex 请求发到哪里。

ChatGPT 登录 / OpenAI 官方入口

如果你是用 ChatGPT 账号登录，没有改过 base_url，先不要套后面的中转配置。

你更应该做的是：

• 记录 Codex 版本和使用入口：CLI、Desktop 还是 VS Code；
• 换一个网络或暂时绕开公司代理再测；
• 新短会话与原长会话对比；
• CLI 可用时运行 codex doctor --summary；
• 看官方仓库是否有相同版本、相同入口的故障。

官方 OAuth 场景和 API Key 中转不是一回事。为了关一个 WebSocket，硬把登录方式和 provider 一起换掉，反而会多出认证问题。

第三方中转 / 自建网关

如果你在 ~/.codex/config.toml 里配了 modelprovider、baseurl，或者请求本来就经过 New API、CLIProxyAPI 一类网关，才进入本文的 WS / SSE 分支。

这时你要问中转的不是：

支不支持 OpenAI？

而是：

支不支持 Responses API 的 WebSocket 传输？能不能完整收到 response.completed？

很多网关能跑普通 OpenAI 兼容接口，不代表已经实现了 Codex 使用的 Responses WebSocket。

先确认 Codex 实际读到了哪份配置

Codex 的 provider 配置应该放在用户级配置里：

• Windows：C:\Users\你的用户名\.codex\config.toml
• macOS / Linux：~/.codex/config.toml

不要把 provider 写进项目的 .codex/config.toml。OpenAI 官方文档明确列了限制：项目级配置不能覆盖 modelprovider、modelproviders 和 openaibaseurl 这类会改变认证或服务地址的键。

CLI 里可以输入：

/debug-config

它会显示配置层的读取顺序和生效情况。再输入：

/status

确认当前模型、上下文和会话配置。

新版 CLI 还可以先跑：

codex doctor --summary

需要留一份给自己排查或提交 Issue 的脱敏报告，可以用：

codex doctor --json

如果你的版本没有 codex doctor，先执行 codex --version 记下版本。命令不存在只说明版本还没提供这项诊断，不是新的网络报错。

情况一：中转明确支持 WebSocket

如果中转文档明确写了支持 Codex Responses WebSocket，而且服务端也真的开启了对应能力，可以先建一个单独的 provider：

model = "你的模型名"
model_provider = "relay_ws"

[model_providers.relay_ws]
name = "My relay with WebSocket"
base_url = "https://你的中转地址/v1"
env_key = "OPENAI_API_KEY"
wire_api = "responses"
supports_websockets = true

这里几个值别照抄：

• model 填中转实际提供的模型名；
• base_url 是否带 /v1，看中转文档；
• env_key 写的是环境变量名字，不是把 Key 明文塞进去。

Linux / macOS 当前终端设置 Key：

export OPENAI_API_KEY="你的 Key"

Windows PowerShell：

$env:OPENAI_API_KEY = "你的 Key"

完全退出 Codex，再开一个新会话测试。

LinuxDo 那篇“首包卡死”调查，主要说的就是这类情况：有些中转的 SSE 路径会卡在首包，如果服务端把 WebSocket 实现完整，启用 WS 有机会绕开这条不稳定路径。

注意我的措辞是“有机会”，不是“根治”。这个判断来自社区案例，不是 OpenAI 对所有中转作出的保证。

情况二：代理或中转不支持 WebSocket

另一类情况刚好相反。

openai/codex 的 Issue #19821 记录了一个很典型的现象：代理环境无法正确传输 WebSocket，Codex 每轮先显示 Reconnecting... 1/5 到 5/5，耗尽重试之后才出现 falling back to HTTP，而 HTTP 请求其实很快就能完成。

这种环境继续硬开 WS 没意义。另建一个 provider，明确告诉 Codex 直接走 HTTPS/SSE：

model = "你的模型名"
model_provider = "relay_sse"

[model_providers.relay_sse]
name = "My relay over HTTPS/SSE"
base_url = "https://你的中转地址/v1"
env_key = "OPENAI_API_KEY"
wire_api = "responses"
supports_websockets = false

为什么要另起名字？

因为 openai、ollama 和 lmstudio 是保留的内置 provider ID。官方文档不允许你用 [modelproviders.openai] 重新定义它。relaysse、my_proxy 这种自定义名字才行。

官方仓库还有一个 Issue #13041：WebSocket 看起来已经连接成功，随后服务端却用 1008 Policy 关闭连接，客户端进入重连再回退 HTTPS。

这也提醒了一点：握手成功不等于整条流能正常跑完。

不要先改重试次数和 5 分钟超时

OpenAI 当前配置参考里有两个参数：

stream_max_retries = 5
stream_idle_timeout_ms = 300000

官方给出的含义是：

• streammaxretries：SSE 流中断后的重试次数，默认 5；
• streamidletimeout_ms：SSE 流空闲超时，默认 300000 毫秒，也就是 5 分钟。

如果中转根本不支持 WebSocket，把 SSE 重试改成 10 解决不了 WS 建连问题。反过来，如果 SSE 已经没有事件了，把空闲超时从 5 分钟拉到 10 分钟，也可能只是多等 5 分钟。

我的建议是：先选对传输方式。只有确认 SSE 本身能稳定工作，只是长任务确实超过默认空闲窗口，才考虑调整这些参数。

改完以后怎么验证

不要凭“这次好像快了点”下结论。拿同一台机器、同一个网络、同一个模型和同一句提示，做两轮。

第一轮还是用：

只回复 READY，不要调用工具。

短任务通了，再补一轮会调用工具的小任务，例如让 Codex 读取一个测试目录里的文本文件并汇总。别直接让它改主项目。

如果 WS 模式连续出现重连，而 SSE 模式几次都能快速完整结束，那就没必要为了“新协议”硬开 WS。反过来，如果 SSE 经常卡首包，而 WS 能稳定结束，才有理由保留 WS。

关了 WS 还是卡，继续查这四处

1. reasoning 太高

纯 Thinking、没有任何重连提示时，先降推理档再测。尤其是短问题，没必要用 xhigh 去验证网络。

2. 会话太长

新会话秒回，旧会话卡，不要继续折腾 provider。先压缩上下文，或者把当前目标和必要材料带到新会话。

3. 后台工具没退出

Codex 是在等模型，还是在等一个命令结束，界面上未必一眼能看出来。CLI 可以用：

/ps

看后台终端。如果是测试、开发服务器或监听命令一直没退出，处理的是进程，不是 WebSocket。

4. 只有某一个入口出问题

同一网络下，CLI 正常但 Desktop / VS Code 一直卡，问题范围已经缩小到客户端、扩展或 app-server。提交反馈时一定写清楚入口和版本，别只留一句“Codex 卡死”。

真要报 Issue，至少准备这些

• Codex 入口：CLI、Desktop 或 VS Code；
• Codex 版本和操作系统；
• 登录方式：ChatGPT、官方 API Key 还是中转；
• 完整报错文字；
• 是否出现 Reconnecting... n/5；
• 新短会话能不能复现；
• WS 开 / 关后的首包时间和完成情况；
• codex doctor --json 的脱敏结果（版本支持时）。

Key、auth.json、代理订阅地址别贴。中转域名如果不方便公开，也可以脱敏，但要说明请求是否经过代理、WAF 或自建网关。

写在最后

Codex 卡在 Thinking 和反复 Reconnecting，表面上都像“它没反应”，排法却不一样。

我的判断顺序很简单：

1. 先用新短会话排除长上下文和高 reasoning；
2. 再分官方登录还是第三方中转；
3. 中转完整支持 Responses WebSocket，才试 supports_websockets = true；
4. 代理或中转带不动 WS，就设为 false，直接走 HTTPS/SSE；
5. 用同一句短提示记录首包和完整结束，别靠感觉。

最关键的不是 WebSocket 一定比 SSE 好，也不是 SSE 一定更稳。中转实际实现了什么，你就选什么。协议没实现完整，参数调得再漂亮也没用。

如果你正好遇到这个问题，可以把脱敏后的报错、Codex 版本、使用入口，以及 WS 开关前后的结果留在评论里。我会把能复现的情况补进后续版本，不收 Key，也别发登录文件。

参考资料

• OpenAI Codex Configuration Reference
• OpenAI Codex Advanced Configuration
• OpenAI Codex Developer Commands
• openai/codex Issue #19821：WS 建连失败后才回退 HTTP
• openai/codex Issue #13041：WebSocket 收到 1008 Policy
• openai/codex Issue #23665：WS 临时失败后的回退行为
• openai/codex Issue #24260：Desktop 长时间 Thinking
• LinuxDo：codex 首包卡死问题调查和解法

相关阅读

OpenAI Codex CLI 完整教程：安装、订阅、额度和国内使用避坑

2026 最新 OpenAI Codex CLI 完整教程：从安装登录、ChatGPT Plus/Pro 订阅额度、模型选择，到国内网络、代理、Windows/WSL2 和 API Key 避坑一次讲清。

TuBaiBai's BlogTuBaiBai

Claude Code 接第三方 / 中转 Key：环境变量怎么配，401 和模型名怎么排查

Claude Code 要用中转或自建网关的 Key，得改 ANTHROPIC_BASE_URL 和鉴权变量。按官方支持的接法写配置步骤，以及 401、路径不对、模型名对不上、流式卡死时怎么查。

TuBaiBai's BlogTuBaiBai