为了稳定使用 Codex，我把网络、WSL、支付和验证都串起来了

很多人以为，用 Codex 就是安装一个客户端，然后登录 ChatGPT。

真正长期使用之后会发现，安装反而是最简单的一步。

网络是否稳定、终端能不能持续连接、浏览器要不要走同一条线路、订阅如何付款、账号验证如何保住，这些环节只要有一个掉链子，Codex 的体验就会从生产工具变成反复排障。

我现在的方案并不神秘，但已经形成了一套完整链路：

Windows / WSL
  |
  +-- Cloudflare One Client：省心方案
  |
  +-- NaiveProxy：自建、可控的备用和主力线路
         |
         +-- WSL 环境变量只接管终端和 Codex
         +-- 浏览器扩展按域名分流

ChatGPT 订阅
  |
  +-- 虚拟 U 卡付款
  +-- 必要时完成短信验证
  +-- 立刻开启 MFA / Passkey

我的核心判断是：Codex 要稳定，不能只准备一条线路，而要把网络、终端、付款和账号安全一起设计。

本文只分享个人技术方案和使用经验。网络工具、虚拟号码、虚拟卡及相关服务，请根据所在地法律法规和平台服务条款自行判断使用。

第一层：Cloudflare One Client，确实是个好东西

先说最省心的方案：Cloudflare One Client。

它以前更容易被大家叫作 WARP 客户端，现在 Cloudflare 官方文档已经统一使用 Cloudflare One Client 这个名字，Windows、macOS、Linux、iOS 和 Android 都有客户端。

Cloudflare 在这件事上确实有点“大善人”的意思：客户端成熟，全球网络基础设施强，而且 Cloudflare One 仍然提供免费方案。对于不想先买服务器、不想研究协议的人，它是成本最低的起点。

我更推荐 Codex 使用完整的流量接管模式，再通过 Split Tunnels 排除局域网、公司内网和不需要代理的应用。

Cloudflare One Client 也提供本地代理模式，可以只让指定应用连接本机代理端口。但官方文档注明，该模式存在单次请求超时限制。Codex 有流式输出和长连接任务，因此我不会把这个模式作为长时间工作的首选。

这套方案的优点是简单：

• 不需要自己维护服务器；
• Windows 上打开客户端就能用；
• 可以统一处理浏览器、Codex App 和其他桌面应用；
• 支持 Split Tunnels，不必让所有流量都绕路。

它的缺点也很明确：线路质量取决于当前网络环境，出口位置和可控性不如自建服务器。

所以我的实际做法是：Cloudflare One Client 负责省心，自建 NaiveProxy 负责可控。

第二层：自己买服务器，搭一套 NaiveProxy

我用的是 NaiveProxy。

它比较小众，Windows 客户端也谈不上漂亮，基本就是一个终端窗口。但它有一个很实际的优点：使用 Chromium 的网络栈，让代理流量尽量接近普通浏览器访问 HTTPS 网站的行为。

服务端并不是单独运行一个花哨的管理面板，而是给 Caddy 编译进 forward_proxy 插件。

我目前的服务器运行 Caddy v2.11.2，并编译了 klzgrad/forwardproxy 的 Naive 分支。核心就是用 xcaddy 把 forward_proxy 模块编译进 Caddy：

xcaddy build \
  --with github.com/caddyserver/forwardproxy=github.com/klzgrad/forwardproxy@naive

对应的 Caddyfile 大致如下：

{
    order forward_proxy before file_server
}

:443, proxy.example.com {
    tls you@example.com

    forward_proxy {
        basic_auth USER STRONG_PASSWORD
        hide_ip
        hide_via
        probe_resistance
    }

    file_server {
        root /var/www/html
    }
}

普通浏览器访问这个域名时，看到的是一个正常静态网站；带正确认证信息的 NaiveProxy 客户端，才会进入代理处理。

NaiveProxy 官方支持 Windows、Linux、macOS、Android 和 OpenWrt。Windows 下可以直接运行客户端，Linux 下则更适合交给 systemd 守护。

客户端可以同时监听一个 SOCKS5 端口和一个 HTTP 端口：

{
  "listen": [
    "socks://127.0.0.1:1080",
    "http://127.0.0.1:1081"
  ],
  "proxy": [
    "https://USER:PASSWORD@proxy.example.com",
    "https://USER:PASSWORD@proxy.example.com"
  ]
}

如果密码里有 @、:、/ 等特殊字符，需要先做 URL 编码。

Linux 或 WSL 中，我会把它注册成服务：

[Unit]
Description=NaiveProxy Client
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/local/bin/naive /etc/naive/config.json
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

然后执行：

sudo systemctl daemon-reload
sudo systemctl enable --now naive
sudo systemctl status naive

如果是在 WSL 中运行，需要先确认当前发行版已经启用 systemd。

配置文件里有代理凭据，权限至少要收紧到 600。更严谨的做法，是给 NaiveProxy 创建独立的系统用户，而不是长期用 root 运行。

第三层：WSL 只接管终端，不影响 Windows 页面

我日常主要在 WSL 里使用 Codex CLI。

这一层最舒服的地方是隔离：我可以让 WSL 中的 Codex、Git、npm、curl 走代理，而 Windows 外面的普通网页保持原来的网络，不需要整台电脑一起切换。

在 ~/.bashrc 里加入：

