Codex 一直重连怎么解决？三种方法彻底搞定 WebSocket 代理问题

27 5月 2026
9 分钟阅读
标签:
Codex,
WebSocket,
代理配置,
Clash TUN,
网络问题

我在用 Codex 做一个动画生成项目的时候，第一次发消息就卡住了——屏幕上出现一串 "Reconnecting..." 的提示，转了五圈之后才终于连上。当时以为是偶发问题，结果每次打开都这样。

这个问题在国内用 Codex 的用户里极其普遍。几乎每个人第一次遇到都以为是自己的梯子出了问题，然后开始换节点、重启软件、重装应用，折腾一圈发现没用。

原因其实很简单，但藏得很深。

为什么会重连5次？

Codex 默认使用 WebSocket 协议建立连接。WebSocket 是一种持久化的双向通信协议，比普通 HTTP 请求更高效，适合 AI 这种需要流式输出的场景。OpenAI 在 2026 年 4 月专门发布了一篇工程博客，解释了为什么在 Responses API 中引入 WebSocket 来加速 Codex 这类 Agent 工作流——延迟更低、连接更稳定。

问题在于：WebSocket 不走系统代理。

大多数科学上网工具（Clash、Surge 等）默认只代理 HTTP/HTTPS 流量。当你开着代理但没有特别配置时，Codex 发出的 WebSocket 请求会绕过代理直接出去，在国内网络环境下自然连不上 OpenAI 的服务器。

Codex 的处理逻辑是：先尝试 WebSocket 连接，失败一次就重试，连续失败5次之后，自动降级到 HTTP 长轮询模式。这个行为在 GitHub openai/codex #13103 中有完整的错误日志记录：

Reconnecting... 2/5 (stream disconnected before completion: failed to send websocket request: Connection closed normally)
Reconnecting... 3/5 ...
Reconnecting... 4/5 ...
Reconnecting... 5/5 ...
Falling back from WebSockets to HTTPS transport.

降级到 HTTP 之后能用，但速度明显变慢，而且每次打开都要经历这5次等待，大约浪费1分钟。

三种解决方案

方案一：开启 TUN 模式（推荐，一劳永逸）

TUN 模式会在系统层面创建一个虚拟网卡，接管所有流量，包括 WebSocket。开启之后，Codex 的连接请求会和普通 HTTP 流量一样走代理，不再需要任何额外配置。

Clash Verge / Clash Meta：

打开客户端 → 设置 → 找到 TUN Mode → 开启
部分版本需要同时开启"系统代理"和"TUN 模式"

Surge：

增强模式（Enhanced Mode）等同于 TUN，直接开启即可

开启后重启 Codex，连接会直接成功，不再出现重连提示。

这是最干净的方案，不需要改 Codex 的任何配置文件。唯一的前提是你的代理工具支持 TUN 模式，以及节点质量足够稳定——TUN 模式下所有流量都走代理，节点如果本身不稳定，问题会更明显。

方案二：强制 Codex 走 HTTP 模式（配置文件）

如果不想开 TUN，可以直接告诉 Codex 不要用 WebSocket，永远走 HTTP。这个方案来自 GitHub Issue #13041 的社区解决方案，已有多人验证有效。

在 ~/.codex/config.toml 文件里加入以下配置（文件不存在则新建）：

model_provider = "openai_http"

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

保存后重启 Codex 即可生效。

这样 Codex 启动时就不会尝试 WebSocket 连接，直接用 HTTP，也就不存在重连5次的问题。

代价是：HTTP 模式的响应速度比 WebSocket 慢一些，在处理长任务时感受更明显。如果你主要用 Codex 做短任务或者对速度不敏感，这个方案完全够用。另外需要注意，这个配置使用的是 ChatGPT 后端 API 端点，部分高级功能可能与官方默认 provider 存在差异。

方案三：通过启动脚本注入代理变量

Codex 目前尚未原生支持读取 HTTP_PROXY 等系统环境变量（这是一个仍在讨论中的 Feature Request），但可以通过在启动脚本里手动注入来绕过这个限制。

在你的 shell 配置文件（~/.zshrc 或 ~/.bashrc）里加一个别名：

alias codex='HTTP_PROXY=http://127.0.0.1:7890 HTTPS_PROXY=http://127.0.0.1:7890 codex'

端口号换成你代理工具实际监听的端口（Clash 默认是 7890，Surge 默认是 6152，在代理工具的设置里查）。

执行 source ~/.zshrc 使配置生效，之后每次用 codex 命令启动时都会自动带上代理变量。

这个方案的好处是不影响其他软件，代理只作用于 Codex 进程本身。缺点是桌面版 Codex（非 CLI）不走这个别名，只对命令行版本有效。

让 Codex 自己修

有一个我觉得挺有意思的操作：直接把这个问题描述给 Codex，让它帮你配置。

在连上之后（哪怕是等了5次重连之后），告诉它：

"我每次启动都会重连5次，原因是 WebSocket 不走代理。请帮我修改 ~/.codex/config.toml，强制使用 HTTP 模式。"

Codex 会自己找到配置文件路径，写入正确的配置，然后告诉你重启生效。这个方式对不熟悉命令行的用户来说反而最简单——它知道自己的配置文件在哪，比你手动找要快。

哪个方案适合你？

情况	推荐方案
用 Clash / Surge，不介意全局代理	方案一（TUN 模式）
不想影响其他软件，主要用 CLI	方案三（启动脚本）
懒得折腾，速度要求不高	方案二（强制 HTTP）
不熟悉命令行	让 Codex 自己配
用软路由（OpenWrt + mihomo）	基本不会遇到这个问题

软路由用户之所以不受影响，是因为流量在路由器层面就已经被接管，所有设备上的所有协议都走代理，WebSocket 自然也不例外。如果你有条件折腾软路由，这是最彻底的解法，但成本明显更高。

一个值得注意的细节

有人担心：配置了代理之后，OpenAI 会不会检测到你在用代理，然后封号？

这个担心基本上是多余的。OpenAI 检测的是 IP 地址的地理位置和风险评分，而不是你是否使用了代理协议本身。用代理访问 OpenAI 是全球绝大多数用户的常规操作，包括很多美国用户也在用 VPN。

真正有风险的是：使用被大量标记的数据中心 IP（便宜机场的共享节点），或者账号行为异常（短时间内从多个地区登录）。节点质量比"是否用代理"更重要。

最后

重连5次这个问题，本质上是 Codex 的网络层设计和国内代理工具的默认配置之间的不匹配，不是 Codex 的 bug，也不是你的梯子坏了。理解了 WebSocket 不走系统代理这个根本原因，三个方案选一个，五分钟之内可以彻底解决。