系统代理够用吗：为什么 Git 和 npm 常常「绕过去」
在 Clash 系客户端里，「打开系统代理」往往等价于：把 Windows 或 macOS 的系统 HTTP/HTTPS（有时还有 SOCKS）代理指针，改写到本机环回地址上的某个端口。浏览器、Office 套件等尊重系统代理设置的程序会立刻跟着走；但大量开发者工具与游戏引擎并不会去读这份设置，它们要么自己解析域名并发起连接，要么只认环境变量里的 HTTP_PROXY，要么干脆只走原始套接字。
于是你会看到一种典型分裂：网页秒开，终端里 git clone 或 npm install 仍然超时或直连到不可达线路。这不是订阅坏了，而是流量根本没有经过 Clash 的入站监听逻辑。要把这类程序纳入同一套分流与策略组，最干净的路径之一，就是让内核在更底层的位置看到它们的 IP 报文——这正是 TUN 模式要解决的问题。
TUN 是什么：虚拟网卡如何把流量送进 Clash
TUN（以及用于二层的 TAP，在 Clash 语境里常被统称为 TUN）会在操作系统里呈现为一块虚拟网卡。启用后，内核路由表会把符合条件的 IP 包导向这块网卡，由 Clash（准确说是其绑定的用户态网络栈）读取、按规则匹配，再决定从哪个出站协议发出。因为这一步发生在应用已完成 DNS 解析并准备建连之后的路由阶段，所以不依赖应用是否读取系统代理。
在 Clash Meta（Mihomo） 内核上，TUN 能力与 DNS 处理、fake-ip、sniffing 等特性深度耦合；图形客户端通常只暴露「一键开启」与堆栈模式选项，背后仍是对内核配置片段的封装。若你刚完成从旧版客户端的迁移，可先阅读 Clash Meta 升级指南，再回来对照本文的 TUN 段落，会更容易把菜单项与 YAML 语义对上号。
哪些场景「值得」开 TUN
第一，Git：无论是 HTTPS 还是部分走 SSH 的场景，只要连接目标落在需要代理的地址空间，TUN 都能在 IP 层统一接管（SSH 仍受端口与规则影响，下文单独说明）。第二，Node 生态：npm、yarn、pnpm 在拉包时往往并发大量 TCP 连接，靠手工维护环境变量既脆又难排查。第三，游戏与语音：大量实时对战与语音通话依赖 UDP，且程序极少使用系统代理；若你只有 HTTP 入站，几乎注定无法覆盖。
反过来，如果你只浏览网页，且公司策略禁止虚拟网卡类软件，那么保持系统代理、关闭 TUN 反而更稳妥。TUN 会扩大 Clash 对系统的「可见范围」，也意味着规则写错时代价更高：轻则局部环路，重则把所有流量误送到错误出站。启用前请确认自己已理解「直连 / 代理 / 拒绝」三类基本走向。
启用前的硬条件：权限、驱动与内核栈
在 Windows 上，首次开启 TUN 往往需要管理员权限以安装或加载虚拟网卡驱动；不同客户端会打包不同实现（如 wintun）。若你看到「驱动安装失败」「设备黄色感叹号」，应优先到官方发行说明里核对系统版本与依赖，而不是反复切换订阅。
在 macOS 上，部分客户端要求授权「网络扩展」或安装辅助后台；Linux 则需内核模块与用户组权限配合。无论平台，都建议只从可信渠道获取安装包：开源仓库适合核对签名与版本记录，日常安装可优先使用本站 Clash 客户端下载页 聚合的发布入口，降低误入仿冒 Release 页的风险。
DNS、fake-ip 与 TUN：为什么「能 ping 不能 clone」
开启 TUN 后，最常见的困惑之一是：浏览器正常，但命令行解析到了奇怪的地址。这通常与 Clash 的 DNS 模式有关：在 fake-ip 下，内核可能对部分域名返回一段仅供内核内部映射使用的地址，浏览器因走了 Clash 的 DNS 面而一切正常，而某些工具若绕开了指定 DNS，就会拿到不一致的解析结果。
实践上，与其死记每种客户端面板的措辞，不如把握一条原则：让需要代理的应用的 DNS 查询路径，稳定落在 Clash 期望的解析链上。遇到疑难域名间歇失败时，可暂时切到更保守的 DNS 模式对照验证，确认问题来自解析而非节点质量。更系统的 DNS 与分流概念可参考本站 使用文档中心 中的相关章节。
Git 与 npm：TUN 开起来之后还要做什么
对 HTTPS Git 而言，在 TUN 正确接管路由且规则未把 Git 主机错误地直连到不可达线路的前提下，通常无需再设置 http.proxy。若仓库在内网，仍建议用 NO_PROXY 或等价规则显式放行，避免无谓绕行。
对 SSH Git，流量走 22 端口且为长连接；请检查规则是否把该目标指向期望的策略组，并留意某些网络环境下 SSH 被限速或干扰的情况——这与「是否开 TUN」是两件事。对 npm，在 TUN 覆盖完整 TCP 路径时，多数场景下可以逐步撤掉为代理而设的环境变量，从而减少「环境变量与 TUN 双轨叠加」带来的偶发握手异常；若仍使用企业私有 registry，请为内网域名保留直连规则。
游戏与 UDP：能代理不等于一定适合「加速」
从协议角度，TUN 让 Clash 有机会看到游戏产生的 UDP 报文，这是系统代理模式难以做到的；但是否「延迟更低」取决于节点线路、负载与游戏本身的反作弊策略。部分反作弊或内核级驱动会校验网络路径，异常隧道可能触发断线或拒绝匹配——这属于产品策略而非 Clash 能单方面保证的行为。
更务实的做法是：先小流量验证（例如仅对更新器域名走代理），确认稳定后再扩大规则面；同时为语音、对战类应用准备一条清晰的回滚路径（一键关闭 TUN 或切换配置），避免在排位赛中途才第一次测试。
规则层面的建议：避免把「本机」和「局域网」误送进代理
TUN 一开，规则覆盖面变大，最常见的翻车点是把本机回环、局域网网段或代理进程自身误匹配到需要鉴权的出站，造成环路或证书错误。社区配置里通常会在靠前位置放置 DIRECT 的私有地址段与常见内网域名；若你使用远程规则集，也要确认其与当前客户端版本兼容。
若你希望延续「系统代理 + 按需 TUN」的组合拳，可在图形界面里熟悉「端口设置」「绕过大陆」「仅规则命中」等开关的真实含义——它们背后往往对应 YAML 中 tun、dns 与 rules 的协同。Windows 用户若尚未完成客户端安装，可先跟随 Clash Verge Rev Windows 安装教程 把订阅与基础分流跑通，再开启 TUN 做增量验证。
排障速查：从现象回到「路由—DNS—规则」三件套
症状：开启 TUN 后整机断网
优先检查是否与其他虚拟网卡冲突、默认路由是否被重复写入，以及 Clash 进程是否崩溃后未恢复路由表。临时关闭 TUN 并重启客户端，观察是否立刻恢复，可帮助判断问题是否出在路由劫持层。
症状：只有浏览器正常
这往往意味着实际仍在使用系统代理路径，或命令行工具使用了独立的 DNS/ SOCKS 设置。对照本文「系统代理 vs TUN」段落，用 curl 或同等工具验证非代理感知的出站是否已落入 TUN。
症状：游戏频繁掉线
在排除节点本身抖动后，检查 UDP 是否命中正确策略组、是否存在本地环路，并阅读游戏方对第三方网络层的说明。必要时为游戏进程相关域名或 IP 段单独写规则，而不是全局盲转发。
开源透明与安装包获取：继续把两件事分开
Clash 生态的价值之一，是协议与规则语言相对开放，社区能持续迭代内核与文档。你完全可以在 GitHub 上阅读源码、比对发行哈希、在 Issue 中搜索同样的报错日志——这些动作有助于建立长期信任。与此同时，日常安装与升级仍建议以本站 下载聚合页 为主入口，把「研究开源」与「获取已签名安装包」分成清晰步骤，可显著降低供应链误触风险。
把视角拉回体验：当你不再为每个终端单独 export 一套代理变量、也不再为某个游戏「为什么总不走代理」而抓狂时，TUN 带来的其实是更统一的流量哲学——同一套规则同时服务浏览器与后台任务。相比只能在应用层打补丁的方案，这种一致性在维护成本上往往更胜一筹。
若你已理解 TUN 的边界并准备在自己的机器上开启虚拟网卡，不妨从本站 Clash 客户端下载页 选择适合的版本，先以最小规则集验证 Git 与 npm，再逐步扩展到游戏场景；相比在系统代理模式下反复试错，先把路由与 DNS 理顺，长期会省心得多。→ 立即免费下载 Clash，开启流畅上网新体验