目录
  1. 一、 第一层：Codex 根本没有走上本机的代理端口
  2. 1. 查找本机真实的代理监听端口
  3. 2. 在 Codex 配置文件中注入代理参数
  4. 二、 第二层：配置后仍报 TLS unexpected-eof？将代理升级为 SOCKS5H
  5. 解决方案：使用 SOCKS5H 协议接管并开启远端 DNS 解析
  6. 三、 终极保底：开启代理软件的 TUN 虚拟网卡模式

Codex 持续 Reconnecting 怎么解决？从本地代理、SOCKS5H 到 TUN 模式彻底搞定 TLS 断流

日常在做 VibeCoding 时，很多开发者最抓狂的场景莫过于：正让 Codex 进行多文件重构或生成复杂模块，界面顶部或右下角突然开始疯狂弹出 Reconnecting...，终端甚至直接抛出底层断流报错：

stream disconnected before completion:
IO error: peer closed connection without sending TLS close_notify

Codex 持续 Reconnecting 与 TLS unexpected-eof 报错实录

很多人的第一反应通常是：“是不是节点崩了？赶紧换个节点试试。”但往往切了一圈节点，发现 Codex 依旧频繁断连、掉线、重新连接。

其实，这种频繁重连的根因极少是节点本身瘫痪，90% 以上都出在本地代理端口绑定与 TLS 长连接握手策略上。根据我的实测排错经验，问题通常分为两层，顺着排查，不用换节点就能彻底解决。

一、 第一层：Codex 根本没有走上本机的代理端口

Codex 在国内网络环境下调用云端模型 API 时，必须依赖本机的本地代理。如果你只是打开了梯子/代理客户端，但没有给 Codex 配置正确的环境变量，客户端可能在不断尝试直连，最终触发连接超时重连。

1. 查找本机真实的代理监听端口

切忌主观臆测代理端口（比如盲目假设端口一定是 7890）。代理客户端（Clash、Mihomo、Surge、v2ray 等）在不同系统或版本上的 mixed-port 可能完全不同。

Windows 检查命令：

在 PowerShell 或 CMD 中排查：

netstat -ano | findstr "LISTEN"

或者在任务管理器中查看 Clash/Mihomo 的配置详情，确认 mixed-port 或 http-port 的真实数值。

macOS 检查命令：

在 Terminal 中执行：

# 查看系统代理设置
scutil --proxy

# 或直接过滤监听代理端口的进程
lsof -nP -iTCP -sTCP:LISTEN | grep -Ei "clash|mihomo|surge|v2ray|xray"

重点确认实际监听的 mixed-port 端口（记为 <PORT>，例如 Clash 常见的 7890）。

2. 在 Codex 配置文件中注入代理参数

Codex 允许在用户目录下的配置文件中声明网络代理环境：

  • 配置文件路径：
    • Windows：%USERPROFILE%\.codex\.env
    • macOS / Linux：~/.codex/.env

编辑（若不存在则新建）该文件，追加以下标准代理参数（请将 <PORT> 替换为您在上一步查得的真实端口）：

HTTP_PROXY="http://127.0.0.1:<PORT>"
HTTPS_PROXY="http://127.0.0.1:<PORT>"
NO_PROXY="localhost,127.0.0.1,::1"

保存后彻底重启 Codex 客户端：

  • Windows：从系统托盘彻底退出，并在任务管理器确认进程结束；
  • macOS：按下 Cmd + Q 完全退出应用后重新打开。

二、 第二层：配置后仍报 TLS unexpected-eof？将代理升级为 SOCKS5H

如果加上了上述配置，Codex 依然断流，且报错变成： IO error: peer closed connection without sending TLS close_notify

这说明 Codex 已经走上了你的本地代理，但 HTTP CONNECT 隧道在传输长数据流时，被代理中间件或链路提前掐断了。更关键的是，默认的 http:// 代理在发起请求前，DNS 解析通常仍然发生在本地系统，容易受到污染或链路阻断。

解决方案：使用 SOCKS5H 协议接管并开启远端 DNS 解析

如果你的代理客户端支持 SOCKS5（Clash 的 mixed-port 原生同时支持 HTTP 和 SOCKS5），直接将应用层协议切换为 socks5h：

修改 ~/.codex/.env 文件为：

HTTP_PROXY="http://127.0.0.1:<PORT>"
HTTPS_PROXY="socks5h://127.0.0.1:<PORT>"
ALL_PROXY="socks5h://127.0.0.1:<PORT>"
NO_PROXY="localhost,127.0.0.1,::1"

注意其中的 socks5h:// 标识： socks5:// 会在本地做 DNS 解析后再发请求；而 socks5h:// 会把域名原封不动交给远端代理服务器去解析 DNS，彻底消除本地 DNS 污染和握手被中间重置的顽疾。

配置完成后再次彻底重启 Codex 进程。

Codex 本地长连接代理演进与断流排查架构

三、 终极保底：开启代理软件的 TUN 虚拟网卡模式

在极少数情况下，Codex 客户端内部依赖的某些原生二进制依赖或子进程可能不尊重 .env 里的环境变量。

如果你改了 socks5h 依然偶尔遇到流断裂，最稳定、最一劳永逸的做法是：开启代理软件的 TUN 虚拟网卡接管模式。

  1. 进入你的代理客户端设置（如 Clash Verge、Mihomo Party、Surge 等）；
  2. 开启 TUN Mode（虚拟网卡接管）；
  3. 清空 ~/.codex/.env 中的 HTTP_PROXY / HTTPS_PROXY / ALL_PROXY 声明。

此时，操作系统的所有底层网络数据包（包括 Codex 产生的所有 TCP/UDP 连接）都会由虚拟网卡驱动直接接管分流，应用层无需再配置任何繁琐的环境变量，从根本上杜绝了长连接断流和 TLS 异常断开的问题。