云数智花园

TECH

Windows 网络受限环境下配置 CodeX / Cloud Code 的代理指南

从 OAuth 协议流程出发，解释 VS Code 插件和 WSL CLI 为什么需要独立配代理，并给出完整的排查与配置方案。

topic: ai-way type: 笔记 origin: 笔记 score: 8 addedAt: 2026-02-26

修订记录

版本时间说明
v12026-02-26初稿：基于实际排障过程整理
v22026-02-26补充：Smart 模式分流原理、全局代理认知误区、本地代理端口 vs 系统代理开关的区别

问题现象

在 VS Code 中使用 CodeX 或 Cloud Code（GitHub Copilot 等同理）插件，选择通过 ChatGPT / Google 账号登录时：

  1. 浏览器能正常跳转到登录页面，输入账号密码成功
  2. 选择工作空间 / 个人账号后，回调到 http://localhost:<port>/auth/callback?code=...
  3. 报错：Token exchange failed: token endpoint returned status 403 Forbidden

直觉反应是”我已经开了全局代理，浏览器能上”，但 VS Code 里就是过不去。

根因：OAuth 2.0 的两段式流程

要理解这个问题，需要先理解 OAuth 2.0 Authorization Code Flow（授权码模式）的两个阶段：

┌─────────────┐         ┌──────────────┐         ┌──────────────┐
│  VS Code    │         │   浏览器      │         │  Auth Server │
│  Extension  │         │  (系统默认)    │         │  (OpenAI)    │
└──────┬──────┘         └──────┬───────┘         └──────┬───────┘
       │                       │                        │
       │  1. 打开浏览器登录     │                        │
       │──────────────────────>│   2. 用户输入账号密码    │
       │                       │───────────────────────>│
       │                       │   3. 返回 auth code     │
       │                       │<───────────────────────│
       │  4. 浏览器回调         │                        │
       │     localhost:port     │                        │
       │<──────────────────────│                        │
       │                       │                        │
       │  5. 用 code 换 token  （POST 请求）              │
       │─────────────────────────────────────────────-->│
       │                       │                        │
       │  6. 返回 access_token │                        │
       │<──────────────────────────────────────────────│
       └                       └                        └

关键差异：

阶段执行者网络通道走不走系统代理
步骤 1-3（登录）浏览器浏览器自身的网络栈走 — 浏览器会读系统代理
步骤 5（换 token）VS Code 后端（Node.js）VS Code 内部 HTTP 请求默认不走 — Node.js 不自动读系统代理

所以你看到的现象就是：登录成功（浏览器走了代理），但换 token 失败（VS Code 没走代理，被 GFW/风控拦截返回 403）。

解决方案

方案一：VS Code settings.json 配置（推荐）

VS Code 内置了一套独立的代理配置，专门控制其内部所有 HTTP 请求（包括扩展发起的请求）。

仅当前工作区生效

在项目根目录创建 .vscode/settings.json：

{
  "http.proxy": "http://127.0.0.1:7078",
  "http.proxyStrictSSL": false,
  "http.proxySupport": "on"
}

所有 VS Code 窗口全局生效（推荐）

按 Ctrl + Shift + P → 输入 Preferences: Open User Settings (JSON)，添加：

{
  "http.proxy": "http://127.0.0.1:7078",
  "http.proxyStrictSSL": false,
  "http.proxySupport": "on"
}

三个配置项的含义：

配置项说明
http.proxy代理地址。127.0.0.1 = 本机，端口号看你的代理客户端设置
http.proxyStrictSSL设为 false，避免代理的自签证书导致 SSL 校验失败
http.proxySupport设为 on（而非默认的 override），确保所有请求都走代理

注意： 这个配置只影响 VS Code 自身，不会影响浏览器、系统或其他软件。代理客户端只需在后台运行即可，不需要开”全局模式”。

方案二：设置 Windows 环境变量（兜底）

有些扩展不读 VS Code 的代理配置，而是读标准环境变量。两者同时配可以最大化兼容性。

