一招教你修复 Codex 客户端总是重新连接 Reconnecting的解决办法SEO关键词Codex Reconnecting、Codex重连5次、Codex WebSocket、Codex Responses API、Codex配置教程、supports_websockets、Codex HTTPS Streaming、Codex连接失败解决方法、OpenAI Codex教程、Codex源码分析Codex客户端下载如果你还没有安装 OpenAI Codex 客户端可以前往软件下载地址Codex客户端https://codexdown.cc/前言你的 Codex 在回答之前有没有出现过这样的情况Reconnecting... Reconnecting... (2/5) Reconnecting... (3/5) Reconnecting... (4/5) Reconnecting... (5/5)有时候明明最后还是能够正常回答但每次开启新对话都要先重连几次等待十几秒甚至几十秒非常影响使用体验。很多人第一反应是OpenAI 服务器太忙网络不稳定模型响应太慢API 出问题实际上很多情况下都不是。这个问题的根源往往是Codex 新版本优先启用了 WebSocket 连接而你的网络环境无法稳定建立 WebSocket 通道。这篇文章带大家从源码层面分析问题并给出实测有效的解决方案。一、先搞清楚 Codex 的请求链路当你在 Codex 输入一句话时用户 ↓ Codex Client ↓ Responses API ↓ OpenAI Backend ↓ 模型返回结果但这里有一个很多人不知道的细节同样都是 Responses API底层其实有两种传输方式。方式一HTTPS Streaming也就是传统的 HTTP POST SSE。流程大概是客户端 ↓ POST 服务器 服务器 ↓ SSE 持续返回内容这种方式也是目前Claude CodeCherry StudioOpen WebUI大部分 AI 客户端最常用的方案。方式二WebSocket2026 年 OpenAI 在 Responses API 中加入了 WebSocket 支持。简单理解建立一次连接 客户端 ←→ 服务器 持续交换数据相比 HTTPS延迟更低不需要频繁建立连接更适合 Agent 场景更适合长时间持续交互OpenAI 官方工程文章也专门介绍过这个方案Speeding up agentic workflows with WebSockets in the Responses API二、为什么会出现 Reconnecting问题就出在这里。很多软件或者网络环境HTTPS 正常 ≠ WebSocket 正常例如企业网络校园网某些机场节点都可能出现HTTPS 能访问 wss:// 建立失败于是 Codex 每次启动对话都会尝试 WebSocket ↓ 连接失败 ↓ 重试 ↓ 重试 ↓ 重试 ↓ 重试 ↓ 放弃 ↓ 切换 HTTPS ↓ 正常回答于是你就看到了Reconnecting... Reconnecting... Reconnecting...最后居然还能正常使用。因为最终已经回退到了 HTTPS。三、Codex 源码是怎么实现的关键逻辑在client.rs中的stream()函数。逻辑大致如下ifwire_apiResponses{ifresponses_websocket_enabled(){使用WebSocket}else{使用HTTPSStreaming}}也就是说第一层判断wire_api是否为responses如果是则继续判断responses_websocket_enabled()四、WebSocket 是否启用由谁决定继续跟进去responses_websocket_enabled()会发现里面最关键的判断supports_websockets简化后逻辑如下ifsupports_websocketsfalse{returnfalse;}另外还有一个条件session.disabled_websocket如果前面已经连续失败过disabled_websockettrue那么后续也会直接禁用。所以实际上控制权就在supports_websockets这个配置项上。五、解决方案直接禁用 WebSocket既然问题已经定位到了WebSocket 建立失败那么解决方案就非常简单不要让 Codex 尝试 WebSocket。直接强制走 HTTPS Streaming。修改 Codex 配置打开~/.codex/config.toml加入下面配置model_provider openai_http [model_providers.openai_http] name OpenAI HTTP wire_api responses requires_openai_auth true supports_websockets false配置说明wire_apiwire_api responses表示继续使用 Responses API不会影响模型能力。supports_websocketssupports_websockets false这是关键。它会让responses_websocket_enabled()直接返回false然后进入HTTPS Streaming分支。从而彻底跳过WebSocket ↓ 连接失败 ↓ Reconnecting这一整套流程。六、用户还需要配置 .env如果你本身需要访问 OpenAI。建议在~/.codex/.env中加入ALL_PROXYhttp://127.0.0.1:7890Linux / macOS 可直接执行echoALL_PROXYhttp://127.0.0.1:7890~/.codex/.env根据自己的端口修改即可例如7890 10809 20171等等。七、为什么我更喜欢 HTTPS 模式我自己长期研究 Codex 工作原理因此更倾向于 HTTPS。主要有两个原因。原因一更容易分析请求HTTPS 模式下每次请求 ↓ 完整上下文 ↓ 发送给服务器因此可以很方便观察Prompt 变化Context 变化Tool Call 内容Token 使用情况原因二兼容性更好目前国内大模型厂商适配情况大多是Chat Completions API部分支持Responses API但支持Responses API WebSocket的其实并不多。因此对于DeepSeekQwenGLMKimiSiliconFlow等生态来说HTTPS 依然是最通用、最稳定的方案。八、实测效果修改配置前Reconnecting... Reconnecting... Reconnecting... Reconnecting... Reconnecting...等待十几秒后才开始回答。修改配置后用户发送消息 ↓ 直接进入 Responses API ↓ 立即返回内容基本不再出现Reconnecting的问题。九、总结如果你的 Codex 经常出现Reconnecting...并且连续重连 5 次后又能正常工作那么问题大概率不是模型慢也不是服务器忙而是WebSocket 连接失败最简单的解决办法1. 禁用 WebSocketsupports_websockets false2. 保持 Responses APIwire_api responses3. 配置ALL_PROXYhttp://127.0.0.1:7890这样 Codex 会直接使用 HTTPS Streaming不再反复尝试建立 WebSocket 连接从而彻底解决启动对话时频繁出现的 Reconnecting 问题。