AI 编程工具走代理：VS Code、Copilot、Cursor、Claude Code、JetBrains 的代理配置与排障

摘要：浏览器里 AI 服务能正常打开，编辑器里的 Copilot、Cursor 或 Claude Code 却报连接失败、证书错误或回复中途断开——这是开发者使用 AI 编程工具时很常见的代理问题。根源在于一个 IDE 里同时跑着好几类进程：Electron 界面跟随系统代理，扩展宿主由编辑器打补丁接管，而插件拉起的命令行子进程往往只认环境变量。本文先讲清这几类进程，以及 HTTP/2、WebSocket、SSE 长连接对代理的要求，再对照官方文档逐一整理 VS Code、GitHub Copilot、Cursor、Claude Code、JetBrains IDE 和 Codex CLI 的代理设置。最后给出 TUN 与分流规则的通用方案、常见报错排查表和服务条款提示。

为什么浏览器能用，编辑器里的 AI 却报错

浏览器只有一个网络栈，开了系统代理就全部生效。AI 编程工具不一样：一个编辑器窗口背后通常有三四类进程，它们各自决定要不要走代理、从哪里读代理。

于是就有了这些典型现象：

• 窗口和登录页正常，AI 请求超时：界面走 Chromium，跟着系统代理走通了；AI 请求发自扩展宿主或子进程，没拿到代理，直连被墙。
• Copilot 能用，同一个窗口里的 Claude Code 插件连不上：Copilot 跑在被 VS Code 接管的扩展宿主里；Claude Code 插件则会启动一个独立的 claude 进程，它只读环境变量和 ~/.claude/settings.json，拿到哪些环境变量取决于平台和编辑器的启动方式。Windows 上从开始菜单启动时，只带系统级和用户级环境变量，PowerShell 配置文件或某个终端里临时设置的代理变量传不进来。macOS / Linux 上从程序坞或启动器打开时，VS Code 会先运行一次登录 shell 读取环境，写在 ~/.zshrc、~/.bashrc 里 export 的代理变量（包括指向已关闭端口的旧值）也会传给 claude，只在某个终端里临时设置的则不会。
• 终端里 claude 正常，换个终端就不行：环境变量只属于设置它的那个 shell，原理见 命令行与开发工具走代理。

系统代理本质上只是一条「公告」，读不读由程序自己决定，两种接管方式的完整对比见 TUN 模式 vs 系统代理。

长连接：HTTP/2、WebSocket 与 SSE 对代理的要求

AI 工具的流量和普通网页不同：回复是一个字一个字「流」回来的，一次生成可能持续几十秒到几分钟。常见的三种承载方式：

对本机的 mihomo、sing-box 这类代理客户端来说，这三种方式都不是问题。客户端访问 HTTPS 地址时，先向本地代理发一个 CONNECT 主机:443，之后 TLS 握手在隧道里端到端完成，HTTP/2 也是在这个握手里由客户端和服务器协商出来的（ALPN），代理只负责搬运加密字节，看不到也不关心里面是什么协议。

真正出问题的是下面三种情况：

1. 工具自己的 HTTP/2 实现不支持代理。Node.js 的 http2 模块没有「代理 Agent」这个概念，要走代理得由程序自己先建 CONNECT 隧道。哪个功能漏了这一步，它的请求就会绕过代理直连，表现为部分功能可用、部分功能超时。
2. 中间有解密 HTTPS 的代理。公司的安全网关、杀毒软件的 HTTPS 扫描、Fiddler / Charles / mitmproxy 这类抓包工具会终止 TLS 再重新发起连接。它们可能不支持 HTTP/2 双向流，或者把 SSE 响应缓冲到结束才一次性转发。Cursor 官方文档点名 Zscaler 是存在这一限制的代理中最常见的一种，HTTP/1.1 + SSE 回退方案就是为这类代理准备的。
3. 长连接被中途掐断。节点不稳定、中间设备的空闲超时，或者客户端在切换节点时主动断开旧连接，都会让一条正在输出的回复断掉。普通网页刷新一下就好，流式回复则会直接报错。

还有一层：出口地区

能连通不代表能用。多数 AI 服务按请求的出口 IP 判断地区，不在支持列表里就会返回 403 或「地区不可用」。如果同一个工具的不同域名被分流规则分到了不同出口（一部分走美国节点，一部分直连或走香港节点），就可能出现登录正常、调用失败这类不一致的现象。各服务的地区策略见 ChatGPT / Claude / Gemini 的 IP 策略与解锁。

准备：统一使用 HTTP 协议的本地代理地址

所有配置都要填本机代理地址，端口在代理客户端里查看，确认方法见 命令行与开发工具走代理 的「准备」一节。本文示例统一写 http://127.0.0.1:7890，请替换成你的实际端口。

为什么强调 http://：各工具对代理协议的支持差别很大，而 mihomo 的 mixed 端口同时接受 HTTP 与 SOCKS5，写 http:// 能兼容的工具更多。

几条通用原则：

