← Research

Tools · Playbook

代理就三步:进、分、出

Claude Code 的每个请求都走同一条路:进到 Clash 手里、被规则分流、从出口节点出去。连不上、断流、国内变慢、提示地区不支持——每个毛病都只会坏在三步之一。会按步定位,就不用每次都猜。

这背后的原理是什么? 读时~18 min
路线图

沿一个请求的生命周期走完五站

先搭好三步总模型,然后逐站拆开「进」「分」「出」,最后一站把全部原理折叠成一张排障表。

回答原问题 01 一张图 三步模型 02 进·三扇门 交接方式 03 分·规则 国内不慢 04 出·节点 地区与稳定 05 按层排障 现象到命令
Roadmap. 横轴是一个请求的旅程;橙色站把前四站的原理收成一张「现象 → 哪步 → 命令」的排障表。

一张图:从敲下回车到 Anthropic 回话

先对齐两个名词。你装的「Clash Verge Rev」是一层操作界面,真正干活的内核叫 mihomo4;下文统称 Clash。你买的「机场订阅」给的是一批海外服务器,叫节点。

你机器上每个要出门的请求,都走同一条路:第一步——流量想办法交到 Clash 手里,一共三扇门,下一节细讲;第二步——Clash 的规则引擎看一眼目的地,国内的放行直连,国外的转给节点;第三步——该出国的流量从节点出去,节点在哪国,对方就认为你在哪国。

Claude Code 浏览器 其他 App ① 环境变量 ② 系统代理·关 ③ TUN 兜底 Clash 规则引擎 直连 国内网站 不出国 · 速度不变 美国节点 Anthropic 出口 IP = 美国
Fig 1. 三步旅程:进(三扇门之一,虚线表示你机器上系统代理是关的)→ 分(规则引擎)→ 出(直连或节点)。
先想一下

你机器上系统代理是关着的,浏览器自己也没填过任何代理设置。那它为什么照样能上 claude.ai?

试着先答

走的是门③ TUN。Clash 造了一张虚拟网卡,浏览器的流量在网络层被整张截走,根本不需要浏览器知道代理这回事。这也是 Fig 1 里第二条线画成虚线、第三条线照样画实的原因。

记住这个模型:进、分、出。后面三节一节拆一步,所有故障都能挂回这三个字上。

第一步「进」:三扇门,谁把流量交给 Clash

Clash 收流量有三种完全不同的方式。

门① 环境变量:一份君子协议

你在 .zshrc 里写的 export HTTPS_PROXY=http://127.0.0.1:7890,意思是「这个终端里启动的程序,请把网络请求交给本机 7890 端口」。这是 Unix 世界几十年的约定5:curl、npm、Python 的网络库都自觉照办7,Claude Code 的官方文档也明确说它认 HTTPS_PROXY3。但「自觉」是关键——不认这份协议的程序,会当这份协议不存在。协议还有一个例外名单 NO_PROXY:把 localhost 写进去,本地开发服务器(localhost:3000 这种)就不绕代理。

门② 系统代理:macOS 设置里的开关

系统级的代理设置,浏览器和多数 GUI 软件认它,命令行工具大多不理它。你机器上这扇门是关的——后面会看到,关着也没事。

门③ TUN:虚拟网卡,网络层全收

Clash 造一张虚拟网卡,操作系统把全机要出门的流量都先送到这张网卡上,Clash 在网络层直接接管——程序配没配代理、认不认协议,都逃不掉4。这是兜底门,你机器上是开的

谁认它管多宽你机器现状
① 环境变量命令行工具(含 Claude Code)只管这个终端开,指向 7890
② 系统代理浏览器、多数 GUI 软件认它的应用
③ TUN不需要谁认,网络层强制接管全机所有流量
Worked example

例:2026 年 6 月 5 日你机器上真实查出来的事。.zshrc 里有四行代理设置,其中一行指向 7897——这个端口后面没有任何程序在听。当时它碰巧被后一行的 7890 覆盖,所以一直没出事。假如哪天它生效:Claude Code 拿着协议去敲 7897 的门,门后没人,连接被拒绝,请求当场失败。

常见错答

「TUN 开着呢,环境变量乱写也无所谓,反正有兜底。」错在哪:三扇门有优先顺序。程序一旦认了环境变量,就只走那扇门;那扇门是死的,请求就死在「交给本机代理」这一步,根本没上路,TUN 截不到不存在的流量

反证

TUN 接管全机有代价:CPU 开销约 +5~8%,偶尔跟个别软件犯冲4,所以有人主张关掉 TUN、只靠环境变量加系统代理。这篇仍建议保持 TUN 开着:工具链里总有不认环境变量的程序,没有 TUN 它们会直接连不上;那点开销在近几年的芯片上感知不到。

环境变量的优先级高于 TUN 的兜底:终端程序被告知交给哪个端口,那个端口就必须活着。

第二步「分」:规则分流,国内为什么不变慢

