一键体检：你的终端 / Claude / VS Code 到底走没走代理？真实 IP 漏没漏

你开了梯子（Clash 之类），浏览器能科学上网，于是默认「整台机器都走代理了」——这是最常见、也最致命的误判。默认配置下，代理往往只接管了走系统代理的那点流量（主要是浏览器），而终端（命令行）和一堆桌面应用根本不读系统代理，它们还在用你真实的宽带 IP 裸连。

偏偏 Claude Code 就是个跑在终端里的命令行工具，VS Code 的集成终端和扩展也常常各走各的。它们的请求一旦带着你真实地区的 IP 打到 Anthropic，账号被风控、被封，都是这么来的。

这篇不教你怎么清理（清理是另一篇的事，链接放在文末），只干一件事：给你一套一键复制的命令，逐项查清楚——你的终端、你的 Claude / AI 工具、你的 VS Code，到底有没有走代理、有没有在漏真实 IP。 Windows 和 macOS 两套并排放，每个代码块右上角点「复制」即可整段拷走。

一句话先说结论：「浏览器能翻墙」≠「终端走代理」≠「Claude 走代理」。 这三件事必须分别验。判断的金标准只有一个——看你的请求到底从哪个 IP 出去的：是代理节点的 IP（✅ 干净），还是你家宽带的真实 IP（❌ 漏了）。

⚡ 速抄：一口气查完（一键复制）

赶时间的看这里，整段拷走粘进终端，挨条读输出。想搞懂每条在干嘛、怎么读结果，往下看「逐项详解」。

命令里不含任何真实 IP / 凭据 / 域名，端口都用 Clash 默认值（7890/7897）做占位——你照抄即可，按自己代理工具实际监听的端口替换。

🪟 Windows（PowerShell）· 一键体检

# ① 真实出口 IP + 地区（这是代理节点的，还是你本地的？）
curl.exe -s https://api.ip.sb/geoip

# ② 查代理环境变量
Get-ChildItem Env: | Where-Object { $_.Name -match 'PROXY|ANTHROPIC|CLAUDE' }

# ③ 查系统代理
netsh winhttp show proxy

# ④ Claude / AI 走不走代理（读了 env 代理的结果）
curl.exe -v https://api.anthropic.com/ 2>&1 | findstr /i "Trying Connected"

# ⑤ ★关键：绕开 env 代理，单独验 TUN 本体
curl.exe --noproxy "*" -v https://api.anthropic.com/ 2>&1 | findstr /i "Trying"

# ⑥ 哪些进程在走代理端口
netstat -ano | findstr "7890 7897 8080"

# ⑦ 顺手清 DNS 缓存
ipconfig /flushdns

🍎 macOS · 一键体检

# ① 真实出口 IP + 地区（这是代理节点的，还是你本地的？）
curl -s https://api.ip.sb/geoip

# ② 查代理环境变量
env | grep -iE 'proxy|anthropic|claude'

# ③ 查系统代理
scutil --proxy
networksetup -getwebproxy Wi-Fi

# ④ Claude / AI 走不走代理（读了 env 代理的结果）
curl -v https://api.anthropic.com/ 2>&1 | grep -iE "Trying|Connected"

# ⑤ ★关键：绕开 env 代理，单独验 TUN 本体
curl --noproxy "*" -v https://api.anthropic.com/ 2>&1 | grep -i "Trying"

# ⑥ 哪些进程在走代理端口
lsof -nP -iTCP -sTCP:ESTABLISHED | grep -E '7890|7897'

# ⑦ 顺手清 DNS 缓存
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

上面是「一口气版」。每条命令该怎么读、什么样算漏、什么样算干净，下面逐项讲透。

① 看真实出口 IP + 地区（一切的起点）

不管你配置写得多漂亮，配置对 ≠ 流量真走了。最硬的一招，就是直接看你的请求到底从哪个 IP、哪个地区出去的。

macOS：

curl -s https://api.ip.sb/geoip

Windows（PowerShell，注意是 curl.exe，不是别名）：

curl.exe -s https://api.ip.sb/geoip

为什么 Windows 一定要写 curl.exe？因为 PowerShell 里 curl 是 Invoke-WebRequest 的别名，参数语法完全不同。加 .exe 才是真正的 curl，跟 macOS / Linux 行为一致。本文 Windows 侧所有 curl 命令都用 curl.exe。

返回是一段 JSON，重点看 ip 和 country / country_code：

{
  "ip": "<出口IP>",
  "country": "<国家>",
  "country_code": "<国家代码>",
  "isp": "<运营商>"
}

怎么读：

返回的 IP / 地区 = 你代理节点所在地（一般是境外）→ 走代理了 ✅
返回的 IP / 地区 = 你本地真实宽带（你所在的城市 / 运营商）→ 漏了，终端没走代理 ❌