proxy_on() {
  export http_proxy="http://127.0.0.1:1081"
  export https_proxy="$http_proxy"
  export HTTP_PROXY="$http_proxy"
  export HTTPS_PROXY="$https_proxy"

  export all_proxy="socks5h://127.0.0.1:1080"
  export ALL_PROXY="$all_proxy"

  export no_proxy="localhost,127.0.0.1,::1"
  export NO_PROXY="$no_proxy"
}

proxy_off() {
  unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY
  unset all_proxy ALL_PROXY no_proxy NO_PROXY
}

proxy_on

执行下面的命令让配置立即生效：

source ~/.bashrc

这里有一个前提：NaiveProxy 要么直接运行在 WSL 里，要么 WSL 能访问 Windows 上的本地监听端口。不同 WSL 网络模式对 127.0.0.1 的处理可能不同。如果连接失败，最省事的办法就是在 WSL 内运行 Linux 版 NaiveProxy。

测试也不要只看网页：

curl -I https://chatgpt.com
codex doctor

OpenAI 当前官方安装方式已经很直接。Linux 或 WSL 可以运行：

curl -fsSL https://chatgpt.com/codex/install.sh | sh

也可以继续使用 npm：

npm install -g @openai/codex

安装完成后运行 codex，使用 ChatGPT 账号或 API Key 登录。ChatGPT Plus、Pro、Business、Edu 和 Enterprise 当前都包含 Codex 使用权益。

第四层：浏览器按域名接管，不和终端绑死

浏览器我会单独配置代理扩展。

以前大家常用 SwitchyOmega，但原项目已经停止维护，最后一个正式版本还停留在 2018 年。现在更适合使用兼容 Manifest V3 的 ZeroOmega，并且要从可信的浏览器商店或项目仓库安装，认真核对发布者。

我通常建立两个情景模式：

• Direct：默认直连；
• Naive：HTTP 代理指向 127.0.0.1:1081。

再建立一个自动切换模式，只把 ChatGPT、OpenAI、Claude 等需要的域名交给 Naive，其他网站继续直连。

如果当前网络环境复杂，也可以临时切成全局代理。这样浏览器、WSL 和 Windows 客户端各管各的，不会因为改了一处设置，把所有应用一起带偏。

第五层：ChatGPT 订阅，我现在使用虚拟 U 卡

网络解决之后，还有付款。

我目前使用虚拟 U 卡订阅 ChatGPT，也测试过用于 ChatGPT 和 Claude 付款。但必须说明：虚拟卡能否成功，取决于发卡地区、账单地址、平台风控和当时的支付政策。我的成功经验不等于任何账号都能保证通过。

我使用的注册链接是：

RooGoo U 卡注册链接

推广说明：这个链接包含我的邀请码，我可能获得邀请奖励。平台宣传的免费开卡、7 天零费率试用、卡片升级、余额收益、消费挖矿和邀请返佣等权益，均以注册页实时规则为准。涉及加密资产或收益类产品时，请自行评估资金、合规和平台风险，不要把宣传收益理解为保本承诺。

我不建议一次往虚拟卡里放太多钱。先用小额完成开卡、验证和首笔订阅，确认续费链路正常，再决定是否继续使用。

第六层：短信验证只解决一次，MFA 才是长期方案

我之前需要短信验证时，用过 5SIM 这类临时号码平台。

它的逻辑是按国家和服务购买一次性号码，接收验证码。我的实际体验是，短信验证通常只在关键节点出现一次。

但临时号码最大的问题不是能不能收到验证码，而是这个号码长期不属于你。账号一旦再次要求验证，或者需要找回，临时号码可能已经无法使用。

所以完成登录之后，我会马上进入 ChatGPT：

Settings -> Security -> Multi-factor authentication

OpenAI 当前支持的 MFA 方式包括验证器动态码、推送通知、短信或 WhatsApp、Passkey，具体选项会因设备、地区和账号情况而不同。

我用过微信里的 FreeOTP 小程序扫描二维码，生成有时效的 6 位验证码。更稳妥的选择，是系统密码管理器、可信的离线验证器或 Passkey，因为 TOTP 二维码本质上就是账号的长期密钥。

开启 MFA 之后，我基本没有再被短信验证反复打断。

别忘了同时保存恢复方式，并检查所有已登录设备。临时号码只能帮你过一次门，MFA 和 Passkey 才是把账号真正留在自己手里的办法。

我的最终方案

如果只想尽快用上 Codex，我建议从 Cloudflare One Client 开始。

如果已经把 Codex 当成每天工作的生产工具，就值得准备一台自己的服务器，用 NaiveProxy 做一条可控线路，再把 Windows、浏览器和 WSL 拆开管理。

我的日常选择是：

省心：Cloudflare One Client
可控：自建 NaiveProxy
终端：WSL + .bashrc 环境变量
浏览器：ZeroOmega 按域名分流
订阅：虚拟卡小额付款
安全：验证完成后立即开启 MFA / Passkey

Codex 本身已经足够好用。

真正决定它能不能成为生产力工具的，往往不是模型参数，而是你有没有一条稳定、可控、能够长期维护的使用链路。

参考资料：

• OpenAI Codex Quickstart
• OpenAI Codex CLI
• OpenAI MFA 官方说明
• Cloudflare One Client 下载与平台支持
• Cloudflare One Client 模式说明
• NaiveProxy 官方仓库
• Caddy 自定义构建文档
• ZeroOmega 项目仓库