OpenAI Codex CLI配合Clash Verge：国内访问配置指南

为什么 OpenAI Codex CLI 需要配合 Clash Verge

OpenAI Codex CLI 是一类面向终端用户的编程助手工具，可以在命令行中读取项目文件、分析代码、生成补丁、解释报错，并按照你的确认执行部分开发任务。它与普通网页聊天工具的区别在于，请求通常由当前 Shell、Node.js 运行时或独立 CLI 进程直接发出，不一定自动继承浏览器里的代理设置。因此，即使你能在浏览器中打开部分 AI 页面，Codex CLI 登录失败、模型请求超时、流式输出中断仍然可能发生。

在国内网络环境中，Codex CLI 的一次完整使用通常包含多个阶段：安装命令行工具、检查版本、打开登录页面、完成账号授权、交换令牌、访问模型接口，以及在运行过程中建立持续的 HTTPS 或流式连接。不同阶段使用的域名和连接方式可能并不完全相同。如果只让浏览器走代理，却让终端直连，或者只代理 API 域名而遗漏登录跳转域名，最终就会出现「网页登录成功，但终端没有完成登录」或「能输入问题，但模型没有返回结果」的半连接状态。

Clash Verge 的作用不是简单地把所有流量都改成代理，而是提供一个可以观察、切换和维护的路由层。你可以通过订阅导入节点，再用规则模式决定哪些请求直连、哪些请求交给代理策略组，并在连接日志中确认 Codex CLI 的真实请求是否命中了预期规则。对于新手来说，先让整个流程稳定运行，再逐步收紧域名范围，通常比一开始就编写一份极其复杂的规则更容易排查。

安装 Clash Verge 前的准备与安全检查

安装前先确认操作系统与客户端版本匹配。Windows 用户应留意安装包架构、系统防火墙和杀毒软件提示；macOS 用户则需要关注 Apple Silicon 与 Intel 架构，以及首次启动时的系统安全确认。下载客户端时，优先选择本站客户端下载页所列出的可信渠道，不要从搜索结果中的未知网盘、破解站或二次打包页面获取代理客户端。代理软件能够接触大量网络请求，安装来源的完整性比「能否马上打开」更重要。

Clash Verge 启动后，先观察主窗口或托盘图标是否显示核心运行状态。若核心没有启动，后续导入订阅、测试节点和设置系统代理都没有意义。首次运行遇到防火墙弹窗时，应根据实际网络范围做选择：个人电脑通常只需要允许本机或专用网络访问，不建议为了省事直接关闭整个防火墙。若系统中同时安装了多个 Clash 客户端，也要避免它们同时抢占相同端口或重复写入系统代理。

还应提前准备一条有效的订阅链接。订阅链接由服务商提供，通常包含节点、策略组和基础规则。不要把订阅地址直接发布到公开聊天、截图或代码仓库中，因为它往往同时具备账户识别和流量配额权限。如果订阅已经过期，Clash Verge 可能显示配置名称，却无法更新节点；这种情况与 Codex CLI 本身无关，应先在服务商面板重新复制链接。

在 Clash Verge 中导入订阅并选择可用策略

打开 Clash Verge 后，进入配置或 Profiles 页面，找到从 URL 添加远程配置的入口，将完整订阅链接粘贴进去并保存。添加完成后不要只看列表里是否出现了配置名称，还要手动执行一次更新，确认返回状态不是 403、404、证书错误或连接超时。更新成功后，配置中通常能看到节点列表和若干策略组；如果列表为空，优先检查订阅是否失效、当前网络是否能够访问订阅域名，以及客户端日志里是否出现 YAML 解析错误。

选择配置并设为当前活动配置后，进入代理页面，先从自动选择或节点选择组中挑选一条延迟和稳定性都较好的线路。这里不建议只根据一次测速结果决定长期使用的节点。Codex CLI 的登录和代码任务更看重持续连接、TLS 握手成功率和流式输出稳定性，某个节点即使延迟最低，也可能在长时间请求中频繁断开。可以先使用自动测速组验证整体链路，出现问题时再切换到固定节点，以便缩小变量范围。

对新手而言，推荐先使用规则模式，而不是立刻开启全局模式。规则模式可以让国内常用网站保持直连，同时把 AI 服务、登录页面和必要的开发资源交给代理。全局模式适合快速验证「代理节点本身是否可用」，但它会改变更多流量的出口，可能导致国内网站验证码、企业内网、局域网服务或软件更新出现额外问题。测试完成后，建议回到规则模式，并通过日志补齐遗漏域名。

