你的Codex一直Reconnecting？附解决方案

适用对象：在 Windows / macOS / Linux 上使用 Codex CLI（或 Codex 桌面应用），本地已运行代理软件（Clash、Clash Verge、Mihomo、v2rayN 等），但不想开启 TUN（虚拟网卡）模式的用户。

一、问题现象

在部分网络或代理环境中，每次启动 Codex 或发起新对话时，终端会连续显示：

Reconnecting... 1/5
Reconnecting... 2/5
Reconnecting... 3/5
Reconnecting... 4/5
Reconnecting... 5/5

等待一段时间后，Codex 要么恢复正常开始回答，要么报出 “request timed out” 之类的错误。典型伴随特征有：

Codex 启动正常，但发送请求后长时间无响应，反复出现 retry / reconnect 提示；
浏览器可以正常访问 ChatGPT / OpenAI 相关网站，唯独命令行工具连不上；
一旦在代理软件里打开 TUN 模式（虚拟网卡/增强模式），问题立刻消失；关掉 TUN 就复发。

需要明确的是：这个现象通常不代表模型不可用、账号异常或 Codex 安装错误，而是实时连接的建立过程出了问题。

二、原因分析：为什么不开 TUN 就会重连？

2.1 Codex 默认走 WebSocket 传输

Codex 支持通过 Responses API 的 WebSocket（WSS） 通道传输响应。当前实现默认最多重连 5 次，单次连接超时约 15 秒。如果 WebSocket 握手失败，Codex 会反复尝试重连，随后才可能回退（fallback）到普通 HTTPS 请求——这就是那 5 次 “Reconnecting” 和明显启动等待的来源。

判断依据很简单：如果 HTTPS 请求能正常访问 OpenAI 服务，但每次对话前都固定出现多次 Reconnecting，应优先怀疑 WebSocket 流量没有走对代理，而不是归因于模型速度或账号状态。

2.2 系统代理 ≠ 全局代理

很多代理客户端默认工作在"系统代理"模式。系统代理只对主动读取系统代理设置的应用生效——浏览器大多能自动识别，所以网页访问看起来一切正常。

但 Codex 运行在终端中，它的网络请求不一定遵循系统代理设置。在 Windows Terminal、PowerShell、VS Code 终端、WSL 以及 Node.js / Rust 网络栈等场景下，"浏览器能走代理、CLI 工具没走代理"是极为常见的情况。普通 HTTPS 请求可能侥幸通过，而 WebSocket 握手却因未走代理而失败，于是进入重连循环。

2.3 为什么 TUN 模式"一开就好"

TUN 模式会在系统网络层创建一张虚拟网卡，从操作系统层面接管（几乎）全部流量，不再依赖单个应用是否正确读取代理配置。因此 Codex 的 WebSocket、HTTPS 请求都会被"兜底"接管，问题自然消失。

但 TUN 的代价是影响面大：可能改变其他桌面软件、局域网/公司内网访问、本地开发服务、虚拟机与容器调试的网络行为，且通常需要管理员权限。如果你只是想让 Codex 走代理，没有必要动用 TUN 这个"重武器"——显式告诉 Codex 代理地址即可，这就是本文要介绍的方案。

2.4 解决思路：用 `.env` 把代理地址直接告诉 Codex

Codex 启动时会读取其用户配置目录下的 .env 文件（Codex 的状态根目录由 CODEX_HOME 决定，默认即 ~/.codex）。只要在其中写入标准的代理环境变量，Codex 的 HTTPS 请求和 WebSocket 握手就都会经由本地代理端口发出，无需开启 TUN。

三、方案对比

方案	原理	优点	缺点	推荐度
配置 `~/.codex/.env` 代理变量（本文方案）	显式指定 HTTP/HTTPS 代理	保留 WebSocket 实时体验；改动小；只影响 Codex	需确认正确的代理端口	★★★★★
自定义 HTTP-only provider	在 `config.toml` 中设 `supports_websockets = false`，禁用 WebSocket	彻底绕开 WSS 问题	放弃 WebSocket 传输；历史会话可能按 provider 重新分组	★★★★
开启 TUN 模式	虚拟网卡接管系统全部流量	全局透明、一劳永逸	需管理员权限；影响面大，可能波及其他软件与内网	★★★（兜底）

建议按 .env 代理变量 → HTTP-only provider → TUN 模式 的顺序排查。下面给出 .env 方案的完整操作教程。

四、详细解决教程（六步安全流程）

整个流程遵循"先只读检测、展示计划、确认后再写入"的安全原则，任何一步发现问题都可以随时中止。

第 1 步：只读检测本地代理端口（关键：别把 SOCKS 当 HTTP）

