> ## Content Index
> Fetch the complete content index at: https://tbbbk.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Codex 一直卡在 Thinking / Reconnecting？WebSocket 与 SSE 排错教程
- URL: https://tbbbk.com/codex-thinking-reconnecting-websocket-sse-troubleshooting/
- Published: 2026-07-23T07:30:16.000Z
- Updated: 2026-07-23T07:30:16.000Z
- Description: Codex 卡在 Thinking，或反复显示 Reconnecting... 1/5，不一定是同一个问题。本文按官方配置与真实 Issue 拆开排查：先分清症状和入口，再根据中转能力决定启用 WebSocket，还是直接走 HTTPS/SSE。
- Author: TuBaiBai
- Tags: AI 编程工具, Codex, OpenAI, 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 秒的短会话测试

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

```text
只回复 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` 里配了 `model*provider* *、base*url`，或者请求本来就经过 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 官方文档明确列了限制：项目级配置不能覆盖 `model*provider* *、model*providers` 和 `openai*base*url` 这类会改变认证或服务地址的键。

CLI 里可以输入：

```text
/debug-config
```

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

```text
/status
```

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

新版 CLI 还可以先跑：

```bash
codex doctor --summary
```

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

```bash
codex doctor --json
```

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

## 情况一：中转明确支持 WebSocket

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

```toml
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：

```bash
export OPENAI_API_KEY="你的 Key"
```

Windows PowerShell：

```powershell
$env:OPENAI_API_KEY = "你的 Key"
```

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

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

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

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

另一类情况刚好相反。

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

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

```toml
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。官方文档不允许你用 `[model*providers.openai]* *重新定义它。relay*sse`、`my_proxy` 这种自定义名字才行。

官方仓库还有一个 [Issue #13041](https://github.com/openai/codex/issues/13041)：WebSocket 看起来已经连接成功，随后服务端却用 `1008 Policy` 关闭连接，客户端进入重连再回退 HTTPS。

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

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

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

```toml
stream_max_retries = 5
stream_idle_timeout_ms = 300000
```

官方给出的含义是：

- `stream*max*retries`：SSE 流中断后的重试次数，默认 5；
- `stream*idle*timeout_ms`：SSE 流空闲超时，默认 300000 毫秒，也就是 5 分钟。

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

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

## 改完以后怎么验证

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

| 记录项                                        | WS 开启 | WS 关闭、走 SSE |
| ------------------------------------------ | ----- | ----------- |
| 是否出现 Reconnecting...                       |       |             |
| 第一段文字出现用了几秒                                |       |             |
| 是否完整结束                                     |       |             |
| 是否出现 stream disconnected before completion |       |             |
| 中转后台有没有成功请求                                |       |             |

第一轮还是用：

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

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

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

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

### 1\. reasoning 太高

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

### 2\. 会话太长

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

### 3\. 后台工具没退出

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

```text
/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](https://developers.openai.com/codex/config-reference/)
- [OpenAI Codex Advanced Configuration](https://developers.openai.com/codex/config-advanced/)
- [OpenAI Codex Developer Commands](https://learn.chatgpt.com/docs/developer-commands?surface=cli)
- [openai/codex Issue #19821：WS 建连失败后才回退 HTTP](https://github.com/openai/codex/issues/19821)
- [openai/codex Issue #13041：WebSocket 收到 1008 Policy](https://github.com/openai/codex/issues/13041)
- [openai/codex Issue #23665：WS 临时失败后的回退行为](https://github.com/openai/codex/issues/23665)
- [openai/codex Issue #24260：Desktop 长时间 Thinking](https://github.com/openai/codex/issues/24260)
- [LinuxDo：codex 首包卡死问题调查和解法](https://linux.do/t/topic/2585447)

## 相关阅读

[OpenAI Codex CLI 完整教程：安装、订阅、额度和国内使用避坑2026 最新 OpenAI Codex CLI 完整教程：从安装登录、ChatGPT Plus/Pro 订阅额度、模型选择，到国内网络、代理、Windows/WSL2 和 API Key 避坑一次讲清。![](https://tbbbk.com/favicon.ico)TuBaiBai's BlogTuBaiBai](https://tbbbk.com/openai-codex-cli-install-subscription-usage-china-guide-2026/)

[Claude Code 接第三方 / 中转 Key：环境变量怎么配，401 和模型名怎么排查Claude Code 要用中转或自建网关的 Key，得改 ANTHROPIC\_BASE\_URL 和鉴权变量。按官方支持的接法写配置步骤，以及 401、路径不对、模型名对不上、流式卡死时怎么查。![](https://tbbbk.com/favicon.ico)TuBaiBai's BlogTuBaiBai](https://tbbbk.com/claude-code-third-party-api-key-relay-guide-2026/)