Codex CLI 代理设置：终端环境变量、TUN 模式与常见坑

你在浏览器里能正常打开 ChatGPT，npm install -g @openai/codex 也装好了，可一输入 codex 就卡在登录页，或者任务跑到一半提示连接断开。这是 Codex 使用教程里被问得最多的场景，九成以上原因只有一个：终端没有走代理。本文专门讲代理设置，分两条路线（环境变量、TUN 模式）给出完整步骤，最后汇总常见坑。安装与登录本身请先看 Codex CLI 安装与基础使用教程。

为什么浏览器正常，Codex 却连接失败

图形客户端（Clash Verge Rev、Mihomo Party、v2rayN 等）开启「系统代理」后，修改的是操作系统层的代理设置。浏览器、微信、Steam 这类桌面程序会主动读取它，而 Node.js 程序不会。Codex CLI 基于 Node.js 运行，它发出的请求会直接走本机默认网络，于是出现「浏览器能开、终端连不上」的割裂。

解决思路只有两种：要么告诉 Node.js 代理在哪里（环境变量），要么让客户端在更底层接管所有流量（TUN 模式）。下表是两种方式的对比。

方式	原理	适用场景	需要管理员权限	对其他程序的影响
环境变量	进程读取 HTTP_PROXY 等变量后主动连代理端口	临时测试、单个项目、WSL	否	仅当前终端会话
TUN 模式	客户端创建虚拟网卡，在网络层接管流量	长期开发、多工具并用	是	全部程序都走客户端

两种方式二选一。开启 TUN 后再导出环境变量，请求会先进代理端口再被 TUN 二次接管，部分内核版本会出现回环或 DNS 异常，排查起来很费时间。

路线一：终端环境变量（推荐先试）

第一步：确认客户端端口

打开客户端设置页，找到「混合端口」或「HTTP 端口」。Clash Verge Rev 默认 7897，部分 Clash 系客户端默认 7890，v2rayN 以界面显示为准。下文以 7890 为例，请替换成你自己的端口。

第二步：导出变量

macOS / Linux（zsh 或 bash）：

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1

Windows PowerShell：

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:ALL_PROXY = "socks5://127.0.0.1:7890"
$env:NO_PROXY = "localhost,127.0.0.1"

Windows 用户如果在 WSL 里运行 Codex，WSL 内部是独立的 Linux 环境，仍然要用 bash 写法导出一遍。此时代理地址不能写 127.0.0.1，而要写 Windows 主机的 IP，或在客户端开启「允许局域网连接」后使用 cat /etc/resolv.conf 里的 nameserver 地址。

第三步：验证代理是否生效

curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://api.openai.com/v1/models

返回 401 且耗时在一两秒内，表示代理已经生效（未携带密钥返回 401 是正常的）。如果长时间无输出或报 Connection timed out，说明变量没写对或端口不对，不要急着启动 Codex。

第四步：持久化

每开一个新终端都要重新导出很麻烦。macOS / Linux 把 export 行写入 ~/.zshrc 或 ~/.bashrc；PowerShell 写入 $PROFILE 文件。更干净的做法是单独建一个 codex-env.sh，需要时 source 一下，避免 Git、npm 等工具在不需要时也走代理。

路线二：TUN 模式（长期开发更省事）

TUN 模式让客户端接管整台电脑的流量，Codex、Claude Code、Git、Docker 全部无感走代理，不需要记任何变量。开启步骤：

1. 在客户端「设置」中安装「服务模式」（Windows 与 macOS 都需要管理员授权）。
2. 打开「TUN 模式」开关，栈类型先用 mixed，不通时换 gvisor 或 system。
3. 确认「自动路由」与「自动选择接口」已勾选。
4. 用上一节的 curl 命令验证，此时不需要任何环境变量。
5. 如果之前在 shell 配置文件里写过 export，先注释掉再测试。

# 对应的 Mihomo 内核配置片段，Clash Verge Rev 会自动生成
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

Windows 下 TUN 模式的详细说明与冲突处理见 Windows 客户端使用指南，macOS 见 macOS 客户端配置指南。

常见坑对照表

现象	原因	处理
curl 正常，codex 仍提示 unable to connect	变量写在了另一个终端窗口	在同一窗口导出后再运行 codex
登录时浏览器授权成功，终端却一直等待	浏览器与终端走了不同节点，回调被拦	统一节点，或用 API Key 登录
任务跑到一半断开	节点不保持长连接或限制并发	换节点，参考稳定机场标准
输出整段一次出现而非逐字流式	线路对 SSE 做了缓冲	更换线路类型，优先专线
设置 NO_PROXY 后局域网服务不通	变量格式错误，含空格	用逗号分隔且不留空格
WSL 内连不上	写了 127.0.0.1	改为 Windows 主机 IP 并开启允许局域网

更完整的错误码与处理方式见 Codex 常见错误汇总，连接超时的通用排查见 连接超时诊断。

选 Codex 稳定机场时看什么

代理配置正确后，剩下的稳定性取决于节点。Codex 一个任务动辄运行十几分钟，期间要维持流式长连接，还会并发发起多个请求，所以 Codex 机场推荐的判断标准与看视频完全不同：

• 长连接保持：节点能否维持 30 分钟以上不断流，比峰值速度重要得多。
• 并发限制：部分低价节点限制单账号连接数，Codex 并发读文件时会被掐断。
• 出口 IP 质量：与浏览器使用同一节点，避免登录授权时 IP 不一致。
• 晚高峰丢包：开发高峰与晚高峰重叠，丢包率要低于 1%。

站内对这四项的详细分析见 Codex 稳定机场与网络环境分析。按这些指标筛选出的品牌可以在 Codex 机场推荐 栏目查看，其中 极连云 针对 AI 工具做了专门分流，宇宙云 的 IEPL 专线在长连接表现上更稳。更多稳定机场推荐的横向对比，可以看 稳定机场推荐 栏目。

总结

Codex CLI 代理设置的核心只有一句话：终端不读系统代理，必须用环境变量或 TUN 模式让它走客户端。先用 curl 验证，再启动 codex，能省掉绝大多数无谓的排查。配置稳定后，再去关注节点的长连接与并发能力，这才是 Codex 稳定机场的真正门槛。更多 Codex 教程见 Codex 教程栏目 与 Codex 专题页。