在 Windows 终端（CMD / PowerShell）中执行：

setx HTTP_PROXY http://127.0.0.1:7078
setx HTTPS_PROXY http://127.0.0.1:7078
setx NO_PROXY localhost,127.0.0.1

setx 设置的是用户级永久环境变量，重启后依然生效。设置后需要完全退出并重新打开 VS Code（setx 只对新进程生效）。

方案三：WSL 中使用 CLI 工具

如果你在 WSL 里通过命令行（如 codex CLI）登录，原理相同 — CLI 工具也需要通过代理才能访问 auth 服务器。

WSL 中设置代理环境变量：

# 临时生效（当前 shell）
export HTTP_PROXY=http://127.0.0.1:7078
export HTTPS_PROXY=http://127.0.0.1:7078
export NO_PROXY=localhost,127.0.0.1

# 永久生效（写入 ~/.bashrc 或 ~/.zshrc）
echo 'export HTTP_PROXY=http://127.0.0.1:7078' >> ~/.bashrc
echo 'export HTTPS_PROXY=http://127.0.0.1:7078' >> ~/.bashrc
echo 'export NO_PROXY=localhost,127.0.0.1' >> ~/.bashrc
source ~/.bashrc

WSL 和 Windows 宿主机共享同一个 127.0.0.1 网络栈（WSL 2 默认开启了 localhostForwarding），所以 Windows 上运行的代理客户端对 WSL 也可用。

验证代理是否通

curl -s -o /dev/null -w "Status: %{http_code}\n" --connect-timeout 3 https://auth.openai.com
  • 返回 403 或 200/301/302 → 代理通了（请求到达了 OpenAI）
  • 返回 000 → 代理不通（连接超时/拒绝）

快速排查端口

不确定代理端口是哪个？用 curl 逐个探测：

