系统代理和 TUN 模式怎么选？六个真实场景逐个对照

上一篇讲了 TUN 的原理，这篇只回答一个问题：你的具体情况下，该开哪个。

先把结论表放在最前面。

下面逐个说清楚为什么。

场景一：日常浏览网页

只开系统代理就够了。

浏览器（Chrome、Edge、Firefox）默认跟随系统代理设置，开一个开关全都覆盖。TUN 在这个场景下不提供任何额外收益，反而多占 CPU、多一层 DNS 处理。

场景二：Steam / 战网 / Epic 下载慢

必须开 TUN。

游戏平台的下载器基本都直接走 socket，完全无视系统代理设置。你会看到一个典型现象：浏览器能打开 Steam 商店页面（走了代理），但下载速度只有几十 KB（下载器没走代理，还在挤原本的国际出口）。

场景三：命令行工具卡住

git clone 卡在 0%、npm install 一直转、docker pull 超时——这些工具都不读系统代理。

有两条路：

路线 A：开 TUN，一劳永逸，所有命令行工具自动生效。

路线 B：设环境变量，更轻量，不用装虚拟网卡：

# PowerShell（当前会话有效）
$env:HTTP_PROXY="http://127.0.0.1:7897"
$env:HTTPS_PROXY="http://127.0.0.1:7897"

# Git 单独配置（永久）
git config --global http.proxy http://127.0.0.1:7897
git config --global https.proxy http://127.0.0.1:7897

# npm
npm config set proxy http://127.0.0.1:7897
npm config set https-proxy http://127.0.0.1:7897

Docker 比较特殊：容器内的 127.0.0.1 指向容器自己，不是宿主机。需要用 host.docker.internal 或者直接开 TUN。开 TUN 是最省事的做法。

场景四：流媒体（Netflix / Disney+ / HBO）

开系统代理即可，TUN 不需要。

网页端和桌面客户端都跟随系统代理。真正影响解锁的不是 TUN，而是：

场景五：联机对战游戏

开 TUN，但要有心理预期。

游戏需要 UDP，系统代理不处理 UDP，所以只能靠 TUN。但注意：

• 节点必须支持 UDP 转发（很多低价节点不支持或做了限制）
• 多绕一跳必然增加延迟，除非你的节点是 IPLC/IEPL 专线
• 部分游戏的反作弊会对虚拟网卡有反应

场景六：公司配发的电脑

慎开 TUN。

企业电脑上通常装了终端安全软件（EDR）、VPN 客户端、或者域策略。TUN 会创建虚拟网卡并改路由表，容易出现三类问题：

1. 与公司 VPN 抢路由，导致内网访问不了
2. 被 EDR 判定为可疑网络行为并上报
3. 域策略强制的代理设置与 Clash Verge 冲突

如果确实需要用，建议：

• 只开系统代理，不开 TUN
• 在规则里把公司内网域名和 IP 段明确设为 DIRECT
• 先跟 IT 部门确认是否允许

三种组合的实际表现

差距不大，现代电脑基本无感。真正的差别在行为复杂度上：TUN 开着的时候，一旦出网络问题，需要排查的层次会多一层。

一个折中方案：只开 TUN，关掉系统代理

如果你既要游戏又要浏览器，可以试试这个组合：

• TUN 开
• 系统代理关

好处是所有流量走同一条路径，行为统一，排查简单。副作用是某些明确写死「读系统代理」的软件可能表现不同，另外浏览器插件里的代理设置可能会绕过 TUN（比如 SwitchyOmega）。

小结

不确定的时候，从系统代理开始，缺什么补什么，比一上来就全开要好排查得多。

延伸阅读：TUN 模式原理详解、局域网共享代理。