隐云 - 安全稳定的网络加速服务

Codex 梯子设置教程：代理端口、TUN 模式与连接失败排查

更新于 2026-10-18 · wkacc.top

简答：Codex CLI 通常先使用代理客户端提供的 HTTP/HTTPS 端口设置 HTTP_PROXY 和 HTTPS_PROXY；如果桌面程序或 IDE 没有继承终端变量，可改用客户端的 TUN 模式，或从已配置环境变量的终端启动 Codex。沙箱命令是否能联网，还要单独检查 Codex 的网络权限和 network_proxy 配置。

定义：Codex 梯子设置，通常是把 Clash Verge Rev、v2rayN 等代理客户端的本地 HTTP、HTTPS 或 SOCKS5 监听地址提供给 Codex CLI、桌面应用或其命令行子进程使用。

先确认你要解决的是哪一层连接问题

搜索“codex 梯子 设置”的用户，通常不是要修改 Codex 本身的模型参数，而是希望让 Codex CLI、桌面应用或 IDE 中的 Codex 能够正常登录、发送请求，或者让沙箱里的 curl、git、npm 等工具访问网络。这里要先分清三种情况。

  • Codex CLI 或桌面应用无法登录、超时：优先检查代理客户端是否运行，以及 Codex 进程是否拿到了 HTTP_PROXY、HTTPS_PROXY 等变量。
  • 终端里可以使用，桌面应用或 IDE 中不行：通常是启动进程没有继承终端环境，或者该程序使用了不同的网络实现。可先从已配置代理变量的终端启动进行对比。
  • Codex 主程序可以工作，但沙箱里的命令无法访问：这是命令执行网络权限问题，需要检查 sandbox_workspace_write.network_access、features.network_proxy 和域名规则，而不是只重复设置本机代理端口。

OpenAI 当前配置参考将工作区写入模式下的命令网络访问字段写为 sandbox_workspace_write.network_access；同时，features.network_proxy 是供沙箱命令使用的实验性网络代理开关，默认关闭。具体字段应以你当前安装版本的配置参考为准，不能直接套用旧教程中的配置层级。OpenAI Codex 配置参考

第一步：在 Clash Verge Rev 或 v2rayN 里找到实际端口

127.0.0.1:7890 只是常见示例，不是所有电脑都使用这个端口。Codex 设置前，必须以代理客户端当前显示的监听地址为准。端口写错时，最常见的现象是连接被拒绝、请求超时，或者浏览器能用但 Codex 不能用。

Clash Verge Rev

  1. 打开 Clash Verge Rev，确认已经选择有效配置并启动核心。
  2. 在客户端的设置、配置文件或当前配置内容中查找 mixed-port、port、socks-port 等字段。
  3. 如果看到类似 mixed-port: 7897，通常应先把它作为 HTTP/HTTPS 代理端口测试；如果配置同时提供 socks-port，再记录 SOCKS5 端口。
  4. 不要把远端节点端口、控制面板端口或订阅地址端口误填为本地代理端口。Codex 需要的是本机回环地址，例如 127.0.0.1:端口。
  5. 如果你启用了 TUN，仍建议先记录 mixed-port，便于在 TUN 关闭后进行对照测试。

Clash Verge Rev 的公开项目说明确认其支持配置文件管理、系统代理和 TUN 虚拟网卡模式；具体界面名称可能随版本变化，找不到固定菜单时，直接在当前配置中搜索端口字段更可靠。Clash Verge Rev 官方项目

v2rayN

  1. 确认节点已设为活动配置，并确认核心已经启动。
  2. 查看客户端底部状态区域、代理设置或本地监听设置，记录 HTTP、SOCKS 或 mixed 监听端口。
  3. 如果客户端只显示 SOCKS5 端口，先不要把它直接填进 HTTP_PROXY；应使用客户端明确提供的 HTTP 端口，或者在支持 SOCKS5 的场景使用 ALL_PROXY。
  4. 如果开启了系统代理，先记下系统代理实际指向的本机地址，再判断 Codex 是否继承了系统设置。
  5. 如果使用 TUN 模式，确认系统权限、核心类型和 TUN 状态正常；v2rayN 的公开说明包含 TUN 协议栈、MTU、路由排除等设置项。v2rayN 界面与 TUN 设置说明
