Codex 一直 Reconnecting，四种解法

Codex 默认走 WebSocket 跟 ChatGPT backend 通信。如果你的网络中间有 Clash、公司代理、跨境线路或者 Cloudflare 的 challenge 页，WebSocket 长连接很容易被打断，然后你就会反复看到 Reconnecting... 1/5。关掉 WebSocket，改走普通 HTTP 流式请求，这个问题基本消失。

为什么 WebSocket 在代理环境下容易断

WebSocket 协议需要先发一个 HTTP Upgrade 请求，服务端返回 101 之后才切换到长连接。问题出在这个长连接上——代理服务器、防火墙、CDN 节点都对空闲长连接有超时策略，Cloudflare 的 challenge 机制也可能在中间插入拦截页面。任何一环把连接掐了，Codex 客户端就开始 Reconnecting。

HTTP 流式（SSE / chunked response）不存在这个问题，因为每次请求是独立的，不需要维持一条持续的双向通道。

方案一：目录级 env 代理

最快见效的方式。在项目目录下创建 .env 文件：

all_proxy=http://127.0.0.1:7890

把 7890 换成你代理客户端的端口。Codex 启动时会读取这个环境变量，所有请求走你指定的代理。

优点：30 秒见效，不需要改配置文件。 缺点：只对当前目录生效，换项目要重新配。

适合临时验证是不是代理导致的问题。

方案二：config.toml 关掉 WebSocket

编辑 ~/.codex/config.toml，在对应的 provider 配置下加一行：

[provider]
supports_websockets = false

这个配置告诉 Codex 不要尝试 WebSocket 升级，直接用 HTTP 流式。

优点：配置一次全局生效，不用每次启动带参数。 缺点：首 token 和中途事件更新可能略慢一点点，体感差异不大。

这是最推荐的方案，改动最小，效果稳定。

方案三：代理客户端开 TUN 模式

如果你的代理客户端支持 TUN（Clash Premium、mihomo 等），直接开 TUN 模式：

# clash config
tun:
  enable: true
  stack: system

TUN 模式在系统网络层接管所有流量，Codex 的请求会自动走代理，不需要任何应用层配置。

优点：全局透明代理，所有应用都受益，不只是 Codex。 缺点：需要管理员权限，部分代理客户端不支持，可能影响其他网络应用。

适合已经有 TUN 使用习惯的人。

方案四：自定义 HTTP Provider

最彻底的方案，直接定义一个新的 provider 走纯 HTTP。编辑 ~/.codex/config.toml：

model_provider = "chatgpt_http"

[model_providers.chatgpt_http]
name = "ChatGPT HTTP"
base_url = "https://chatgpt.com/backend-api/codex"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

这个配置创建了一个 chatgpt_http provider，指向 ChatGPT 的 backend API，使用 Responses API 协议，显式关闭 WebSocket。

优点：从协议层面彻底避开 WebSocket，模型能力完全不变（还是 gpt-5.5，还是 Responses API）。 缺点：这是自定义 provider，如果 Codex 后续改了 ChatGPT backend 的路径或 provider 字段定义，可能需要跟着调整。

适合方案二不够用、或者经常断连影响工作的场景。

怎么选

网络本来很稳——不用改，保留 WebSocket 的实时体验。

偶尔断连——方案二，supports_websockets = false，一行配置搞定。

经常 Reconnecting——方案四自定义 provider，或者方案三 TUN 模式，二选一看你的代理客户端能力。

只想试试——方案一 env 代理，30 秒验证问题是不是代理导致的。

相关文章

• https://byronfinn.github.io/2026-05-17-codex-ssh-remote-guide/：Codex SSH 远程开发配置