动手配置：让 Codex CLI 使用 Clash Verge 端口

Clash Verge 常见的本地入站包括 HTTP、SOCKS 或 mixed-port，具体端口以客户端当前配置页面显示的数值为准。为了让命令行工具能够明确使用代理，建议先记录本机地址和端口，例如本机地址通常是 127.0.0.1，端口可能是 7890 或其他自定义值。不要直接照抄网上示例中的端口，因为不同订阅、客户端版本和本地设置可能使用不同监听端口。

在 macOS 或 Linux 的 Shell 中，可以在启动 Codex CLI 前临时设置代理环境变量。下面的写法只是示例，请把端口替换成 Clash Verge 实际显示的 mixed-port：

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

如果你使用的是 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"

设置完成后，先不要急着登录 Codex CLI。可以先用一个简单的网络请求测试终端是否真的经过 Clash，例如访问一个你平时能够稳定打开的 HTTPS 站点，并同时观察 Clash Verge 的连接日志。如果日志中完全没有新连接，说明环境变量没有被当前 Shell 或子进程继承，或者端口类型与变量协议不匹配。如果出现连接但请求失败，再检查节点、DNS 和规则命中情况。验证代理后，再启动 Codex CLI，可以避免把「终端没有代理」误判为「账号登录异常」。

对于不方便设置环境变量的场景，可以考虑启用 Clash Verge 的系统代理，让支持系统代理的应用自动使用本地端口。但要注意，系统代理并不能保证覆盖所有终端程序、容器、远程会话和自带网络栈的应用。Node.js 工具、Python 脚本、Git、Docker 和某些独立二进制可能各自读取不同的代理配置。若 Codex CLI 仍然不通，可以优先保留环境变量配置，并检查当前命令是否由另一个 Shell、IDE 终端或任务运行器启动。

Codex 登录、API 与域名分流思路

Codex CLI 的网络请求不一定只访问一个域名。登录阶段可能涉及 OpenAI 账户页面、授权跳转、令牌交换和回调地址；运行阶段则会连接模型 API、配置服务或其他静态资源。具体域名会随着客户端版本、登录方式和服务端架构变化，因此不建议把网上复制的域名清单当作永久配置。更可靠的办法是：在 Clash Verge 中打开连接日志，执行一次登录或模型请求，然后按照时间顺序记录出现的主机名。

规则编写时，可以把明确属于 OpenAI 服务的域名后缀交给一个命名清晰的策略组，例如 OPENAI_AI。常见写法是使用 DOMAIN-SUFFIX 匹配服务后缀，而不是用过于宽泛的关键词匹配。关键词规则虽然省事，却可能误伤包含相同字符串的无关站点，也会让后续排查变得困难。规则的顺序同样重要：更具体的域名规则应放在更宽泛的规则之前，最终再由兜底规则处理未匹配流量。

示例结构如下，策略组名称必须替换为你当前配置中真实存在的名称：

rules:
  - DOMAIN-SUFFIX,openai.com,OPENAI_AI
  - DOMAIN-SUFFIX,auth.openai.com,OPENAI_AI
  - DOMAIN-SUFFIX,api.openai.com,OPENAI_AI
  - MATCH,DIRECT

这段示例的重点是表达分流逻辑，而不是保证覆盖所有版本的实际域名。若日志显示 Codex CLI 访问了新的认证域、账户域或 CDN 主机，应根据真实请求逐项增加规则。对于你无法确认用途的域名，不要仅凭名称就加入代理；可以先查看请求发生的阶段、连接方向和失败表现，再决定是并入 OPENAI_AI，还是建立单独的登录策略组。规则越少越容易维护，但覆盖范围不足同样会导致 OAuth 半路中断。

流式输出中断与长连接稳定性

编程助手常使用分块传输或流式响应，终端会在较长时间内保持连接。普通网页打开速度快，并不代表流式请求一定稳定。若 Codex CLI 能登录、能发送问题，却在生成代码时停顿、重复重试或输出半截内容，应观察 Clash 日志中连接是否被重置，并检查节点是否对长连接、TLS 或大响应存在限制。换一个稳定节点进行对比，比盲目提高本地超时时间更有价值。