很多人以为「国内不慢」是因为国内流量绕开了 Clash。恰恰相反:国内流量也全部经过 Clash,只是规则引擎看一眼目的地就放行直连。判断在本机内存里完成,耗时微秒级,肉眼不可感知——我在你机器上实测,百度直连 0.14 秒,跟没开 Clash 一个样。

规则是一张从上往下逐条匹配的清单6:前面是域名规则(如「百度的域名 → 直连」「anthropic.com → 走代理」),中间是地理规则(GEOIP,CN,DIRECT:目的地 IP 在中国就直连),最后一条 MATCH 兜底,没匹配上的全走代理。机场订阅自带一套维护好的规则,日常不用自己写。

Worked example

例:两个请求先后进了 Clash——

api.anthropic.com:域名规则没命中国内清单 → 地理规则查出 IP 在美国,不是 CN → 落到兜底 MATCH → 走节点出国。

www.baidu.com:命中国内域名清单(或 GEOIP,CN)→ DIRECT 直连,不出国,零额外延迟。

这套分流只在「规则」模式下生效。Clash 有三种模式,模式选错是「国内变慢」几乎唯一的原因:

模式行为后果
规则逐条匹配,分别处理国内快、国外通——日常唯一该用的
全局跳过规则,全部塞给节点国内网站绕道美国再回来,集体变慢
直连全部不走代理国外全断,等于没开 Clash
先想一下

假设明天国内网站集体变慢,但 Google 一切正常。三步里先怀疑哪一步?去哪验证?

试着先答

怀疑「分」——模式被切成了全局,国内流量在绕地球。打开 Clash Verge 主界面看模式那一栏,切回「规则」即可。注意这是三步里最不容易自己坏的一步:规则引擎不会无故失灵,几乎都是模式被人(或某次更新)误切。

国内不慢,靠的不是绕过 Clash,而是规则引擎看一眼就放行。模式永远留在「规则」。

第三步「出」:节点决定你是谁、稳不稳

地区:对方只看你的出口 IP

Anthropic 判断你在哪,看的不是你人在哪,而是出口节点的 IP 属于哪个国家。官方支持名单覆盖 175 个国家和地区,中国大陆和香港都不在名单上,台湾、日本、新加坡、美国在12。香港是 IP 层面直接拦截,访问即报「当前地区不可用」9 🟡 med。所以节点只从美国、日本、新加坡这类名单内地区里选。你现在的出口是美国圣何塞,实测 loc=US

稳定:长连接最怕中途换路

Claude Code 的回答是流式的:一条连接保持开着,文字一段段流过来,中间动辄几十秒没有数据8。这种长连接对中间环节的变动极其敏感——出口节点一换,这条连接就断 🟡 med,表现为「生成到一半卡住或报错」。Clash 的「自动选择」分组会定时测速换节点,网页浏览无感,对 Claude Code 是定时炸弹。

常见错答

「自动选择比手动智能,当然用自动。」错在哪:自动选择优化的是「每次新连接挑最快的」,代价是已经开着的长连接随时被掐断。看网页是几百个短连接,断一个无感;Claude Code 一次回答就是一条长连接,断了就是事故。手动固定一个延迟稳定的节点,比「最快但会变」的节点好得多。

地区决定能不能用,稳定决定用得顺不顺:手动固定一个美/日/新节点,不用自动选择,不碰香港。

按层排障:现象 → 哪步 → 验证命令

排障的第一问永远是分诊:浏览器还能不能翻墙?能,说明 Clash 和节点都活着,问题锁定在终端那扇门(进);不能,说明坏在 Clash 本身或节点(出)。

现象坏在哪步验证动作
Claude Code 连不上,浏览器翻墙正常进——门①死了echo $HTTPS_PROXY 看指向哪个端口;再用下方 curl 命令测端口
浏览器也上不了 Google出——Clash 没跑或节点挂了看 Clash Verge 在不在运行;换一个同地区节点
回答生成到一半断出——节点不稳或被自动切换把节点组从「自动选择」改成手动固定
国内网站集体变慢分——模式被切成全局Clash 主界面看模式,切回「规则」
提示地区不支持出——出口地区不在名单用下方 trace 命令看 loc= 是哪国

三条命令,全部排障靠它们

第一条,看终端把流量交给了谁:

echo $HTTPS_PROXY

第二条,验证「进分出」三步是否全通:

curl -o /dev/null -w "%{http_code}" -x http://127.0.0.1:7890 https://api.anthropic.com

返回 404好消息:404 的意思是「Anthropic 的服务器收到了请求,但这个地址没有页面」。能收到对方服务器的任何回应,就证明三步全通。真正的坏消息是 000(压根连不上)或长时间无响应。

第三条,看出口在哪国:

curl -sx http://127.0.0.1:7890 https://api.anthropic.com/cdn-cgi/trace | grep loc=