只想要 IP 一个值、不要整段 JSON，用这条更干脆：

curl -s https://api.ip.sb/ip

curl.exe -s https://api.ip.sb/ip

单点端点偶尔抽风，备用：https://ifconfig.me、https://ipinfo.io/ip。任选其一交叉验证。

② ★终端 vs 浏览器：出口 IP 对比（一秒看出漏没漏）

这是最直观、最不会骗人的一招：同一时刻，两个地方看出口 IP，一对比就知道终端漏没漏。

终端里跑：

curl -s https://api.ip.sb/ip

curl.exe -s https://api.ip.sb/ip

浏览器里打开：https://ip.sb（或 https://ipinfo.io），看页面显示的 IP。

两个 IP 一比：

终端 IP	浏览器 IP	结论
代理节点 IP	代理节点 IP（一致）	终端也走代理了，干净 ✅
你真实宽带 IP	代理节点 IP	终端在漏真实 IP，代理只接管了浏览器 ❌

第二种情况最常见，也最坑：你看浏览器能翻墙就放心了，结果终端里的 Claude Code 一直在用真实 IP 裸连。解法是开 TUN 模式（见 ⑥ 和文末「踩坑总结」），把终端也接管进来。

③ 查代理环境变量

代理工具 / 教程经常让你 export 几个环境变量来「让命令行走代理」。先查清楚它们在不在、指向哪。

Windows（PowerShell）：

Get-ChildItem Env: | Where-Object { $_.Name -match 'PROXY|ANTHROPIC|CLAUDE' }

macOS：

env | grep -iE 'proxy|anthropic|claude'

各变量管什么：

变量	管什么
`HTTP_PROXY` / `http_proxy`	明文 `http://` 请求走哪个代理
`HTTPS_PROXY` / `https_proxy`	`https://` 请求走哪个代理（Claude Code 连 `api.anthropic.com` 看的就是它）
`ALL_PROXY` / `all_proxy`	所有协议的兜底代理（含 socks）
`NO_PROXY` / `no_proxy`	例外白名单：命中的域名 / IP 直连、不走代理（小心别把 `anthropic` 写进去）
`ANTHROPIC_` / `CLAUDE_`	跟 Claude 相关的配置（base_url、token、模型等）——本文只做检测，清理见文末那篇

关键认知：这几个 *_PROXY 变量只对「读它们」的程序有效。你在某个终端 export 了，也只有这个窗口、且只有那些「尊重环境变量代理」的程序才走代理——很多 GUI 桌面应用压根不读它。所以光看变量在不在，不等于流量真走了代理，得继续往下用出口 IP 实测。

④ 查系统代理

环境变量是「程序级」的，系统代理是「操作系统级」的设置。两者是两回事，都得查。

Windows：

netsh winhttp show proxy

Windows 有两套代理：WinHTTP（上面这条命令查的，很多后台服务 / CLI 看这层）和 WinINET（IE / 「设置 → 网络和 Internet → 代理」那层，浏览器看这层）。有些程序只认其中一套——这正是「浏览器走了、命令行没走」的经典原因。图形界面再核一眼：设置 → 网络和 Internet → 代理，看「手动设置代理」开没开。

macOS：

scutil --proxy                              # 系统全局 / PAC 代理总览
networksetup -getwebproxy Wi-Fi             # http 代理（网卡名按实际，可能是 Ethernet）
networksetup -getsecurewebproxy Wi-Fi       # https 代理
networksetup -getsocksfirewallproxy Wi-Fi   # socks 代理

怎么读： 看到 Enabled : Yes 才是开着。scutil --proxy 里若有 ProxyAutoConfigEnable : 1，说明走的是 PAC 自动配置脚本。但请记住——系统代理开着，也不代表命令行就走了（很多 CLI 不读系统代理），照样要用出口 IP 和下面 ⑤⑥ 实测。

⑤ ★Claude / AI 到底走不走代理（看连接落点）

前面查的都是「机器整体」，这一步精确到「连 Anthropic 的这一次请求，到底连到哪了」。

Windows：

curl.exe -v https://api.anthropic.com/ 2>&1 | findstr /i "Trying Connected"

macOS：

curl -v https://api.anthropic.com/ 2>&1 | grep -iE "Trying|Connected"

怎么读输出：

看到 Trying 127.0.0.1:7897... / Connected to 127.0.0.1 ... port 7897 → curl 读到了 HTTPS_PROXY，正经过本地代理端口出去（系统代理 / env 代理模式）✅
看到 Trying 198.18.x.x... → 走的是 TUN 模式的 fake-ip（虚拟网卡在网络层接管了，见 ⑥）✅
看到 Trying <api.anthropic.com 的真实公网 IP>...、Connected to api.anthropic.com (<某公网IP>) port 443 → 没走任何代理，直连，真实 IP 暴露 ❌

