为什么浏览器能翻墙，终端里的 git、npm、curl 却不行？

很多用户第一次用 Clash 时会遇到一种「分裂」现象：Chrome 或 Edge 打开境外站点一切正常，但终端里跑 git clone、npm install、curl https://… 仍然超时或直连被墙。原因并不神秘——主流操作系统里的「系统代理」或「HTTP 代理」开关，主要影响遵守系统网络栈或 WinINet 机制的那类应用；而大量命令行工具默认并不会去读这张「代理地图」，除非你自己 export 一套 HTTP_PROXY / HTTPS_PROXY，或在每个工具的配置文件里写死代理地址。

于是你会看到两种常见补救：一是给 shell 配环境变量，甚至把配置写进 ~/.zshrc、CI 脚本、Docker build 参数里，维护成本随项目数量线性上升；二是干脆开「全局」——若全局只是「系统代理全开」，仍可能漏掉不少 CLI。TUN（虚拟网卡）模式走的则是另一条路：在更底层把符合策略的流量交给 Clash，让不感知代理的应用也被路由进同一套规则引擎，这正是「让 git、npm、curl 全部走代理」这句话在工程上真正落地的方式。

适用前提：TUN 解决的是出站路径问题；你仍需在客户端中载入可用的节点配置或订阅，并理解本地法规与所在单位网络政策。本站仅讨论客户端能力，不涉及具体商业线路。

TUN 模式到底是什么？用最短路径理解「虚拟网卡」

可以把 TUN 理解成系统在协议栈里挂上的一张虚拟网卡。应用程序照常发起连接到某个 IP —— 它不觉得自己走了「代理」，只是数据包会像经过普通路由一样流过这张网卡。Clash（及 Mihomo 等兼容内核）在 TUN 设备上截取、按规则重写或转发这些数据包，再根据你的 proxy-groups 与 rules 决定走 DIRECT 还是某个出站。

与「应用内嵌 SOCKS / HTTP 代理地址」相比，TUN 的边界更靠下：对应用透明，因此适用面更广；trade-off 是对系统路由、权限和公司安全软件更敏感。当你在 macOS、Windows、Android 上还跑着另一套全局 VPN（包括企业 EDLP、SDP 客户端）时，可能出现路由争用——这时需要谁在「最后一公里」掌权，往往需要读一遍两个软件的文档并排错。

顺带一提：市面资料里偶有 TAP 字眼，本质是二层桥接多一些场景；在现代 Clash 系客户端语境下，用户勾选的多半是用户态三层 TUN，与本文讨论一致。

三张「代理地图」：TUN、系统代理、环境变量怎么选？

系统代理（Mixed Port / 系统设置）

开启后，许多浏览器、部分桌面应用会跟着走 127.0.0.1:7890 一类本地端口。优点是侵入性低、无需管理员；缺点是对 CLI 覆盖不稳定，且无法统一处理「硬编码直连」或「自己解析 DNS 再连 IP」的程序。

环境变量 ALL_PROXY / HTTP_PROXY

对支持 libcurl、gRPC 封装、Node 的请求库等链路往往有效。git 可用 git config --global http.proxy；npm/pnpm/yarn 各自有 registry 代理配置。优点是可脚本化；缺点是「每个仓库、每台机器、每台 CI Runner 都可能不同」，而且有些工具只吃 SOCKS、不吃 HTTP，要反复试端口类型。

TUN 虚拟网卡

在策略与规则已经写好的前提下，一条命令不配也能「跟着 Clash 走」。这对以下场景格外省心：需要从终端访问境外 API、golang toolchain 下载 module、Rust rustup、Docker（视网络命名空间而异）、以及大量调用底层 socket 的小型工具。注意：若某程序显式绑定本机局域网或绕过策略列表，仍需结合规则和 DNS 逐项核对。

方式 典型覆盖 主要负担
系统代理 浏览器与部分桌面应用 CLI 常漏网；不靠系统栈的程序无效
环境变量 尊重代理变量的 CLI / 运行时 维护分散；协议类型与绕过列表易踩坑
TUN 绝大部分 TCP/UDP 流量（按规则） 权限与路由冲突；要结合 DNS 以防规则失效

如何把 TUN 开稳：权限、客户端与配置文件协奏

不同外壳（Clash Verge Rev、FlClash、mihomo-party 等）按钮名字略有出入，但底层都要调内核的 tun 段。你可以在 YAML 中看到类似：

tun:
  enable: true
  stack: system
  auto-route: true
  strict-route: false