# 测试常见端口
for port in 7078 7890 10809 1080; do
  code=$(curl -x http://127.0.0.1:$port -s -o /dev/null -w "%{http_code}" --connect-timeout 2 https://www.google.com 2>/dev/null)
  echo "Port $port: HTTP $code"
done

返回非 000 的就是可用的代理端口。

完整配置检查清单

  • 代理客户端（MyMonoCloud / Clash / V2RayN 等）在后台运行
  • 确认本地 HTTP 代理端口号（不是 SOCKS5 端口）
  • VS Code 用户级 settings.json 中配置了 http.proxy
  • Windows 环境变量 HTTP_PROXY / HTTPS_PROXY 已设置
  • WSL 环境变量已设置（如果用 CLI）
  • 完全重启 VS Code（不是 Reload Window，是退出再打开）
  • 重新登录 CodeX / Cloud Code

常见误区

”我开了全局代理，为什么还不行？”

“全局代理”通常指代理客户端修改了 Windows 的系统代理设置（IE 代理 / WinHTTP）。但 VS Code 基于 Electron（Node.js），默认不读系统代理。必须通过 http.proxy 配置或环境变量显式指定。

“设了 HTTP_PROXY 环境变量，国内网站也会走代理吗？”

设了 HTTP_PROXY 后，请求的流转路径是：

你的程序 → 127.0.0.1:7078 (代理客户端) → 目标网站

请求确实都会先到代理客户端的本地进程，但代理客户端会根据模式决定如何处理：

代理客户端模式访问 baidu.com访问 openai.com
Smart 模式直连（不经过代理服务器）走代理服务器出去
全局模式走代理服务器走代理服务器

使用 Smart 模式时，代理客户端内置了分流规则 — 国内域名直连，国外域名走代理。所以即使所有请求都经过 127.0.0.1:7078，访问国内网站时代理客户端会让它直连，不绕远路。

唯一的额外开销是请求多经过了一次本地回环（127.0.0.1），延迟可忽略不计（微秒级）。

结论：保持 Smart 模式 + 环境变量/http.proxy 配置即可，国内直连、国外走代理，全自动。

“开了代理会不会影响内网访问？”

http.proxy 只作用于 VS Code 内部请求。配合 NO_PROXY=localhost,127.0.0.1，本地开发服务器（如 localhost:3000）不受影响。其他软件（浏览器、终端等）的网络行为完全独立。

“代理客户端需要开’全局模式’吗？”

不需要。代理客户端启动后就会在本地监听端口（如 127.0.0.1:7078），VS Code 直连这个端口即可。代理客户端的”全局模式""Smart 模式""规则模式”影响的是系统代理设置，与 VS Code 的 http.proxy 配置无关。

深入理解：“全局代理” vs “本地代理端口”

很多人（包括笔者最初）有一个认知误区：以为必须开”全局代理”才能让软件走代理。实际上，代理客户端有两个完全独立的概念：

概念作用何时可用
本地代理端口 (127.0.0.1:7078)一个始终在监听的代理服务，谁连它谁就能走代理客户端运行就有，跟模式无关
”全局代理”开关修改 Windows 系统代理设置（IE 代理 / WinHTTP），让读系统代理的软件自动连上面的端口手动开启时

用公式表达：

"全局代理" ≠ 代理能力本身
"全局代理" = 帮你把 Windows 系统代理设置指向 127.0.0.1:7078

为什么之前必须开全局代理才能登录 Copilot / CodeX？

因为之前没有在 VS Code 里手动配 http.proxy。VS Code（基于 Electron/Node.js）默认不读系统代理，但开了全局代理后，在某些版本和特定条件下，Electron 可能会间接读到（行为不稳定，时灵时不灵）。

所以之前的体验是：开全局代理 → 有时能用有时不能用 → 很困惑。

正确做法

显式配了 http.proxy: http://127.0.0.1:7078 之后，VS Code 直接连本地代理端口，不再依赖系统代理设置。无论全局代理开不开、Smart / 规则 / 任何模式，只要代理客户端在运行，VS Code 就能走代理。

一句话总结：以前是”碰运气走系统代理”，现在是”精确指定走哪个端口”，更稳定也更可控。

原理总结

三条独立的代理通道

┌─────────────────────────────────────────────────────────┐
│                    Windows 宿主机                        │
│                                                         │
│  ┌──────────┐   http.proxy    ┌──────────────┐          │
│  │ VS Code  │ ───────────────>│ 代理客户端    │          │
│  │ (Node.js)│   127.0.0.1:    │ (MyMonoCloud │──> 外网  │
│  └──────────┘   7078          │  /Clash/..)  │          │
│                               └──────────────┘          │
│  ┌──────────┐   HTTP_PROXY    ┌──────────────┐          │
│  │ WSL CLI  │ ───────────────>│    同上       │          │
│  │ (curl/..)│   127.0.0.1:    │              │──> 外网  │
│  └──────────┘   7078          └──────────────┘          │
│                                                         │
│  ┌──────────┐   系统代理       ┌──────────────┐          │
│  │ 浏览器   │ ───────────────>│    同上       │          │
│  │          │   (自动读取)     │              │──> 外网  │
│  └──────────┘                 └──────────────┘          │
└─────────────────────────────────────────────────────────┘

核心要点：不同软件读代理配置的方式不同。浏览器读系统代理，VS Code 读 http.proxy，CLI 工具读环境变量。三条路径互不干扰，需要分别配置。

Smart 模式下的流量分流

┌──────────┐       ┌──────────────────────────────┐
│ VS Code  │       │     代理客户端 (Smart 模式)    │
│ / WSL    │──────>│  127.0.0.1:7078              │
│ / 浏览器  │       │                              │
└──────────┘       │  ┌─ 匹配国内规则? ──> 直连    │──> baidu.com ✓ 直连
                   │  │                           │
                   │  └─ 匹配国外规则? ──> 代理    │──> openai.com ✓ 代理
                   └──────────────────────────────┘

即使所有请求都经过本地代理端口，Smart 模式也会自动分流：国内直连、国外走代理。不需要用户操心。

评论