• 代理地址写 http://，不要写 https://：本地 mixed 端口是明文代理，变量名里的 https 指的是「访问 https 网站时用的代理」。
• 设了代理变量，就在 NO_PROXY 里放上 localhost,127.0.0.1,::1：AI 工具大量依赖本地通信（IDE 与 CLI 之间、本地 MCP 服务器），这些请求不该被送到代理。但只在同时设置了 HTTPS_PROXY 等代理变量时才这样做；依赖系统代理时，不要单独往系统环境变量里写一个全局 NO_PROXY，否则 VS Code 的窗口会改为直连（见下一节）。
• 不要为了「能用」关闭证书校验：后文专门讨论。

VS Code：窗口和扩展是两套逻辑

窗口：默认跟随系统代理

VS Code 官方网络文档说明，它使用与 Chromium 相同的代理支持，系统代理设置（包括 PAC）会被自动识别。从 VS Code 源码（windowImpl.ts）可以看到更具体的规则：

1. 用户设置里填了 http.proxy，或 VS Code 启动时的环境中带有 HTTPS_PROXY / HTTP_PROXY（大小写均可），就把这个地址设给窗口的网络会话；
2. 绕过列表取自 http.noProxy，没有则取 NO_PROXY，并自动加上本地地址；
3. 只有代理地址和绕过列表都没有设置时，窗口才保留系统代理（含 PAC）。

第 3 条有一个不太直观的后果（据 VS Code、Electron 与 Chromium 的源码推断）：只设了绕过列表（http.noProxy，或启动环境里有 NO_PROXY）而没有代理地址时，VS Code 仍会用空的代理地址调用 Electron 的 setProxy，而 Chromium 把空的固定代理当作直连处理，于是窗口改为直连，系统代理反而失效。扩展向主进程查询代理时用的也是这个网络会话，Copilot 等扩展会一起直连。会话中途把 http.proxy 清空也一样会变成直连，要重启 VS Code 才会回到系统代理。

第 1 条则意味着从终端里执行 code . 首次启动的 VS Code（此前没有已在运行的实例），会受到当时终端里代理变量的影响；如果那个变量指向一个已经关掉的端口，整个窗口都会连不上网。

自动识别不奏效时，官方文档给出了 Chromium 的启动参数：

用法如 code --proxy-server=http://127.0.0.1:7890。VS Code 已在运行时，要先完全退出再带参数启动，参数才会生效。

扩展宿主：http.proxySupport

扩展运行在 Node.js 里，而 Node.js 默认不读系统代理。VS Code 的做法是在扩展宿主里替换 http、https、net、tls 模块以及全局 fetch、WebSocket 的实现，让扩展发出的请求也能按代理走。按 @vscode/proxy-agent 的源码，扩展宿主为每个请求选代理的顺序是：

1. 发往 localhost、127.0.0.1、::1 的请求总是直连；
2. 命中 http.noProxy（没设置时看 NO_PROXY）的请求直连；
3. 用 http.proxy；
4. 没有设置时，看扩展宿主自己环境里的 https_proxy、HTTPS_PROXY、http_proxy、HTTP_PROXY；
5. 以上都没有时，才把请求的 URL 交给主进程，由窗口的网络会话解析（即上面的窗口规则或系统代理）。

所以开着系统代理时，多数扩展无需额外设置。

注意：VS Code 官方网络文档的「Legacy proxy server support」一节至今仍写着扩展尚未获得与 VS Code 同等的代理支持，这是旧说法，与当前源码不符：http.proxySupport 默认为 override，扩展宿主已按上述方式接管网络请求（见 proxyResolver.ts），本文以源码为准。

相关设置的键名、默认值取自 VS Code 源码中的设置注册（request.ts）：

需要手动指定时，写在用户设置（Preferences: Open User Settings (JSON)）里。http.proxy 等代理设置在源码中注册为应用级（application）、受限的设置，写进项目的 .vscode/settings.json 不会生效；而且那个文件常被提交到仓库，容易泄露代理账号：

1
2
3
4
5
6

{
  "http.proxy": "http://127.0.0.1:7890",
  "http.noProxy": ["localhost", "127.0.0.1", "::1"],
  "http.proxySupport": "override",
  "http.proxyStrictSSL": true
}

一般情况下保持默认的 override 即可。某个扩展自带了网络处理、和 VS Code 的接管冲突时，社区排障常见的做法是改成 on 或 fallback 试试；改完要重启窗口。

扩展拉起的子进程，不受上面这些设置管

VS Code 打的补丁只作用于扩展宿主这个进程本身。扩展另外启动的程序——语言服务器、CLI、本地 MCP 服务器——是独立进程，它们只继承扩展宿主的环境变量，http.proxy 和系统代理对它们都无效。这类程序要么在各自的配置里设代理（Claude Code 见后文），要么交给 TUN 模式统一接管。

认证、证书与远程开发

