1. Codex 卡在 Reconnecting 5/5 到底卡在哪
Codex 客户端反复卡在 Reconnecting 5/5，指的是新建会话或执行/new之后，界面不断刷出Reconnecting... 1/5到5/5，重连次数耗尽后才开始正常回复，或者干脆回退到 HTTP Streaming 才把请求发出去。这个现象最烦的地方在于它不是每次都报错，而是"偶发但高频"——你开十个会话，可能有三四个要等一轮重连，时间就这么被磨掉了。
它适合谁看？适合每天用 Codex 跑编码任务、Agent 长流程、批量改代码的开发者，尤其是那种一天要开十几轮新会话的人。因为每次新会话都要重新握手，握手阶段一旦走 WebSocket 失败，就会触发这套重连计数。
我实测下来，绝大多数 Reconnecting 5/5 都不是 Codex 服务端挂了，而是本地环境的问题：要么是config.toml里supports_websockets和当前网络环境不匹配，要么是会话上下文太重导致首次握手 payload 过大，要么是本地插件启动慢把握手拖超时了。所以排查顺序应该是"先清量、再查会话、最后动配置"，而不是一上来就改config.toml。
下面这套流程是我自己踩过坑之后整理出来的，从config.toml骨架讲到 WebSocket 与 HTTP Streaming 的取舍，每一步都有可复制的配置和验证动作，你可以直接跟着做。
2. 动手前先把 TaoToken 的接入信息准备好
Codex 这类客户端要正常跑起来，底层得有一个稳定的模型接入端点。我这边习惯用 TaoToken 来做统一接入，原因是它的接口兼容 OpenAI 的 responses 风格，config.toml里改base_url就能接上，不用大改客户端逻辑。
你需要准备的东西不多：一个可用的 API Key，以及对应的接入地址。API 地址是https://taotoken.net/api，注意这个地址后面不要加多余的路径，Codex 的wire_api = "responses"会自己拼/responses。官网在https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=，注册和看文档都在那边。
Key 的获取入口在控制台的 API Keys 页面，直接生成一个就行。如果你后面要长期跑编码任务、Agent 流程，建议顺手看一下 Coding Plan，它更适合高频调用场景；只是临时验证模型通不通，用模型对话页面点几下就能确认。
注意：Key 只显示一次，生成后立刻复制到本地安全位置，别贴在会提交到 Git 的文件里。
拿到 Key 之后，先别急着改 Codex 的配置，先用一条 curl 确认这个端点本身是通的。这一步能帮你把"端点问题"和"Codex 客户端问题"分开，后面排查会省很多事。
3. 可复制的 config.toml 骨架与 WebSocket 参数
Codex 的配置文件在不同系统下路径不一样，Windows 一般在用户目录下的.codex文件夹，macOS 和 Linux 在~/.codex/config.toml。改之前先备份，这是铁律：
cp ~/.codex/config.toml ~/.codex/config.toml.bak下面是一份可以直接用的骨架，重点是model_provider的名字必须和下面[model_providers.xxx]的块名完全一致，这是最常见的配错点：
# 顶层指定使用哪个 provider，名字要和下面的块名一致 model_provider = "taotoken" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" wire_api = "responses" requires_openai_auth = true # 关键开关：网络环境不支持 WebSocket 时设为 false，强制走 HTTP Streaming supports_websockets = false这里有几个参数值得单独说。wire_api = "responses"表示走 responses 风格的接口，和 TaoToken 的接入方式匹配。requires_openai_auth = true表示需要带认证头，Key 会通过环境变量或客户端登录态注入。supports_websockets是这次排查的核心开关——设为true时客户端会优先尝试 WebSocket 长连接，设为false时直接走 HTTP + SSE 流式传输。
为什么这个开关这么关键？因为 WebSocket 在不少网络环境里会被拦：企业网络的策略限制、校园网出口、某些代理工具不支持 WebSocket 转发、本地 DNS 或 TLS 配置异常，都会让 WebSocket 握手失败。握手一失败，客户端就进入重连计数，于是你看到的就是 1/5 到 5/5。
如果你确认自己的网络环境干净、直连没问题，可以试着把supports_websockets设回true，观察首次请求是否还重连。两种模式的差异可以对照看：
| 模式 | 协议 | 特点 | 适用场景 |
|---|---|---|---|
| WebSocket | 长连接 | 减少重复握手开销 | 网络干净、Agent 长流程 |
| HTTP Streaming | HTTP + SSE | 兼容性好，穿透力强 | 企业网、代理环境、不稳定网络 |
注意：不同 Codex 版本对字段的支持可能有差异，如果某个字段报"未知配置项"，以你本地客户端实际支持的字段为准，删掉不认识的即可。
改完配置后必须完全退出客户端再重启，只关窗口不算退出。Windows 在任务栏图标右键退出，macOS 用 Cmd + Q，Linux 确认进程结束。这一步不做，配置不生效，你会以为改了没用。
4. 分步验证：从 curl 到 Codex 最小会话
配置改完，先别在 Codex 里直接跑大任务，按下面顺序验证，每一步都能定位到不同层的问题。
第一步，用 curl 确认端点通不通。把$TAOTOKEN_KEY换成你自己的 Key：
curl -sS https://taotoken.net/api/responses \ -H "Authorization: Bearer $TAOTOKEN_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-4o-mini", "input": "ping" }'如果这条命令能返回正常的 JSON 结构，说明端点和 Key 都没问题，问题在 Codex 客户端侧。如果这条就失败，先解决 Key 或网络问题，别往下走。
第二步，在 Codex 里新开一个极简会话，只发一句hello。观察两点：是否还出现 1/5 到 5/5，首次响应是否立刻返回。如果极简会话正常，说明客户端进程和配置没问题，之前卡的是会话上下文太重。
第三步，切到一个空目录再启动 Codex，比如~/Desktop/empty-test。如果空目录下正常、原项目下卡，那就是项目目录太重，扫描和索引拖慢了握手。
第四步，如果前三步都正常，回到真实项目，但把任务拆小。一个会话只做一件事，别又写代码又改文档又跑测试。阶段性用/clear或直接开新会话，避免单次请求 payload 过大。
验证成功的标志很明确：新会话不再刷 Reconnecting 计数，首次请求立即响应，也不再出现回退到 HTTP Streaming 的提示。如果开了开发者工具，可以在网络面板里看请求类型——wss://是 WebSocket，text/event-stream是 HTTP SSE，对照你配置里的supports_websockets值就能确认走的是哪条路。
5. 本篇常见错排查
错误一：model_provider名字和块名不一致。顶层写model_provider = "taotoken"，下面却写成[model_providers.openai]，客户端找不到对应 provider，握手直接失败。改的时候两个名字必须逐字一致。
错误二：引号用了中文全角。从网页复制配置时经常带进全角引号"…"，TOML 解析直接报错。全部换成英文半角"。
错误三：改了配置没完全重启。只关窗口，进程还在后台跑，读的还是旧配置。必须完全退出再启动。
错误四：supports_websockets和网络环境不匹配。网络不支持 WebSocket 却设成true，每次新会话都重连。反过来，网络干净却设成false，虽然能用但少了长连接优化。按实际环境选。
错误五：会话上下文太长。单个会话滚动几十屏、工具调用结果堆了一堆没清理，首次请求 payload 巨大，握手成本高。判断标准是出现"上下文已超出"类提示之前，就该拆会话了。
错误六：本地插件或 MCP 启动慢。Codex 启动时加载本地插件，某个插件卡住会拖慢整个握手。处理办法是关掉所有非必要插件，重启验证，再逐个启用，每启一个发一次最小请求，找到那个"卡"的。
错误七：项目目录太重。node_modules、dist、build、日志文件全在扫描范围里。清理无关文件，配好.gitignore，把大文件挪出项目目录。
错误八：登录态异常。如果用了带 MFA 的登录体系，旧 session 失效会导致连接建立后立刻被断开，客户端表现为重连。彻底退出后重新登录，走完整验证流程。
错误九：客户端版本过旧。旧版本可能和新协议不完全兼容。检查更新提示，升级后重启，再用最小会话验证。
错误十：电脑资源占用过高。CPU、内存、磁盘被 IDE、浏览器、虚拟机占满，Codex 也被拖累。关掉不必要的软件，必要时冷启动一次。
排查顺序建议按"先低成本后高成本"来：先做重启客户端、新开极简线程、换空项目这三步清量动作，能排除一半的假故障；再查会话上下文和工具输出；然后是登录态、插件、项目目录、系统资源；最后才动config.toml和传输层。别一上来就改配置，那样容易把本来没问题的配置改坏。
6. 接入与排障的下一步
如果你走完上面流程，Reconnecting 5/5 还在，优先检查三件事：Key 是否有效、base_url是否写成了https://taotoken.net/api（不要多加路径）、supports_websockets是否和你的网络环境匹配。这三项确认完，九成问题能定位。
需要重新生成或核对 Key，去控制台的 API Keys 页面：https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite。接入细节和字段说明看文档：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite。只是想快速确认模型通不通，用模型对话页面发一句话就行：https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite。如果你是要长期跑编码任务、Agent 流程，Coding Plan 更适合高频场景：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite。
最后留一个我自己的习惯：每次改完config.toml，先跑一遍 curl，再开一个空目录的极简会话，两步都过了再回到真实项目。这样即使出问题，也能立刻知道是配置层还是项目层，不用在一堆变量里瞎猜。