端口类型与 Codex 环境变量对应关系
客户端端口通常用途Codex 测试写法注意事项
HTTP 或 mixedHTTP、HTTPS 请求HTTP_PROXY=http://127.0.0.1:实际端口优先用于 Codex CLI 的初次测试
SOCKS5支持 SOCKS5 的程序ALL_PROXY=socks5h://127.0.0.1:实际端口不要误填到只接受 HTTP 的字段
TUN 虚拟网卡系统级流量接管通常不需要为每个程序单独填端口需确认权限、路由、DNS 和排除规则

第二步：给 Codex CLI 设置代理变量

建议先用临时环境变量测试，不要一开始就写入全局配置。这样可以把“代理端口错误”和“Codex 版本或网络实现问题”分开。

Windows PowerShell

  1. 打开 PowerShell，并把下面的端口替换成 Clash Verge Rev 或 v2rayN 中实际显示的 HTTP 或 mixed 端口：$env:HTTP_PROXY="http://127.0.0.1:实际端口"
  2. 设置 HTTPS 请求使用同一个 HTTP 代理入口：$env:HTTPS_PROXY="http://127.0.0.1:实际端口"
  3. 如果你确认客户端提供 SOCKS5 端口，再按需设置：$env:ALL_PROXY="socks5h://127.0.0.1:实际端口"
  4. 先检查变量是否写入：Get-ChildItem Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:ALL_PROXY
  5. 确认变量无误后，再在同一个窗口启动：codex

不要把带用户名和密码的代理地址提交到代码仓库，也不要把完整环境变量截图公开。Windows 桌面程序从图标启动时，可能不会继承当前 PowerShell 的临时变量；此时可先从该终端启动 Codex，确认问题是否由环境继承造成。

macOS 或 Linux

  1. 设置 HTTP 和 HTTPS 代理：export HTTP_PROXY="http://127.0.0.1:实际端口" 与 export HTTPS_PROXY="http://127.0.0.1:实际端口"
  2. 为兼容区分大小写的程序，同时设置：export http_proxy="$HTTP_PROXY" 与 export https_proxy="$HTTPS_PROXY"
  3. 确认变量：env | grep -i proxy
  4. 确认无误后，从当前终端启动：codex
  5. 如果需要 SOCKS5，再设置：export ALL_PROXY="socks5h://127.0.0.1:实际端口"

Codex 网络代理项目的官方说明列出了 HTTP_PROXY、HTTPS_PROXY、WS_PROXY、WSS_PROXY 和 ALL_PROXY 的示例。其中，WebSocket 连接可能需要额外考虑 WS_PROXY 或 WSS_PROXY，但是否被你当前 Codex 版本和启动方式读取，仍应通过实际日志验证。Codex network-proxy 官方说明

第三步：什么时候应该开 TUN 模式

TUN 模式的作用是通过虚拟网卡和路由接管系统流量，减少某些程序不读取终端环境变量、桌面启动器没有继承变量、或 WebSocket 与系统代理行为不一致等问题。它不是 Codex 专属设置，也不代表开启后一定可以解决所有连接问题。

  1. 先在 Clash Verge Rev 或 v2rayN 中确认节点和核心能够正常运行。
  2. 开启客户端的 TUN 或虚拟网卡模式，并按系统提示授予网络扩展、管理员或服务权限。
  3. 暂时关闭重复的系统代理或旧的环境变量，避免 TUN、系统代理和显式代理同时指向不同端口。
  4. 完全退出 Codex，再重新启动；桌面应用、后台服务和 IDE 扩展可能需要分别重启。
  5. 先测试登录或最小任务，再测试沙箱里的网络命令。
  6. 如果 TUN 能用、显式环境变量不能用，记录操作系统、Codex 版本、客户端版本和连接方式，不要直接断言某个端口失效。