• 代理认证：官方文档列出支持 Basic、Digest、NTLM 和 Negotiate，SOCKS5 代理认证尚未实现。
• 证书：官方推荐把代理的根证书装进操作系统信任库；Linux 上除系统信任库外，还要加入 NSS 证书库。--ignore-certificate-errors 会忽略所有证书错误，官方明确不推荐。
• 远程开发（Remote-SSH、WSL、Dev Containers）：运行在远端的扩展从远端机器发起请求，远端的 127.0.0.1 指的是远端自己，不是你的电脑。http.useLocalProxyConfiguration 控制远端扩展宿主是否向本地窗口查询代理，默认值由远程环境决定（源码为 useHostProxy ?? !isRemote，远程环境没有声明时为关闭）。按源码推断，开启它时远端扩展拿到的是本地解析出的代理地址，连接却仍从远端发起：本地代理是 127.0.0.1:7890 时，远端会去连它自己的 7890 端口，需要配合 FAQ 里的 SSH 端口转发。关闭它时，本地和远端的代理设置分别配置。

GitHub Copilot

本文的 Copilot 均指 GitHub Copilot。它和站内 ChatGPT / Claude / Gemini 的 IP 策略与解锁 一文提到的 Microsoft Copilot 是两个产品，域名和地区策略都不同，那里的规则不能直接套用。

Copilot 在 VS Code 和 JetBrains 中都优先使用编辑器自己的代理设置。GitHub 官方文档给出的规则：

• 编辑器未设置代理时，读取环境变量，优先级从高到低为 HTTPS_PROXY、https_proxy、HTTP_PROXY、http_proxy。与通常的约定不同，Copilot 只取优先级最高的那个，并把它同时用于 HTTP 和 HTTPS 请求；
• 认证：支持 Basic 认证（账号密码写进代理 URL）和 Kerberos；Kerberos 的服务主体名默认由代理地址推出，可在 VS Code 用 http.proxyKerberosServicePrincipal、在 JetBrains 的 Copilot 网络设置里覆盖，也可用环境变量 AGENT_KERBEROS_SERVICE_PRINCIPAL；
• 代理地址以 https:// 开头时，目前不受支持；
• 证书：从操作系统信任库和 NODE_EXTRA_CA_CERTS 指定的文件读取，因此在透明代理、Zscaler 这类环境下装好公司根证书即可。

在 VS Code 中的配置位置：设置 → Application → Proxy，即上一节的 http.proxy；「Proxy Strict SSL」复选框对应 http.proxyStrictSSL，官方建议不要关闭证书校验。在 JetBrains 中：Settings → Appearance & Behavior → System Settings → HTTP Proxy，选择 Manual proxy configuration 和 HTTP，填主机与端口。

排障入口：VS Code 官方 Copilot 排障文档建议在命令面板运行 GitHub Copilot: Chat Diagnostics，它会生成一份连通性检查报告；报告没有失败项只能排除它测过的连接，问题仍在时，用 Output: Show Output Channels 查看「GitHub Copilot」和「GitHub Copilot Chat」两个输出频道，必要时用 Developer: Set Log Level 把日志级别调到 Trace（排查完记得调回）。