127.0.0.1:7897 里的 7897 是 Clash 的默认混合端口（老版本常见 7890），换成你代理工具设置里实际监听的端口。198.18.x.x 是 Clash TUN 的 fake-ip 专用网段，看到它基本就是 TUN 在接管。

⚠️ 但这条有个大坑：curl 会优先读 HTTP_PROXY / HTTPS_PROXY 环境变量。 如果你 export 过这俩，这条命令永远显示「连本地代理端口」，哪怕 TUN 根本没开——它读的是 env 代理，不是 TUN。所以光看这条会误判，必须配合下一条 ⑥ 单独验 TUN 本体。

⑥ ★★验 TUN 本体（关键 · 最容易误判的一步）

接着 ⑤ 的坑说。要判断「TUN 模式（虚拟网卡）到底有没有在接管全机流量」，就得把 env 代理变量绕开，让 curl 不读 HTTP_PROXY，看它在「没有 env 代理」的情况下还能不能从代理出去——能，就说明是网络层（TUN）在接管。

加 --noproxy "*" 强制忽略所有代理环境变量：

Windows：

curl.exe --noproxy "*" -v https://api.anthropic.com/ 2>&1 | findstr /i "Trying"

macOS：

curl --noproxy "*" -v https://api.anthropic.com/ 2>&1 | grep -i "Trying"

怎么读：

出现 Trying 198.18.x.x...（Clash fake-ip 网段）→ TUN 真生效了，网络层全接管，终端、CLI、GUI 一个不漏 ✅✅
出现 Trying <api.anthropic.com 的真实公网 IP>... → TUN 没接管，绕开 env 代理后就直连了——说明你之前 ⑤ 看到的「走代理」纯靠 env 变量撑着，一旦某个程序不读 env，就漏 ❌

这就是为什么 ⑤ 和 ⑥ 要一起看：⑤ 告诉你「读 env 代理的程序走不走代理」，⑥ 告诉你「不读 env 的程序（才是大多数 GUI / 部分 CLI）走不走代理」。两条都指向代理出口，才是真·全程不漏。

⑦ 哪些端口 / 进程在走代理

反过来看本机：有没有活跃连接真的打到了代理端口。有，就反证「确实有程序在用代理」。

代理客户端（Clash 等）会在本地开端口转发流量，常见 7890（旧版混合 / http）、7897（新版混合）、7891（socks）、8080 等。

Windows：

netstat -ano | findstr "7890 7897 8080"

macOS：

lsof -nP -iTCP -sTCP:ESTABLISHED | grep -E '7890|7897'

怎么读： 有输出 = 确实有进程通过代理端口在转发。把端口换成你代理工具实际监听的那个（在它设置面板里能看到）。netstat -ano 最后一列是 PID，可以拿去任务管理器反查是哪个程序；lsof 第一列直接就是进程名。

注意：这条只能证明「有东西在走代理」，不能证明「Claude / 你的终端在走代理」——要确认具体某个进程，还得回到 ⑤⑥ 的 curl 实测。

⑧ VS Code 等应用是否走代理（应用各自为政）

这是单独要警惕的一类：很多桌面应用有自己的代理设置，既不读系统代理、也不一定读环境变量。 VS Code 就是典型——它有 http.proxy 设置项，它的集成终端和扩展（Copilot、各种 AI 插件、Claude 相关扩展）走不走代理，得单独确认。

第一步：在 VS Code 的集成终端里，跑一遍 ① 的出口 IP 命令做对比。

打开 VS Code → 顶部菜单 Terminal → New Terminal → 在里面跑：

curl -s https://api.ip.sb/ip

curl.exe -s https://api.ip.sb/ip

把这个结果跟你系统终端里同一条命令的结果对比：

两边一致（都是代理节点 IP）→ VS Code 集成终端也走代理了 ✅
VS Code 里是真实宽带 IP、系统终端是节点 IP → VS Code 的终端在漏，它没继承到代理 ❌

第二步：查 VS Code 自己的代理设置。

Ctrl/Cmd + , 打开设置，搜 http.proxy，或直接看 settings.json 里有没有这几项：

{
  "http.proxy": "http://127.0.0.1:7897",   // VS Code 自己的代理（端口换成你实际的）
  "http.proxyStrictSSL": false,
  "http.proxySupport": "on"
}

怎么判断：

http.proxy 为空、且系统又没开 TUN → VS Code 的扩展很可能在用真实 IP 联网 ❌
已填正确的本地代理端口，或你开了 TUN（网络层接管，应用设不设都走代理）→ ✅

