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。先盯着界面看一次，把现象归到下面几类。
| 现象 | 优先怀疑 | 第一件事 |
|---|---|---|
只有 Thinking，一直没有输出 | 模型推理、长上下文、服务端首包、客户端状态或工具进程 | 新开一个短会话测试 |
出现 Reconnecting... 1/5 到 5/5 | 响应流断开，或者 WebSocket 建连失败 | 抄下完整错误，看后面是否出现回退 HTTPS |
显示 stream disconnected before completion | 流没有走到完整结束 | 看是 WS、SSE，还是代理/防火墙中断 |
| 工具执行后就不动了 | 后台命令没退出、工具结果没回传，或后续响应流断了 | 先看后台终端和进程 |
| CLI 正常，Codex Desktop / VS Code 卡 | 客户端或 app-server 这一层的可能性更高 | 用同一条短提示交叉测试 |
这里最容易误判的是第一种。
OpenAI 官方仓库里有一例 Windows Codex Desktop 的报告：gpt-5.5 配 xhigh reasoning，提交任务后等了 30 分 38 秒才出现第一段输出。报告者自己的历史数据里，xhigh 也更容易出现长尾等待，但他没有把原因直接定成 WebSocket。
所以，只有 Thinking 三个字，证据还不够。
先做一个 30 秒的短会话测试
新建会话，不带旧聊天上下文，发一句：
只回复 READY，不要调用工具。结果大致有三种：
- 几秒内回复：基础链路能用，原来的问题更像长上下文、推理档位或工具任务。
- 仍然
Thinking很久，但没有重连：先把 reasoning 从xhigh降到medium或low再测。 - 立刻开始
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 本身能稳定工作，只是长任务确实超过默认空闲窗口，才考虑调整这些参数。
改完以后怎么验证
不要凭“这次好像快了点”下结论。拿同一台机器、同一个网络、同一个模型和同一句提示，做两轮。
| 记录项 | WS 开启 | WS 关闭、走 SSE |
|---|---|---|
是否出现 Reconnecting... | ||
| 第一段文字出现用了几秒 | ||
| 是否完整结束 | ||
是否出现 stream disconnected before completion | ||
| 中转后台有没有成功请求 |
第一轮还是用：
只回复 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，表面上都像“它没反应”，排法却不一样。
我的判断顺序很简单：
- 先用新短会话排除长上下文和高 reasoning；
- 再分官方登录还是第三方中转；
- 中转完整支持 Responses WebSocket，才试
supports_websockets = true； - 代理或中转带不动 WS，就设为
false，直接走 HTTPS/SSE； - 用同一句短提示记录首包和完整结束，别靠感觉。
最关键的不是 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 首包卡死问题调查和解法