同时不要忽略本地网络设备的影响。公司 VPN、透明网关、安全软件和另一款代理客户端可能会修改 DNS 或拦截 TLS，造成 Clash Verge 看似运行但实际出站路径不一致。排查时建议只保留一个代理客户端，暂时关闭不必要的 VPN，重启 Clash Verge 核心，再重复一次登录和模型请求。每次只改变一个条件，才能知道问题究竟来自节点、规则、终端环境还是本地安全策略。

常见故障的定位顺序与修复方法

如果 Codex CLI 提示无法登录，先在浏览器中确认账号页面是否能够正常加载，再检查终端是否继承代理变量。浏览器成功只能证明浏览器这条链路可用，不能证明 CLI 的网络请求使用了相同出口。随后查看 Clash Verge 日志：若完全没有相关连接，重点检查环境变量、Shell 配置和 CLI 启动方式；若有连接但被判定为直连，则检查规则顺序与策略组；若已经走代理仍失败，再测试其他节点和系统时间。

如果登录页面可以打开，但授权完成后 CLI 一直等待，通常要重点检查回调和令牌交换阶段。浏览器可能访问了授权站点，但 CLI 还需要访问另一个认证端点。保持 Clash 日志窗口打开，重新执行登录，记录授权开始到 CLI 返回结果期间出现的全部主机名。不要只把浏览器地址栏里的域名加入规则，因为真正的令牌请求可能由后台 JavaScript、CLI 本身或本地回调流程发出。

如果能够登录但模型请求报超时，先确认当前使用的模型和账号权限没有问题，然后在日志中区分 DNS 失败、TLS 握手失败、连接被重置和响应等待超时。DNS 失败通常需要检查 Clash 的 DNS 模式和本地网络；TLS 错误可能与系统时间、证书拦截或节点兼容性有关；响应等待超时则更接近节点质量、出口拥塞或规则命中了不合适的策略。把所有错误都归结为「节点慢」，往往会错过真正的配置问题。

如果代码任务中途断线，建议先缩小请求规模，例如让 Codex CLI 只读取一个小文件、执行一个简单解释任务，再逐步恢复完整项目操作。这样可以判断问题是所有 API 请求都失败，还是大上下文、长时间流式传输或工具调用阶段才触发。项目目录中也应避免把密钥、订阅链接和令牌文件提交给 CLI 读取；代理配置正确不代表敏感信息可以忽略。

完成配置后的稳定使用清单

当 Codex CLI 已经可以登录并完成一次简单代码任务后，建议把当前配置整理成可重复使用的状态。第一，记录 Clash Verge 当前使用的监听端口、模式和策略组名称，避免下次重启后忘记端口变化。第二，将代理环境变量写入明确的 Shell 配置或项目启动脚本，但不要把包含节点信息、订阅链接或账户令牌的文件提交到 Git。第三，为 Codex 单独建立策略意图，后续看到新域名时可以快速判断它属于登录、API 还是静态资源，而不是在一个巨大的代理列表里盲目添加。

日常使用推荐采用「规则模式加日志抽查」的组合。正常工作时让国内开发站点、代码仓库和局域网服务按原有规则直连；需要登录或调用模型时确认 OpenAI 相关请求进入代理策略。更新订阅后重新检查策略组是否仍然存在，因为部分服务商会在远程配置更新时重写策略名称。若本地覆写规则会被订阅覆盖，应使用客户端支持的覆写、脚本或独立配置方式保存自定义分流。

安全方面，尽量不要在公共终端执行来源不明的安装命令，也不要为了排障长期关闭证书校验、防火墙或系统安全功能。OpenAI Codex CLI 可能接触项目源码、环境变量和命令执行权限，使用前应明确当前目录、授权范围和项目备份策略。对生产项目，最好先在测试分支运行，审阅 CLI 生成的 diff 后再合并；代理配置的目标是提高连接稳定性，不应替代代码审查和权限控制。

与只依赖浏览器扩展的代理方式相比，Clash Verge 更适合 Codex CLI 这类由终端进程直接发起请求的场景；与全局 VPN 相比，它又能通过规则模式减少对国内网站、局域网和企业系统的影响。部分轻量代理工具虽然上手更快，但在订阅管理、连接日志、策略组和域名分流方面较弱，遇到「网页能用、CLI 不能用」时不容易定位。Clash V.CORE 则能把本地端口、规则路由和多客户端使用统一起来，适合需要同时处理终端、浏览器与开发工具的用户；如果你希望按本文思路完成 Codex CLI 的稳定访问，可以前往下载 Clash V.CORE，再从订阅导入和日志验证开始逐步配置。