公开的 Codex 问题记录显示，在部分 Windows 和 macOS 场景中，显式设置 HTTP_PROXY、HTTPS_PROXY，或切换到 TUN 模式，可能改变 WebSocket 与 HTTPS 回退的表现；这些记录属于版本和环境相关的复现报告，不等于所有用户都会遇到同样问题。遇到持续重连、WebSocket 超时或 HTTPS 回退失败时，建议先升级到当前可用版本，再进行 TUN 与显式代理的 A/B 测试。Codex Windows 代理与 WebSocket 问题记录 Codex macOS 系统代理与 TUN 对比记录

第四步：Codex 沙箱命令无法联网时怎么配

如果 Codex 主程序已经能对话，但在任务中运行的 curl、git 或包管理器无法访问网络，不要只修改本机代理端口。官方配置参考当前明确区分了工作区网络权限和网络代理功能。

  1. 先确认当前沙箱模式。配置参考中，sandbox_workspace_write.network_access 用于允许 workspace-write 沙箱中的出站网络访问。
  2. 如果需要由 Codex 的网络代理处理沙箱命令，检查 features.network_proxy 是否启用。官方文档说明它默认关闭。
  3. 如果使用域名规则，确认目标域名有明确的 allow 规则；未配置允许项时，外部目标可能被阻止。
  4. 如果看到 403，查看响应中的策略信息。network-proxy 官方说明列出了 allowlist、denylist、method policy 等阻断类型。
  5. 不要把本机 Clash 或 v2rayN 的监听端口，和 Codex 内置沙箱代理的 features.network_proxy.proxy_url、socks_url 混为一谈。前者是外部客户端端口，后者是 Codex 配置字段。

配置参考当前列出了 features.network_proxy.proxy_url 和 features.network_proxy.socks_url，也列出了 permissions.<name>.network.enabled、mode、proxy_url 与 socks_url。由于这些字段会随 Codex 版本调整，建议只复制你当前版本配置参考中存在的字段，不要照搬来源不明的完整 TOML 示例。Codex 配置字段与权限参考

桌面应用、VS Code 扩展与终端表现不一致

Codex CLI、桌面应用和 IDE 扩展不一定由同一个进程启动，也不一定使用完全相同的网络路径。OpenAI 的 Codex IDE 文档单独说明了 IDE 扩展的安装和使用入口，因此排查时不要只看终端是否成功。Codex IDE 扩展文档

  1. 先做同机对照：在已设置代理变量的终端执行 codex，再从桌面图标或 IDE 中启动，比较结果。
  2. 检查 IDE 集成终端：在 VS Code 等编辑器的集成终端中运行 env | grep -i proxy，Windows PowerShell 则运行 Get-ChildItem Env:*proxy*。
  3. macOS 后台启动：如果程序由 launchd 或登录项启动，可在确认端口无误后使用 launchctl setenv HTTP_PROXY http://127.0.0.1:实际端口 和 launchctl setenv HTTPS_PROXY http://127.0.0.1:实际端口，然后完全退出并重新打开相关程序。完成测试后，应清理不再需要的全局变量。
  4. Windows 桌面程序：可先从 PowerShell 启动 Codex，确认显式环境变量是否有效；如果有效，再考虑配置用户环境变量，而不是直接修改系统范围设置。
  5. 后台服务：确认是否存在旧的 .env 或启动脚本。过期的回环代理端口，即使浏览器和普通命令正常，也可能让 Codex 单独失败。

DNS、MTU 和端口连通性排查命令

当错误表现为偶发超时、TLS 握手失败、WebSocket 反复重连或大请求中断时，可以按下面顺序测试。命令只用于定位本机网络问题，不代表某个代理或线路一定可用。

  1. 测试本地端口：Windows PowerShell 可运行 Test-NetConnection 127.0.0.1 -Port 实际端口；macOS 或 Linux 可运行 nc -vz 127.0.0.1 实际端口。
  2. 测试 HTTP 代理：curl -I -x http://127.0.0.1:实际端口 https://example.com。若这里就失败，先检查客户端核心、端口、防火墙和规则。
  3. 测试 DNS：Windows 使用 nslookup auth.openai.com；macOS 或 Linux 可使用 dig auth.openai.com。如果解析失败，先排查 DNS，而不是立即更换 Codex 配置。
  4. 测试 MTU：Windows 可从 ping -f -l 1472 目标域名 开始，出现需要分片或失败时逐步降低数值；macOS 或 Linux 可尝试 ping -D -s 1472 目标域名。不同系统对参数支持不同，命令报错时先查看本机 ping 帮助。
  5. 对比 TUN 和显式代理：只改变一个变量，分别记录直连、HTTP 代理和 TUN 三种状态下的错误信息，不要同时更换节点、DNS、客户端和 Codex 版本。