首先确认本机代理软件实际监听的端口，优先找到 HTTP 代理端口或 Mixed（混合）端口。

方法一：看代理软件的设置界面（最可靠）

Clash for Windows / Clash Verge / Mihomo Party：在"设置 / 端口"或"内核设置"页面查看。Clash 系列常见的 Mixed 混合端口为 7890 或 7897；
v2rayN：在"设置 / 参数设置 / 本地端口"中查看 HTTP 端口与 SOCKS 端口（常见为 10808 附近，不同版本默认值不同，以软件实际显示为准）。

方法二：命令行验证端口监听情况（只读操作，不会改动系统）

Windows（PowerShell / CMD）：

netstat -ano | findstr LISTENING | findstr "7890 7897 10808 10809"

macOS / Linux：

lsof -i -P | grep LISTEN | grep -E "7890|7897|10808|10809"

端口类型辨析（本步骤的核心）：

端口类型	能否直接用于 `.env`	说明
HTTP 代理端口	✅ 可以	标准 HTTP/HTTPS 代理，`HTTP_PROXY` 直接指向它
Mixed 混合端口	✅ 可以	同时接受 HTTP 与 SOCKS 协议，当作 HTTP 端口使用即可
SOCKS5 端口	❌ 不要直接填	`HTTP_PROXY=http://127.0.0.1:SOCKS端口` 是错误的写法，协议不匹配会导致连接失败

如果你只有 SOCKS5 端口可用，正确写法是 ALL_PROXY=socks5://127.0.0.1:端口，但绝大多数情况下代理软件都提供 HTTP 或 Mixed 端口，优先使用它们。

第 2 步：检查 `~/.codex/.env` 是否已存在

目标文件的默认路径为：

Windows：C:\Users\你的用户名\.codex\.env（本文示例用户为 C:\Users\QSY\.codex\.env）
macOS / Linux：/Users/你的用户名/.codex/.env（即 ~/.codex/.env）

Windows（PowerShell）：

Test-Path "$env:USERPROFILE\.codex\.env"

macOS / Linux：

ls -la ~/.codex/.env

第 3 步：确定写入策略

文件不存在：新建 .env 文件；
文件已存在：只修改或追加代理相关变量，保留其余内容。.env 中可能已有 OPENAI_API_KEY 等其他配置，切勿整体覆盖。

第 4 步：写入前展示完整计划（确认环节）

在真正创建或修改文件之前，先核对以下三项信息，确认无误后再动手：

目标文件路径：必须是用户主目录下的 .codex\.env（如 C:\Users\QSY\.codex\.env 或 /Users/QSY/.codex/.env）。
⚠️ 不要写到当前项目目录的 .codex/.env——项目级配置只在受信任的项目内生效，且无法承担全局代理职责，写错位置是常见的无效操作。
检测到的端口类型与端口号：例如"v2rayN，Mixed 混合端口，10808"。
准备写入的完整内容：见第 5 步。若文件已存在，明确列出"保留哪些行、追加/修改哪些行"。

第 5 步：写入代理环境变量

假设检测到的 HTTP/Mixed 端口为 10808，完整写入内容如下：

HTTP_PROXY="http://127.0.0.1:10808"
HTTPS_PROXY="http://127.0.0.1:10808"
http_proxy="http://127.0.0.1:10808"
https_proxy="http://127.0.0.1:10808"
NO_PROXY="localhost,127.0.0.1,::1"
no_proxy="localhost,127.0.0.1,::1"

各变量说明：

HTTP_PROXY / HTTPS_PROXY：指定普通 HTTP 与 HTTPS 请求使用的代理地址。WebSocket（WSS）握手本质上由 HTTPS 连接升级而来，也会经由此代理发出；
大小写各写一份：不同语言/库的 HTTP 客户端读取的变量名习惯不同（有的只认大写、有的只认小写），同时写全可以避免"设了却不生效"的隐性坑；
NO_PROXY：让本机地址（localhost、127.0.0.1、::1）绕过代理，避免影响本地开发服务。

端口请替换为第 1 步检测到的实际值：Clash 常见 7890/7897，v2rayN 常见 10808/10809。再次强调：填 HTTP 或 Mixed 端口，不要填 SOCKS5 端口。

Windows 用户特别注意一个陷阱：用记事本等工具新建文件时，系统可能因"隐藏已知文件类型的扩展名"而把文件保存成 .env.txt。请在资源管理器"查看"中勾选"文件扩展名"，确认文件名确实是 .env。

第 6 步：确认后执行写入，然后重启、验证、学会回滚

（1）完整重启 Codex

已运行的 Codex 进程不会自动重新读取 .env，必须彻底退出后重启：