一句话总结这节：应用是各自为政的——系统代理管不到的（VS Code、各类 AI 客户端、Electron 应用），都得单独确认。 想一劳永逸别一个个查，最稳的还是开 TUN（见文末），网络层全接管，谁都漏不了。

⑨ DNS 缓存：检查与清理

排查时如果遇到「域名解析到奇怪的 IP」「改了代理规则不生效」，多半是 DNS 缓存在作祟。清一下缓存能排除这类干扰。

Windows：

ipconfig /flushdns

macOS：

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

怎么用： 改完代理规则、或切换了 TUN / 系统代理后，先清一次 DNS 缓存，再回去重跑 ①⑤⑥ 的检测，避免被旧缓存误导。Windows 跑完会提示「已成功刷新 DNS 解析缓存」；macOS 正常无输出（需要输管理员密码）。

⑩ 今晚踩坑总结（每条都是检测时最容易翻车的点）

把上面散落的关键认知拧成一束，照着这几条，基本不会误判：

a. 系统代理模式只管「尊重系统 / env 代理的程序」。 浏览器走了，不代表终端走了。命令行工具（Claude Code 就是）、不少桌面 app 根本不读系统代理，会用真实 IP 裸连。要全接管，得开 TUN 模式 / 增强模式（虚拟网卡在网络层接管全部进程）。
b. curl 显示「连 7897」不代表 TUN 开了。 因为 curl 优先读 HTTP_PROXY / HTTPS_PROXY 环境变量，⑤ 那条永远显示走本地代理端口。必须用 ⑥ 的 --noproxy "*" 绕开 env 单独验 TUN 本体，看到 198.18.x.x 才算 TUN 真接管。这是最容易误判的一步。
c. 198.18.x.x = Clash TUN 的 fake-ip 网段。 检测时看到连接 / 解析落到这个段，就是 TUN 在工作；它不是真实公网 IP，是虚拟网卡给的占位地址。
d. 7890 / 7897 = Clash 默认代理端口。 老版本常用 7890，新版混合端口常是 7897；netstat / lsof 看连接、curl -v 看落点，都围绕这俩端口。换成你工具里实际监听的端口。
e. AI 域名（尤其 Claude）建议做「AI 环境隔离」。 把 api.anthropic.com、*.anthropic.com、claude.ai 单独拎到一个只含代理节点、兜底 REJECT 不回落直连的策略组——节点临时挂了宁可连不上，也绝不偷偷走直连泄漏真实 IP（这一瞬间的直连就足以触发风控）。这属于配置层，检测时顺带验一下「节点挂了会不会回落直连」。
f. *_PROXY 环境变量是梯子的，别误删。 检测时它们是重要线索，不是垃圾。HTTP_PROXY / HTTPS_PROXY / ALL_PROXY 删了会让命令行直接断网——本文只查不删，真要清理（区分哪些该清哪些该留）看文末那篇。

附：判定速查（照着比对，一眼定生死）

把三个关键证据凑齐，对上号就放心：

□ 终端出口 IP（curl api.ip.sb/geoip）   = 代理节点 IP / 境外地区，不是你本地宽带
□ --noproxy "*" 验 TUN（curl -v ...）   = Trying 198.18.x.x（TUN 真接管）
□ 浏览器出口 IP（打开 ip.sb）           = 跟终端一致，都是节点 IP
□ VS Code 集成终端出口 IP               = 跟系统终端一致，是节点 IP
□ curl -v api.anthropic.com 落点         = 代理端口 / 198.18.x.x，不是 anthropic 真实公网 IP

三条出口 IP 全一致、全是节点 IP + --noproxy 验出 198.18 + 落点不直连
  →  全程无泄漏 ✅

任意一条还是你真实宽带 IP  →  漏了 ❌  →  去开 TUN 模式整机接管，再给 AI 域名配 fail-closed 规则

检测的金标准就一句话： 终端出口 IP = 节点 IP，--noproxy "*" 验出 198.18.x.x，浏览器同 IP——三者对上，才是真·全程不漏。任意一处露出你本地真实 IP，就是没接管干净，赶紧去补。

查清楚「漏没漏」只是第一步。如果你查出来终端 / Claude 还在用第三方中转站、或环境变量里塞着来路不明的 token，那就得做一次彻底清理——怎么把这些残余从环境变量、配置文件、登录凭据里剥干净、回到官方正规订阅，见这篇姊妹篇：《如何彻底清理 Claude Code 残余：从第三方中转站回归官方正规订阅》。

检测 + 清理两篇配套用：先体检确认漏没漏，再对症清理。干干净净走官方，账号才坐得稳。