Copilot 需要访问的域名以 GitHub 的 Copilot allowlist reference 为准，其中建议接口（Suggestions）除了 *.githubcopilot.com，还有 copilot-proxy.githubusercontent.com 和 origin-tracker.githubusercontent.com；用户管理与取令牌走 api.github.com（/user、/copilot_internal/*），认证走 github.com/login/*。这几类域名应走同一个出口，后文的分流规则会一并列出。

Cursor

Cursor 是 VS Code 的分支，但它的 AI 请求发往 Cursor 自己的服务器，并默认使用 HTTP/2 双向流。官方文档重点讲的是 HTTP/2 兼容性，而不是代理地址怎么填。

官方明确的部分

据 Cursor 官方网络配置与常见问题文档：

• 对话和 Agent 默认使用 HTTP/2 双向流；流式传输失败时，会自动回退到 HTTP/1.1 + SSE，无需手动操作；
• 如果所在网络的代理不支持 HTTP/2，可以手动切换：Cursor Settings → Network → HTTP Compatibility Mode，设为 HTTP/1.1，然后重启 Cursor；
• 同一页面的 Run Diagnostics 会检测本机与 Cursor 服务器之间的连通性，向官方求助时附上结果；
• 官方推荐放行的通配域名为 *.cursor.sh、*.cursor-cdn.com、*.cursorapi.com、*.cursorvm.com 与 *.*.cursorvm.com（官方注明后两个都要加），另有用于客户端更新和扩展下载的 downloads.cursor.com；其中 Cursor Tab 与代码库检索的部分接口只支持 HTTP/2；
• 登录域名正在迁移：登录页改到 accounts.spacex.ai、accounts.x.ai，另需 auth.x.ai、auth.grok.com、auth.grokusercontent.com、auth.grokipedia.com 等认证主机。官方帮助页说明，旧登录页 authenticator.cursor.sh 只作过渡期的回退，10 月 30 日停用后，登录必须能访问 accounts.spacex.ai 和 accounts.x.ai；cursor.com、api*.cursor.com 这些主机不变。完整列表以官方页面为准；
• 通过 SSH 远程开发时，AI 请求从本地机器发出，而不是远端主机——这和 VS Code 远端扩展的行为不同，排查时要注意；
• 断开 VPN 后出现 DNS 错误，官方建议完全退出并重启 Cursor，因为它可能沿用了 VPN 时期的 DNS 设置与环境变量。

代理地址怎么设

Cursor 官方文档没有说明编辑器里 http.proxy 等继承自 VS Code 的设置是否作用于 AI 请求，而社区论坛的反馈表明这一点并不可靠：

• 2026 年 7 月，Cursor 工作人员在 论坛帖 中确认了一个 3.8 到 3.9 的回归：AI 请求改走默认的 HTTP/2 通道，这条通道不经过代理，临时办法是强制使用 HTTP/1.1。工作人员随后表示计划在 3.11 修复，但未必能完全解决，该帖没有标记为已解决；
• 2026 年 10 月，仍有用户在 3.22 版本上 报告 Agent 的模型请求绕过 http.proxy 和 HTTPS_PROXY，直连 api2.cursor.sh 等接口，关闭 HTTP/2 后才经过代理。

也就是说，只在 Cursor 里填代理地址，不一定能让它的 AI 请求走代理。论坛帖里用到的 cursor.general.disableHttp2 这个键名不在官方文档中，官方文档给出的是界面里的 HTTP Compatibility Mode 开关，建议优先用它。

所以对 Cursor 来说，最可靠的做法是本机代理开 TUN 模式，让所有进程都被接管。不用 TUN 时，至少把 HTTP Compatibility Mode 设为 HTTP/1.1，并在代理客户端的连接面板里确认发往 *.cursor.sh 的请求确实经过了代理；切到 HTTP/1.1 后，只支持 HTTP/2 的 Cursor Tab、代码库检索接口可能受影响。

Cursor CLI

Cursor 的命令行 Agent 文档写得很明确，在运行前设置：

1
2
3
4
5

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NODE_USE_ENV_PROXY=1
# 中间有解密 HTTPS 的代理时，再信任对应的根证书
export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem

Windows PowerShell 的写法：

1
2
3
4
5

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:NODE_USE_ENV_PROXY = "1"
# 中间有解密 HTTPS 的代理时
$env:NODE_EXTRA_CA_CERTS = "C:\path\to\corporate-ca.pem"

NODE_USE_ENV_PROXY=1 让 Node.js 内置的网络模块读取代理环境变量。据社区反馈，Cursor CLI 使用安装包自带的 Node 运行时，这个变量是否生效取决于内置版本，和你系统里装的 Node 无关；设置后仍不走代理，就改用 TUN。Node.js 对这个变量的版本要求见 命令行与开发工具走代理 的 Node.js 一节。代理不支持 HTTP/2 双向流时，在全局配置文件里加上 network 段：

1
2
3
4
5

{
  "network": {
    "useHttp1ForAgent": true
  }
}

全局配置文件位于 macOS / Linux 的 ~/.cursor/cli-config.json，Windows 的 $env:USERPROFILE\.cursor\cli-config.json；该键默认为 false，开启后 Agent 连接改用 HTTP/1.1 + SSE。

Claude Code

Claude Code 的官方文档对代理写得比较细，企业网络配置页面明确了以下规则。

环境变量与 settings.json

几个要点：

• 不支持 SOCKS 代理，本地 mixed 端口请写 http://；
• Basic 认证写进 URL：http://用户名:密码@主机:端口；NTLM、Kerberos 等高级认证，官方建议改用支持该认证方式的 LLM 网关；
• shell 里导出的变量只在启动时读取一次，会话运行中再改 shell 不会生效；改了 settings.json 里的代理后，稳妥起见也重开一次会话；
• 代理 URL 无法解析（例如漏了 http://）时，Claude Code 会直接拒绝启动，并提示是哪个变量出了问题；
• Claude Code 自己发往 localhost、::1、127.0.0.0/8 的 WebSocket 连接永远不走代理，不需要为此改 NO_PROXY。

官方文档说明，这些变量都可以写进 settings.json 的 env 块。Claude Code 直接从文件读取，无论从哪里启动都生效——终端、VS Code 插件、后台 Agent 都一样。对后台 Agent，官方明确建议把网络相关变量写在设置里而不是 shell 里：后台 Agent 由一个共享的常驻进程托管，它只继承第一次启动它的那个 shell 的环境。

1
2
3
4
5
6

{
  "env": {
    "HTTPS_PROXY": "http://127.0.0.1:7890",
    "NO_PROXY": "localhost,127.0.0.1,::1"
  }
}

写在哪个文件里有讲究：

注意两个细节：

1. 同一个变量在 shell 和 env 块里都设置时，大多数情况下 env 块的值生效；
2. 但大小写不同的变量是两个变量。在 macOS / Linux 上，如果 shell 里残留着一个小写的 https_proxy（指向旧端口），按上面的优先顺序它会排在 env 块里大写的 HTTPS_PROXY 前面被选中。遇到「明明设置了却不生效」，先 env | grep -i proxy 看一眼，或者在 env 块里把小写的 https_proxy 也写上。Windows 的环境变量不分大小写，没有这个问题。

VS Code 插件的扩展设置里也有一个 environmentVariables 选项，可以只给插件启动的 Claude 进程设变量；官方的建议是共享配置放在 ~/.claude/settings.json。

证书

Claude Code 默认同时信任自带的 Mozilla CA 证书集和操作系统的证书库（由 CLAUDE_CODE_CERT_STORE 控制，默认值 bundled,system；通过 npm 安装时，读取系统证书库需要 Node.js 22.15 或更高版本）。公司的 HTTPS 检查代理只要把根证书装进了系统信任库，一般无需额外配置；否则用 NODE_EXTRA_CA_CERTS 指向 PEM 文件。

验证配置是否生效

1
2
3
4
5

# 启动前，用同一个代理地址手动测一次
curl -x http://127.0.0.1:7890 -I https://api.anthropic.com

# 带调试日志启动，日志写到 ~/.claude/debug/ 下
claude --debug

1
2

# Windows PowerShell 里请写 curl.exe，否则会调用自带的 Invoke-WebRequest
curl.exe -x http://127.0.0.1:7890 -I https://api.anthropic.com

进入会话后运行 /status，其中的 Proxy 一行会显示当前生效的代理地址，无法解析的值会被标为无效并忽略。

需要放行的域名

官方「Network access requirements」表列出了 Claude Code 需要访问的主机，核心几项：

另有插件市场（github.com）、插件安装与 npx 启动的 MCP 服务器（registry.npmjs.org）、Claude in Chrome 的桥接（bridge.claudeusercontent.com）、遥测等主机，配置分流规则或防火墙前请对照官方完整列表。如果你是通过公司或第三方提供的 LLM 网关接入（设置了 ANTHROPIC_BASE_URL），模型请求会发往网关地址而不是上面的域名。

JetBrains IDE

IDE 本体：HTTP Proxy 设置页

位置：Settings → Appearance & Behavior → System Settings → HTTP Proxy（macOS 上 Settings 在应用名菜单下）。据 IntelliJ IDEA 当前版本的帮助文档：

JetBrains 的支持文章与 GitHub 文档都把这里作为 AI Assistant 和 JetBrains 版 Copilot 的代理配置入口。GitHub 文档给 Copilot 的说明是选择 Manual proxy configuration 和 HTTP；Copilot 提示证书问题时，对应的开关在 Appearance & Behavior → System Settings → Server Certificates 里的「Accept non-trusted certificates automatically」，GitHub 不建议勾选。

AI Assistant 的地区与域名

JetBrains 支持文章给出了 AI Assistant / Junie 需要访问的地址，包括 api.jetbrains.ai、api.jetbrains.cloud、api.app.prod.grazie.aws.intellij.net、www.jetbrains.com/config/、account.jetbrains.com 等（中国大陆位置使用单独的 api.ai.jetbrains.com.cn）。在 AI Assistant 里使用 Claude Agent、Codex 等第三方 Agent 时，还需要 cdn.agentclientprotocol.com、frameworks.jetbrains.com、nodejs.org 和 registry.npmjs.org。

AI Assistant 还有一个容易被忽略的设置：Settings → Appearance & Behavior → System Settings → Language and Region 里的地区。JetBrains 的排障文章列出，地区设置不对、防火墙 / 代理 / VPN 拦截、所在地不在服务范围内，都会导致「AI Assistant is not available in your location」一类提示；IDE 地区、JetBrains 账号资料里的地区与实际情况要一致。同一篇文章还特别注明，AI Assistant 在香港、澳门不可用，给 JetBrains AI 用的策略组不要选这两地的节点。

构建工具要单独配

IDE 的代理设置管不到 Gradle、Maven 这些构建工具自己的下载。Gradle 官方文档给出的方式是在 gradle.properties 里写 JVM 系统属性。我们建议写在用户级的 ~/.gradle/gradle.properties（Windows 为 %USERPROFILE%\.gradle\gradle.properties），而不是项目里会被提交的那个：

1
2
3
4
5
6

systemProp.http.proxyHost=127.0.0.1
systemProp.http.proxyPort=7890
systemProp.https.proxyHost=127.0.0.1
systemProp.https.proxyPort=7890
# HTTPS 的绕过列表也用 http 前缀，官方注明这不是笔误
systemProp.http.nonProxyHosts=localhost|127.0.0.1

Maven 则在 ~/.m2/settings.xml 的 proxies 段里配置。

Codex CLI：能核实的部分

OpenAI 的 Codex 文档在代理方面信息有限，这里只写能从官方文档核实的内容：

• 证书：在有 HTTPS 检查代理或私有根证书的网络里，设置 CODEX_CA_CERTIFICATE 指向 PEM 证书包；未设置时回落到 SSL_CERT_FILE。这两个变量同时作用于登录、普通 HTTPS 请求和安全 WebSocket 连接；
• 登录回调：浏览器登录需要把令牌回传到本机的回调服务器（默认 localhost:1455）。Codex 运行在远程主机上时，官方给出的办法是在本地执行 ssh -L 1455:localhost:1455 user@remote 转发回调端口，再在这个 SSH 会话里运行 codex login。也可以改用设备码登录（测试版）codex login --device-auth，但要先在 ChatGPT 账号的安全设置里开启设备码登录，工作区账号则需管理员在工作区权限中开启；
• 配置项里的 network_proxy 不是给 Codex 自己用的：配置参考里 features.network_proxy 等设置的作用对象是沙箱里执行的命令（控制它们能访问哪些网络），而不是 Codex 与模型服务之间的连接，别把两者混淆。

至于 Codex 自身如何读取代理：官方环境变量页（列出 Codex 直接读取的稳定变量）里没有 HTTPS_PROXY 这类变量，也没有专门的代理配置章节。GitHub 上的 issue #20844 中（截至发稿仍未关闭），有 Windows 用户反馈把 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 都设为 socks5:// 时连接不稳定，改为 http:// 地址并取消 ALL_PROXY 后恢复正常；后续还有 Linux 用户反映，WebSocket 请求能经过 SOCKS 代理，HTTPS 回退路径却不行。日志里出错的请求发往 chatgpt.com/backend-api/codex/...，即 ChatGPT 账号登录时 Codex 的接口。

在官方补充说明之前，可以先把 HTTPS_PROXY、HTTP_PROXY 设为 http://127.0.0.1:端口，同时清除 ALL_PROXY 里的 socks5:// 值（unset ALL_PROXY，PowerShell 用 Remove-Item Env:ALL_PROXY），这与 issue 中恢复正常的配置一致；仍不行再用 TUN 模式。

通用方案：TUN 模式 + 分流规则

TUN：不用逐个工具配置

上面每个工具的规则都不一样，而且子进程、构建工具、MCP 服务器还会各自带来新的变数。TUN 模式在网络层接管所有进程的流量，程序本身完全不需要知道代理的存在，这对 AI 编程工具尤其合适：编辑器、插件拉起的 CLI、语言服务器、npx 启动的 MCP 服务器，一次全部覆盖。原理与取舍见 TUN 模式 vs 系统代理，开启后不生效、WSL 或 Docker 断网等问题见 TUN 模式不生效的常见原因。

配合客户端的 DNS 设置，TUN 还能减少 DNS 方面的问题：系统代理模式下，不走代理的程序会在本地解析域名，既可能拿到被污染的结果，也会暴露你在访问哪些服务，详见 DNS 泄漏是什么、怎么检测、怎么防。

分流规则：域名以官方列表为准

TUN 只负责把流量交给代理客户端，最终走哪个出口仍由规则决定。给 AI 工具单独建一个策略组，把官方列出的域名都指向它，可以避免「一部分请求走代理、一部分直连」造成的超时和地区不一致。各工具的官方域名清单：

下面是按这些清单摘录的 mihomo 规则示例（只列核心接口，完整列表请以官方页面为准）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

proxy-groups:
  - name: AI
    type: select          # 手动选择，避免自动切换导致出口 IP 频繁变化
    proxies:
      - 美国节点A
      - 日本节点B

rules:
  # 以下规则要放在 rules 列表靠前的位置：至少排在 GEOSITE、RULE-SET 这类
  # 通用代理列表（如 gfw、proxy）以及 GEOIP、MATCH 之前，
  # 否则这些域名会先被通用规则分到别的策略组
  # Claude Code
  - DOMAIN-SUFFIX,anthropic.com,AI          # 含 api、mcp-proxy 等子域名
  - DOMAIN-SUFFIX,claude.ai,AI
  - DOMAIN-SUFFIX,claude.com,AI
  - DOMAIN-SUFFIX,claudeusercontent.com,AI  # Claude in Chrome 桥接等
  # Codex（OpenAI）
  - DOMAIN-SUFFIX,openai.com,AI
  - DOMAIN-SUFFIX,chatgpt.com,AI
  # GitHub Copilot
  - DOMAIN-SUFFIX,githubcopilot.com,AI
  - DOMAIN,copilot-proxy.githubusercontent.com,AI
  - DOMAIN,origin-tracker.githubusercontent.com,AI
  - DOMAIN,api.github.com,AI
  # Cursor
  - DOMAIN-SUFFIX,cursor.sh,AI
  - DOMAIN-SUFFIX,cursorapi.com,AI
  - DOMAIN-SUFFIX,cursor-cdn.com,AI
  - DOMAIN-SUFFIX,cursorvm.com,AI
  - DOMAIN-SUFFIX,cursor.com,AI
  # Cursor 新登录页（2026 年 10 月起）
  - DOMAIN-SUFFIX,x.ai,AI
  - DOMAIN-SUFFIX,spacex.ai,AI
  - DOMAIN,auth.grok.com,AI
  - DOMAIN,auth.grokusercontent.com,AI
  - DOMAIN,auth.grokipedia.com,AI
  # JetBrains AI Assistant
  - DOMAIN-SUFFIX,jetbrains.ai,AI
  - DOMAIN,api.jetbrains.cloud,AI
  - DOMAIN,api.app.prod.grazie.aws.intellij.net,AI

几点说明：

• 规则顺序：mihomo 的规则自上而下匹配，订阅配置里常有在 GEOIP 之前就出现的通用代理列表，其中往往已经包含 anthropic.com、github.com 这类域名。AI 规则排在它们后面就形同虚设，写好后在连接面板里确认每条请求命中的规则；
• 策略组类型：url-test 自动测速组换节点后，已经建立的连接一般仍走旧节点（mihomo 的 url-test 实现不会主动断开旧连接，sing-box 的 interrupt_exist_connections 默认也是关闭的），但重试、下一轮对话和同一任务的后续请求会从新的出口 IP 发出，同一会话里出口 IP 来回变化，可能触发服务商的风控。部分图形客户端还有「切换节点时断开连接」一类选项，开着它时，正在输出的回复会被直接打断。用 select 手动固定，或用 fallback 只在节点故障时切换，更适合这类流量，取舍见 故障检测与自动切换策略；
• 节点地区：AI 策略组里不要放香港、澳门节点。Anthropic 的支持地区列表里没有这两地，OpenAI 的列表里也没有香港，JetBrains 则明确注明 AI Assistant 在港澳不可用；
• GitHub 其他域名（github.com 等）大多已被常用规则集分到代理，可以在连接面板里确认，最好与 AI 策略组的出口地区一致；
• 规则写法与规则集维护见 如何自定义规则 和 Clash 规则集详解。

常见报错与排查

对照表

证书错误：先找出是谁在「中间」

常规的代理客户端（mihomo、sing-box 等规则分流类客户端）只转发加密流量，不会替换网站证书——除非你在客户端里主动开启了 MITM / HTTPS 解密功能。所以出现自签名证书错误，几乎总是有别的东西在解密 HTTPS：

1. 公司网络：安全网关做 SSL 检查，需要 IT 提供根证书；
2. 杀毒 / 安全软件的「HTTPS 扫描」「网页防护」功能；
3. 抓包工具：Fiddler、Charles、mitmproxy 等调试完忘了关，系统代理还指向它们。

处理顺序：先确认来源；该信任的根证书装进系统信任库（VS Code、Copilot、Claude Code 都会读取系统证书）；Node.js 系工具补一个 NODE_EXTRA_CA_CERTS。网上流传的 NODE_TLS_REJECT_UNAUTHORIZED=0、关闭 http.proxyStrictSSL、--ignore-certificate-errors 都是关掉证书校验，等于放弃了 HTTPS 防中间人的能力，你的代码、API 密钥和登录令牌都可能因此暴露，不建议使用。

407：本机代理开了认证

如果你给 mihomo 设置了 authentication（例如为了安全开启了局域网连接），本机工具也会被要求认证。可以把账号密码写进代理 URL，也可以用 mihomo 的 skip-auth-prefixes 让回环地址免认证：

1
2
3
4
5

authentication:
  - "user:password"
skip-auth-prefixes:
  - 127.0.0.1/8
  - ::1/128

账号密码写进代理 URL 后，它会以明文出现在配置文件、环境变量甚至进程列表里，不要把这类配置提交到仓库。authentication、skip-auth-prefixes 与 lan-allowed-ips 的完整写法和注意事项见 mihomo 配置文件逐段详解。

流式输出中断

偶发中断多数工具会自动重试：Claude Code 官方文档说明它会对超时、连接断开、流停滞等瞬时故障自动重试，默认最多 10 次。频繁中断时按顺序检查：

1. 是否在自动切换节点：看客户端日志里有没有节点切换记录。url-test 组频繁换节点，通常说明当前节点本身不稳；同时检查客户端是否开了「切换节点时断开连接」。AI 策略组改为手动选择；
2. 节点本身是否稳定：用 节点连不上？系统排查流程 的方法排除线路问题；
3. 中间是否有公司代理：缓冲型代理会把响应攒到生成结束才转发，流式请求迟迟拿不到响应头，Claude Code 会报 No response from API。直连 Anthropic API（包括经过 HTTPS 代理）时，第一次尝试最多等约 180 秒（首字节截止时间，可用 CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS 调整），超时后重试一次，重试的等待时间比 API_TIMEOUT_MS（默认 600000 毫秒）少一秒。官方建议：代理会扣住响应直到生成完成时，调大 API_TIMEOUT_MS；第一次尝试总是超时、重试才成功时，再调大 CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS；
4. 工具版本：Claude Code 官方错误文档提到，Socket is closed 最常见的原因是 Windows 上的公司代理中途关闭隧道，v2.1.214 起会对此自动重试。

区域不可用

连接正常、返回 403 或「地区不可用」，问题不在代理配置，而在出口地区。先在浏览器访问一个显示 IP 归属地的页面，确认 AI 策略组当前节点的地区；再检查连接面板里该工具的所有域名是否都走了同一个策略组。不同服务的地区与 IP 类型要求见 ChatGPT / Claude / Gemini 的 IP 策略与解锁。

服务条款与安全提示

• 服务条款：Anthropic 的 Supported Regions Policy（页面标注自 2026 年 11 月 12 日起生效的版本）同时适用于 Claude.ai、Claude Code 和 API 等产品。它规定身处不支持地区的个人不在服务范围内，中国大陆、香港、澳门都不在支持列表中；注册地或总部在不支持地区的实体，以及被不支持地区的个人或实体直接或间接多数持股、控制的实体，其员工和用户即使身在支持地区，也不在服务范围内。OpenAI 的支持国家页面也写明，在列表之外访问或提供访问，可能导致账号被封禁或暂停。通过代理在服务不支持的地区使用这些产品，可能违反服务条款，由此带来的封号、付费订阅损失等风险需要你自行评估。
• 公司设备与网络：公司电脑上的代理、证书和网关配置往往是安全策略的一部分，自行绕过可能违反信息安全制度，操作前先了解单位规定，必要时咨询 IT 部门。
• 凭据安全：代理账号密码、API 密钥不要写进会提交到仓库的文件（.vscode/settings.json、.claude/settings.json、项目里的 gradle.properties）。
• 第三方中转：通过非官方的 API 中转服务接入，你的代码和提示词会经过第三方服务器，隐私与合规风险与直连官方完全不同，代理能保护什么、不能保护什么见 代理能做什么、不能做什么。

常见问题（FAQ）

开了 TUN 模式，还需要在 VS Code、Claude Code 里填代理吗？

一般不需要，原因见上文「TUN：不用逐个工具配置」，通用说明见 命令行与开发工具走代理 的 FAQ。AI 工具要额外注意一点：关掉 TUN 或退出客户端后，残留在 http.proxy、~/.claude/settings.json 的 env 块或 shell 配置里的代理地址会让工具连不上，排查时一并检查。

为什么 Copilot 能用，同一个窗口里的 Claude Code 插件却连不上？

两者的进程模型不同，见开头「为什么浏览器能用」一节：Copilot 的请求由 VS Code 接管，Claude Code 插件拉起的 claude 进程不读系统代理。把代理写进 ~/.claude/settings.json 的 env 块，或者开 TUN，都能解决。

Remote-SSH 或 WSL 里的 AI 工具，代理该怎么配？

先分清请求从哪台机器发出。VS Code 远端扩展、在远端终端里运行的 claude 都从远端发起请求，而远端的 127.0.0.1 并不是你的电脑；Cursor 官方文档则说明它的 AI 请求从本地发出。远端需要用本地代理时，可以用 SSH 远程端口转发把本地端口带过去：

1
2
3

# 远端的 7890 端口转发到本机的 127.0.0.1:7890
ssh -R 7890:127.0.0.1:7890 user@server
# 然后在远端设置 HTTPS_PROXY=http://127.0.0.1:7890

也可以在 ~/.ssh/config 对应的 Host 下写 RemoteForward 7890 127.0.0.1:7890。在多人共用的服务器上，同机其他用户也能连到这个端口，要评估风险。

VS Code 的远端扩展有两种配法：在 Remote 设置（Preferences: Open Remote Settings (JSON)）里开启 http.useLocalProxyConfiguration 时，远端会使用本地解析出的代理地址，用上面的方法把同一端口转发过去即可；也可以让它保持关闭，在 Remote 设置里单独设置 "http.proxy": "http://127.0.0.1:7890"。WSL 的情况见 命令行与开发工具走代理 的 WSL2 一节。

可以把证书校验关掉一劳永逸吗？

不建议，理由见上文「常见报错与排查」里的证书错误一节：这等于放弃 HTTPS 防中间人的能力，而 AI 编程工具传输的正是源代码、密钥和登录令牌。正确做法是信任解密 HTTPS 的那个程序的根证书，或者不让它解密这些域名。

频繁切换节点会影响账号吗？

可能会。同一账号短时间内从多个国家登录或调用，可能触发风控验证，原因和策略组写法见上文「分流规则」一节的说明。IP 类型与质量的判断方法见 ChatGPT / Claude / Gemini 的 IP 策略与解锁。

浏览器能打开 claude.ai，命令行里 curl api.anthropic.com 却超时？

浏览器走的是系统代理，curl 默认只读环境变量，没设就直连了。用 curl -x http://127.0.0.1:7890 -I https://api.anthropic.com 显式走代理测一次（Windows PowerShell 中写 curl.exe）：能通说明代理没问题，是工具没读到代理；不通再查节点和分流规则。终端环境变量的设置方法见 命令行与开发工具走代理。

外部参考

• VS Code：Network connections in Visual Studio Code、设置注册源码 request.ts、窗口代理源码 windowImpl.ts、扩展宿主代理源码 proxyResolver.ts、代理解析顺序 vscode-proxy-agent、登录 shell 环境解析 shellEnv.ts、Chromium 网络设置与启动参数
• GitHub Copilot：Network settings for GitHub Copilot、Configuring network settings、Copilot allowlist reference、Troubleshoot AI in VS Code
• Cursor：Network Configuration、Sign-in domains、Common Issues、CLI Configuration、论坛帖：3.9 起 AI 请求不经过代理、HTTP/2 下 Agent 绕过代理
• Claude Code：Enterprise network configuration、Environment variables、Settings、Error reference、Troubleshoot installation、Use Claude Code in VS Code
• JetBrains：HTTP Proxy 设置、AI Assistant 防火墙与代理放行地址、AI Assistant 地区设置问题、Gradle 网络与代理、Maven 代理配置
• Codex：Authentication、Environment variables、Configuration Reference、openai/codex issue #20844
• 服务条款：Anthropic Supported Regions Policy、OpenAI Supported countries and territories
• 代理客户端：mihomo 全局配置、mihomo url-test 实现源码、sing-box URLTest 出站

站内相关文章：

• 命令行与开发工具走代理：终端、Git、npm、pip、Docker 配置大全
• TUN 模式 vs 系统代理：原理与选择
• TUN 模式不生效的常见原因
• ChatGPT / Claude / Gemini 的 IP 策略与解锁