Codex 卡在「思考中」没反应：常见原因与排查方案
用 Codex 跑任务时长时间停在思考中，或执行命令中途挂住，中止重试后短暂恢复又复现。这类问题多数不在模型，而在传输方式、跨境线路和中间代理配置。本文拆解 HTTP 流式与 WebSocket 的差异、代理超时与缓冲的影响，并给出一套按层定位的排查清单与取舍建议。
用 Codex 跑任务，最影响节奏的往往不是报错，而是「没有反应」：界面一直显示思考中，或者在执行命令那一步停住，既没有输出也没有失败提示。有人以为是偶发，结果隔一阵复现一次，中止再继续能撑一会儿，很快又卡住。
从反馈看这不是个例，且集中出现在把 Codex 接入第三方客户端、或经过代理与中转链路访问的场景。同一时间换一个接入点就正常、换一条网络线路就明显变慢，说明大部分问题不在「模型想不出来」，而在请求发出去之后的那段链路。
卡死的典型表现
- 提交任务后长期停留在思考状态，迟迟没有首个 token 输出
- 已经开始执行命令，中途输出中断，进程像挂住一样
- 中止后重发同一请求，短期恢复，过一会儿再次复现
- 换一个网络环境（例如绕开代理）明显好转
区分一点很关键：是「完全没有响应」，还是「输出很慢但还在动」。前者偏向连接被切断或超时策略不匹配，后者更可能是线路质量与节点拥塞。
常见原因
传输方式：长连接通常比短连接更稳
Codex 服务的接入有 HTTP 流式和 WebSocket 两条路径。流式 HTTP 在经过代理、CDN 或网关时，容易被缓冲、被空闲超时切断，表现出来的就是「卡在思考中」。WebSocket 建立一次长连接，中间层不容易插手中断，稳定性一般更好，较新的客户端已有默认走长连接的行为。如果你的客户端支持切换，这是值得优先尝试的一项。
反过来，部分企业网络或代理会直接拦掉 WebSocket 升级请求，这时只能回退到 HTTP，那就得靠超时与缓冲配置来兜底。
线路与地区差异
同样的客户端，在公司网络正常、回家挂上代理就变得很慢，是很常见的反馈。跨境链路抖动、代理节点拥塞、DNS 解析到较远的入口，都会放大首字延迟。判断方法很直接：换一条出口线路跑同样的任务，对比首字延迟和卡死频率。
中间层：Cloudflare、Nginx 一类反向代理
如果请求链路里有自建反向代理或 CDN，默认配置往往对长连接不友好：
| 配置项 | 常见问题 | 调整方向 |
|---|---|---|
| 读超时 | 默认值偏短，静默期被切断 | 适当放大读超时 |
| 响应缓冲 | 缓冲导致流式输出攒着不发 | 对流式接口关闭缓冲 |
| 升级头 | 未透传 Upgrade / Connection | 显式允许协议升级 |
| 空闲回收 | 长时间无数据被清理 | 延长时限或加心跳保活 |
| 压缩 | 对流式响应压缩引入延迟 | 对流式响应关闭压缩 |
有人按这几项调整后，卡死频率大幅下降但没完全消失——这说明它只是压低了触发概率，链路本身的抖动依然存在。
客户端版本与超时处理
新版本客户端通常在超时、重连、流式解析上做过修补，升级往往比改配置见效快。同时要区分「服务端没回」和「客户端没渲染」：看调试日志，如果日志里已有数据流进来，问题就在前端解析环节。
排查清单
按顺序走，能较快定位到具体层：
- 记录一次卡死的完整时间点，检查客户端日志在卡住前后有无连接关闭、超时、重连记录。
- 换网络对比：同一任务分别在有线网络、手机热点、不同代理节点下各跑一次，记录首字延迟。
- 换接入方式：客户端支持长连接与 HTTP 切换时，两种都试，观察差异。
- 把客户端升级到最新版本后复测。
- 检查链路中的代理与网关，重点看读超时、缓冲、协议升级、压缩四项。
- 用简单的 curl 直接请求流式接口做对照：能稳定收到分块数据说明链路正常，问题在客户端侧。
- 若只有某一个接入点异常、换另一条线路即正常，问题基本可锁定在该接入点。
各种做法的取舍
- 切换长连接：对长任务最有效，但需要客户端支持，且部分网络会拦截升级请求。
- 调整代理超时与缓冲：成本低、见效快，但只能降低概率，无法根治线路抖动。
- 升级客户端：几乎无副作用，建议先做。
- 更换出口线路：能缓解地区相关的延迟，效果取决于你手上线路的质量。
- 使用第三方中转或共享接入：这类服务存在凭据泄露、数据被记录、随时中断以及违反服务条款的风险，不建议把包含敏感代码或密钥的任务交给它，优先使用官方支持的接入方式与自己的凭据。
需要自行确认的地方
具体卡在哪个环节因环境而异，上面的方向都需要结合日志验证。至于服务端是否已修复、客户端默认传输方式是否变更，这类信息以官方发布说明和客户端的实际行为为准，不要照搬旧结论。
如果任务本身需要长时间挂着跑，本地机器休眠、断网、代理重连都会直接打断会话。这种情况可以考虑把执行环境放到一台长期在线的机器上，例如境外机房的一台独享 Mac，远程连接过去使用，出口网络固定，也不必担心本地设备睡眠导致任务中断。
小结
Codex 卡在思考中，多数时候不是模型的问题，而是请求在链路上被缓冲、被超时切断，或者走了不合适的传输方式。建议的排查顺序是：先看日志分清是「没回」还是「很慢」→ 换线路与接入方式做对比 → 升级客户端 → 再动代理配置。把长连接、超时、缓冲这三件事处理好，大部分卡死会明显缓解，剩余的概率性抖动则属于线路本身的特性。