stack 取 system / gvisor 等会因平台与内核而异；auto-route 为真时通常会尝试写系统路由，把「应由 Clash 接管的前缀」送进 TUN 设备。strict-route 为真时更接近「硬核全局」，误配容易导致局域网或内网联不通，新手可先从较宽松的组合入手，再配合分流规则微调。

  • Windows：首次启用常需管理员身份或允许安装内核驱动 / Wintun；若与安全软件发生冲突，可把 Clash 主程序加入放行名单并避免重复挂载多张虚拟网卡。
  • macOS：往往需要用户在「隐私与安全性」里同意网络扩展（Network Extension）；若系统仍拦截，检查是否与其他 VPN 的「全流量」互斥。
  • Linux：桌面发行版需具备创建 /dev/net/tun 的权限；在容器或受限命名空间里，不一定能真正把 TUN 抬进业务进程——这时退回代理端口或宿主侧代理更现实。
  • Android：许多客户端走系统 VPN 权限 等价于移动端上的「类 TUN」路径；与桌面相比，省电策略杀后台更值得留意。

git、npm、curl 实测心智模型：还需要单独配吗？

在TUN 工作正常且规则没有把目标流量标成 DIRECT 的前提下，以下工具通常不再需要为「翻墙」单独写一行代理：

  • curl：走系统 IP 路由与 TLS，按规则出站；可用 curl -v 观察解析到的地址与耗时。
  • git：https:// 与部分 git:// 场景均能纳入；若远端强制 SSH 自定义端口或被企业 MITM，问题往往落在密钥与证书一侧而非 TUN。
  • npm / pnpm / yarn：Node 侧的 HTTPS 请求会随路由进 Clash；若 registry 本就是国内镜像，应保持直连以降低延迟——这正是分流比「无脑全局代理」更聪明之处。

但有时你仍会保留环境变量：在关闭 TUN 时复用同一套终端习惯，或只允许某一工具走代理而其他保持直连。这与 TUN 并不冲突——只是别把两套机制配成互为环路的「代理链」即可，例如又让系统代理指向 Clash，同时 Clash TUN 把本机回路再次兜一圈。

# Examples only; mixed-port varies by profile
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890
npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890

别让 DNS 成为你的「隐性直连」短板

规则多数是先有域名语义、再看解析结果 IP。若 CLI 绕过 Clash DNS、直连接入运营商递归，可能出现解析到意想不到的 CDN 出口，进而误判 GEOIP 或 DOMAIN 规则。fake-ip、redir-host、fake-ip-filter 等条目会显著改变链路；当你发现「浏览器正常、CLI 跑偏」时，第一步请对比两者是否共用同一 DNS 链路，再在连接面板里抽查命中规则。

另一个常见落差是 NO_PROXY 环境变量写得太宽，把本应走代理的企业域或内网段整个排除在外；而 TUN 路径下若仍命中「直连例外」，多半来自规则优先于环境变量或应用级硬编码，需要回到 YAML 与客户端「绕过」列表核查。

常见问题速查

问：启用 TUN 后 ping 看起来很怪？
答：ICMP 与 TCP 路径未必一致；更可靠的是看 HTTP/TLS 级工具与应用日志。

问：WSL / 虚拟机里还要再开一次吗？
答：WSL2 的网络栈独立于 Windows host，常见做法是由 Windows 一侧集中提供 TUN 或代理端口，再在 WSL 内按需指路由或环境变量——具体组合与你的虚拟交换机配置绑定，无法一句话覆盖所有拓扑。

问：会不会拖慢局域网 NAS 或打印机？
答：请在规则靠前的位置显式放行内网段（如 RFC1918）、本机回路以及组播地址；strict-route 开得太激进时最易误伤。

为什么我仍推荐在同一套 Mihomo / Clash 规则上解决终端问题？

市面也存在「只靠终端 SOCKS 封装」的小型工具，但它们往往不包含完整规则 DSL，难以同时做到「npm 镜像直连、上游 registry 出境、公司内部域名兜底」这一类细颗粒度编排；另一些传统全局 VPN 一上来就整条隧道，想拆出「仅开发流量」非常痛苦。反观 Clash 系：规则、策略组与订阅结构都是明文可读，你可以把 TUN、系统代理、端口代理当成三种「踩油门的方式」，而真正决定车子往哪开的仍是同一发动机。

如果你更希望在一个界面里搞定订阅、TCP/UDP、hysteria2 / reality 等新协议适配，并让终端天然跟随分流，与其在多个单点代理工具之间疲于奔命，不如把精力花在一份维护良好的配置文件与仍在积极迭代的桌面 / 移动客户端上。相比之下，只靠系统代理兜底而反复给 shell patch，往往会在换新机器或新同事 onboarding 时再付一次隐性成本。若你正在为自己或团队整理一条可复制、可持续的翻墙与开发链路，从本站下载聚合维护的客户端版本，能比翻散落的历史发行页节省大量甄别时间：

前往下载页获取适合你系统的 Clash 客户端 →