如果普通 HTTPS 能通，但 WebSocket 仍然超时，不能简单得出“代理端口错误”的结论。Codex 的公开问题记录中确实存在系统代理、显式环境变量和 WebSocket 传输表现不一致的案例，因此应记录版本并优先尝试升级或使用 TUN 进行对照。

推荐的最小排查顺序

  1. 确认 Clash Verge Rev 或 v2rayN 核心已启动，并记录当前 HTTP、HTTPS、SOCKS5 端口。
  2. 用 Test-NetConnection 或 nc 检查本机端口是否监听。
  3. 用 curl -x 测试代理是否能建立 HTTPS 请求。
  4. 在当前终端设置 HTTP_PROXY 和 HTTPS_PROXY，先检查变量，再启动 Codex。
  5. 如果终端有效而桌面或 IDE 无效，比较进程启动方式，并尝试从已配置变量的终端启动。
  6. 如果仍然出现 WebSocket 重连或桌面程序不继承变量，开启 TUN 做 A/B 测试。
  7. 只有在沙箱命令无法联网时，才进一步检查 sandbox_workspace_write.network_access 和 features.network_proxy。
  8. 最后再检查 DNS、MTU、域名规则、企业防火墙和自定义证书，不要一次修改多个变量。

本文不核实任何第三方网络服务的价格、速度、状态或可用性；具体客户端界面、端口和 TUN 权限以你安装的软件版本和其公开说明为准。

常见问题

Codex 一定要设置梯子或代理才能使用吗？

不一定。如果当前网络已经能完成登录和请求，就不需要额外设置。只有出现连接超时、登录失败或 WebSocket 重连时，才建议先确认本地代理端口，再临时设置 HTTP_PROXY 和 HTTPS_PROXY 进行测试。

Clash Verge Rev 的端口在哪里找？

优先打开当前配置或客户端设置，搜索 mixed-port、port、socks-port 等字段；也可以查看客户端显示的本地监听信息。不要直接套用 7890、7897 等示例端口，必须以当前配置实际值为准。

v2rayN 只有 SOCKS5 端口，怎么给 Codex 设置？

先确认 v2rayN 是否同时提供 HTTP 或 mixed 端口。若只有 SOCKS5，且当前 Codex 版本和启动方式支持 SOCKS5，可尝试设置 ALL_PROXY=socks5h://127.0.0.1:实际端口；不要把 SOCKS5 地址直接填进只接受 HTTP 的字段。

设置了 HTTPS_PROXY，为什么 Codex 仍然连接失败？

可能是端口或协议写错，也可能是桌面进程没有继承变量、WebSocket 路径与 HTTPS 路径表现不同，或存在旧的 .env 配置。先用 curl -x 测试端口，再从同一个已设置变量的终端启动 Codex；若仍失败，可升级并用 TUN 模式做对照。

Codex CLI 能联网，但沙箱里的 curl 或 git 不能联网怎么办？

这是两层配置。先检查 sandbox_workspace_write.network_access；如果需要 Codex 的网络代理和域名策略，再核对 features.network_proxy 及其 domains、proxy_url 等字段。不要把外部客户端端口和 Codex 内置沙箱代理字段混用。

要不要开启 TUN 模式？

如果显式环境变量无法被桌面应用、IDE 或后台进程继承，可以把 TUN 作为对照方案。开启前先确认客户端核心、权限、路由和 DNS 设置，关闭重复的旧代理变量，并重启 Codex 相关进程。

相关阅读

参考资料

  1. OpenAI Codex 配置参考
  2. Clash Verge Rev 官方项目
  3. Codex Windows 代理与 WebSocket 问题记录
  4. Codex macOS 系统代理与 TUN 对比记录