输出 loc=US 就是美国出口。看到 loc=HK 或其他名单外地区,立刻换节点。

你来补

场景:Claude Code 报连接错误;浏览器能正常开 YouTube;echo $HTTPS_PROXY 输出 http://127.0.0.1:7897。坏在哪一步?下一步敲什么命令验证??

对答案

坏在「进」——浏览器还能翻墙,说明 Clash 和节点都活着,问题锁定在终端那扇门。验证:curl -o /dev/null -w "%{http_code}" -x http://127.0.0.1:7897 https://api.anthropic.com。连接被拒绝,就坐实 7897 是个没人听的死端口——去 Clash Verge 设置里看真正的混合端口号(你机器上是 7890),把 .zshrc 里的环境变量改成它。

先分诊(终端的门,还是 Clash 和节点),再用三条命令对号入座——九成故障三分钟定位。

综合判断

你的机器已经是标准答案,剩下的是两条纪律

你现在的架构不需要改:规则模式分流(国内直连不变慢)、TUN 兜底(不认协议的程序也被接住)、终端环境变量直通(Claude Code 官方认可的方式3)、美国出口(名单内地区)。日常只守两条纪律:模式永远留在「规则」,节点永远手动固定在美/日/新。出了问题先问「浏览器还能不能翻墙」,把故障切成两半,再用第五节的三条命令对号入座。

这套判断什么时候会失效,提前知道三种情况:换了代理客户端或它改了端口(环境变量要跟着改,否则就是又一个 7897);进了有企业级代理的公司网络(三扇门之外多出一层,本文的分诊法失准);Anthropic 调整地区政策(名单以官方页为准1,别信过期攻略)。

关键不确定性

这些地方我说实话也没全把握

  • 「切节点必断流」是从长连接原理推出来的:公开资料确认流式连接对中间环节变动敏感8,但没有专门针对 Clash 自动选择分组的权威文档逐字背书这个结论。🟡 med
  • 香港被拦的官方原因没有公开,本文引用的解释来自第三方评论9,属于二手转述;「香港不在名单上」这个事实本身是官方的1🟡 med
  • 什么样的出口 IP 容易触发账号风控(机房 IP、频繁换地区),Anthropic 从未公布细则,业界说法全是经验之谈。🔴 low
自测

读完盖住,试着答这几题

  1. 「进、分、出」三步分别指什么?各自坏了是什么现象?

    试着先答

    进:流量交给 Clash 的三扇门(环境变量 / 系统代理 / TUN),坏了表现为「只有某类程序连不上」;分:规则引擎决定直连还是走节点,坏了(模式切成全局)表现为国内集体变慢;出:出口节点,坏了表现为全机翻墙失败、断流或提示地区不支持。

  2. 你机器系统代理是关的,浏览器为什么照样能上 claude.ai?

    试着先答

    门③ TUN:Clash 的虚拟网卡在网络层接管了全机流量,浏览器不需要任何代理设置。

  3. HTTPS_PROXY 指向一个没人听的端口,TUN 开着能救吗?为什么?

    试着先答

    救不了。程序认了环境变量就只走那扇门,请求死在「交给本机代理」这一步,没有流量真正发往外网,TUN 截不到不存在的流量。

  4. 国内网站集体变慢、Google 正常,按本文框架先查什么?

    试着先答

    查「分」:Clash 模式是不是被切成了全局。国内流量被全部塞给美国节点绕一圈,就是集体变慢的样子。

  5. 用 curl 走代理访问 api.anthropic.com 返回 404,是好消息还是坏消息?

    试着先答

    好消息。404 说明 Anthropic 的服务器收到了请求并回了话——「进分出」三步全通,只是这个地址没有页面。坏消息是 000 或超时。

把这几题截图,过两三天再凭记忆答一遍 —— 记得住才算真学会。

引用

Sources

  1. Anthropic — Supported countries and regions — https://www.anthropic.com/supported-countries
  2. Claude Help Center — Where can I access Claude? — https://support.claude.com/en/articles/8461763-where-can-i-access-claude
  3. Claude Code Docs — Enterprise network configuration — https://code.claude.com/docs/en/network-config
  4. Clash Verge Rev Docs — 名词解释(TUN 模式 / 系统代理 / mihomo) — https://www.clashverge.dev/guide/term.html
  5. everything curl — Proxy environment variables — https://everything.curl.dev/usingcurl/proxies/env.html
  6. Clash 知识库 — Rules 规则 — https://clash.wiki/configuration/rules.html
  7. HTTPX — Environment Variables — https://www.python-httpx.org/environment_variables/
  8. SpeedTestHQ — Streaming LLM Responses: SSE vs WebSocket vs HTTP Long Polling — https://speedtesthq.com/guides/ai/streaming-llm-responses-sse-vs-websocket
  9. doodhk — Why Claude Is Blocked in Hong Kong — https://doodhk.com/blog/why-claude-is-blocked-in-hong-kong-causes-context-and-alternatives/