Windows：任务管理器中结束所有 codex / Codex.exe 相关进程（包括 VS Code 扩展宿主中的），再重新启动；
macOS / Linux：

pkill -f codex

然后重新打开 Codex。

（2）验证是否生效

重新发起一次对话，观察是否还出现连续 5 次 Reconnecting。如果直接开始回答，说明 WebSocket 流量已正确经过代理；
需要进一步确认时，可运行 codex doctor（若当前版本提供）检查 provider 连通性，或在终端中回显变量：

# Windows PowerShell（针对通过终端临时设置的场景）
echo $env:HTTP_PROXY

# macOS / Linux
echo $HTTP_PROXY

（3）如何回滚

本方案的全部改动都集中在一个文件里，回滚非常干净：

打开 ~/.codex/.env；
删除（或用 # 注释掉）本次追加的 6 行代理变量，其余内容保持不动；若整个 .env 都是本次新建的，直接删除该文件即可；
再次完整重启 Codex，即恢复到修改前的状态。

建议在修改已存在的 .env 之前先复制一份备份（如 .env.bak），回滚时直接还原。

五、仍然重连？按这份清单排查

如果完成上述步骤后问题依旧，依次检查：

代理软件是否正在运行，且所选节点可用；
.env 是否位于用户主目录的 .codex 下，而不是项目目录；
Windows 下文件名是否实际为 .env.txt；
端口是否与代理软件设置一致、且确为 HTTP/Mixed 端口而非 SOCKS 端口；
当前代理节点是否允许 WebSocket（WSS）连接——可换一个节点试试；
公司网络、防火墙或安全软件是否拦截了 WSS 握手；
是否在修改后彻底重启了 Codex（后台残留旧进程会导致配置不生效）。

六、备选方案速览

方案 B：禁用 WebSocket（HTTP-only provider）

编辑 ~/.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

保存并完整重启 Codex。该方案从协议层面绕开 WebSocket，重连等待立即消失；代价是放弃 WebSocket 的实时传输体验，且历史会话可能按 provider 重新分组（恢复原配置即可还原）。修改前建议备份 config.toml。

方案 C：Windows 系统环境变量（setx）

如果希望所有终端工具都走代理，可写入用户级环境变量：

setx HTTP_PROXY "http://127.0.0.1:7897"
setx HTTPS_PROXY "http://127.0.0.1:7897"

执行后需关闭并重新打开所有终端 / VS Code 才能生效。注意此方式影响面大于 .env（对所有读取该变量的程序生效），不再需要时可用以下命令清除：

[Environment]::SetEnvironmentVariable("HTTP_PROXY", $null, "User")
[Environment]::SetEnvironmentVariable("HTTPS_PROXY", $null, "User")

方案 D：TUN 模式（最终兜底）

前两招都无效时再开。开启后请检查内网、本地开发服务与其他常用软件是否仍正常，并按代理软件文档配置绕行规则。

七、总结

Codex 反复 Reconnecting 的根源，是 WebSocket 流量没有被代理正确接管：系统代理管不到终端应用，而 Codex 又默认使用 WSS 传输，重试 5 次后才回退。不开 TUN 的最优解是：

只读检测出代理软件的 HTTP / Mixed 端口（不是 SOCKS5 端口）；
在 ~/.codex/.env（Windows 为 C:\Users\<用户名>\.codex\.env）中写入 HTTP_PROXY / HTTPS_PROXY（大小写各一份）与 NO_PROXY；
彻底重启 Codex 并验证；
需要回滚时，删掉这几行变量即可。

整个过程只影响 Codex 一个应用，改动范围小、可逆性强，是此类问题的首选长期方案。

兼容性提示：Codex 当前开源实现会读取 ~/.codex/.env，但官方环境变量文档主要将环境变量描述为进程级配置。若升级 Codex 后该方法失效，请以最新官方文档与当前版本行为为准，或将相同变量配置为系统/启动进程的环境变量（见方案 C）。

参考资料

Codex 一直 Reconnecting，四种解法 — byronfinn.github.io：https://byronfinn.github.io/2026-05-22-codex-websocket-reconnect-fix/
解决 Codex 请求 5 次重连问题 — qingchenjia.github.io：https://qingchenjia.github.io/2026/07/03/解决Codex请求5次重连问题
修复 Codex 代理超时（含 ALL_PROXY 与子进程注意事项）— GitHub: wille614/codex-remote-control-proxy-fix
Codex 不开虚拟网卡也能走本地代理：配置 ~/.codex/.env — CSDN DevPress
OpenAI 官方文档：Codex Environment variables — https://developers.openai.com/codex/environment-variables