TUN 模式与系统代理怎么选？全面对比
先说结论：日常刷网页、用常规桌面软件，打开系统代理就够了；只有当某些程序完全无视代理设置，或者你需要让整台机器的流量都走代理时，才有必要启用 TUN 模式。这两者不是“高级”与“低级”的关系，而是工作在不同网络层级的两种接管方式。
系统代理是操作系统层面的一条声明：告诉所有应用“要联网请走 127.0.0.1 的某个端口”，但应用可以选择不听。TUN 模式则是创建一块虚拟网卡，把系统的 IP 流量在网络层整体接管，应用没有绕过的余地，代价是需要更高的系统权限。
TUN 模式与系统代理对比表
| 对比维度 | 系统代理 | TUN 模式 |
|---|---|---|
| 工作层级 | 应用层，走 HTTP/SOCKS 协议 | 网络层，虚拟网卡接管 IP 数据包 |
| 覆盖范围 | 只覆盖读取系统代理设置的应用 | 系统绝大部分流量，应用无需配合 |
| 权限要求 | 普通用户权限即可 | 需要管理员／服务模式或系统授权 |
| DNS 处理 | 域名多由代理端在建立连接时处理 | 通常由内核接管解析，需正确配置 |
| 开启难度 | 一个开关 | 先装服务或授予权限，再打开开关 |
| 出问题时的表现 | 个别应用不通，其余正常 | 可能整机断网，影响面更大 |
| 典型用途 | 浏览器、常规办公与聊天软件 | 游戏、命令行工具、没有代理设置的客户端 |
覆盖范围的差异：自愿遵守与强制接管
系统代理的运作方式是“声明 + 自愿遵守”：客户端打开开关时，把本地监听端口写进操作系统的网络设置（默认混合端口可在客户端设置中查看，常见为 7890 或 7897），浏览器和大多数桌面软件会主动读取这份设置。
问题出在“自愿”两个字。有些程序压根不读系统代理：部分游戏客户端、使用自有网络库的桌面应用，以及很多命令行工具。命令行还有补救办法，临时导出环境变量即可：
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890但游戏和闭源客户端往往没有这种入口。TUN 模式解决的正是这一类问题：它创建一块虚拟网卡，通过路由把系统的 IP 流量导入内核，应用是否“愿意”走代理不再重要，它们看到的只是一块普通网卡。想了解虚拟网卡具体如何工作，可以读TUN 模式详解；系统代理的机制与局限，则在系统代理是什么里讲得更细。
稳定性、性能与排错难度的实际差别
两种模式的体验差异，更多来自链路上的环节数量，而不是谁“天生更快”。系统代理只处理应用交过来的 HTTP/SOCKS 请求，环节短、边界清楚；TUN 要在网络层拆解重组 IP 数据包，通常还要接管 DNS，任何一环配置不当都会表现为“连不上”。
排错难度也因此不同：系统代理出问题时影响面局限在具体应用，关掉开关就恢复；TUN 出问题往往是整机断网。它并非不稳，只是失败代价更大，所以系统代理能解决的场景不必急着全局接管。
提示：Android 上 CMFA、FlClash 弹出的“VPN 连接请求”本质上就属于网络层接管，系统已把权限流程标准化，手机端无需在两种模式间权衡。
按场景选择：什么时候才该开 TUN
- 只用浏览器和日常办公软件联网：系统代理足够，出问题也好排查。
- 某个程序无网络、浏览器却正常：它多半不读系统代理，开 TUN。
- 游戏、下载器、没有代理设置项的桌面客户端：TUN 是更省心的选择。
- 命令行工作流（git、curl、包管理器）：优先用环境变量。
- 要求“除内网外全部走代理”的整机接管：用 TUN，并在规则里放行局域网地址。
两个开关同时打开会怎样
很多人以为两个都开更保险，实际并非如此。应用先按系统代理把请求发往本地端口，这段本地流量又被虚拟网卡接管，链路凭空多绕一圈，配置不当时甚至可能出现回环。多数客户端会放行本地地址来规避死循环，但排查故障时仍应只留一个开关。
注意：另一个常见冲突来源是同时运行的其他 VPN 或加速器，它们同样会改动路由表和虚拟网卡，结果往往是谁都不通，遇到疑难先完全退出它们。更多典型报错见常见错误排查大全。
结论清单
- 默认从系统代理开始，它已覆盖绝大多数上网需求。
- 出现“个别程序不走代理”，才是开 TUN 的真正理由。
- TUN 需要更高权限：Windows 先装服务模式，macOS 与 Linux 按引导授权。
- 排错时只保留一种接管方式，不要让变量叠加。
- 关闭 TUN 后仍没网，检查系统代理设置是否留有残留。
模式选定之后，剩下的就是装好客户端、导入订阅。桌面端可以到下载中心获取 Clash Verge Rev（本站提供 2.5.2），它对两种模式都做了图形化封装，切换只需一个开关，界面细节随版本可能略有差异。