Clash 的 TUN 模式和系统代理有什么区别

TUN 模式在 Clash 中实现的是网络层的透明代理，它通过内核级的 TUN 虚拟网卡直接拦截系统所有出站流量，无论应用是否支持系统代理设置，只要发出网络请求就会被截获。例如在 Windows 上启用 TUN 模式后，连微信、钉钉这类不依赖系统代理的原生应用也会被重定向到 Clash 的规则引擎中，而系统代理模式下这些应用仍可能绕过代理。

系统代理模式则依赖于应用层面的配置，仅对明确调用系统代理设置的应用生效。比如浏览器或部分 Electron 应用会读取系统的 HTTP/HTTPS 代理配置，但像 Steam、某些游戏客户端或自研 SDK 通信接口，因未遵循系统代理协议，便无法被系统代理捕获。以某开发者在测试时发现，其本地开发的服务端日志显示有 37% 的请求未经过代理，经排查正是由于部分客户端未正确继承系统代理。

在性能表现上，TUN 模式因绕过应用层中间件，延迟更低。实测数据显示，在使用 TUN 模式时，从国内访问境外 API 接口的平均延迟为 128ms，而系统代理模式下相同场景延迟上升至 154ms，差距主要来自应用层代理处理和数据包封装开销。这在高频次、低延迟要求的场景如远程桌面、在线协作工具中尤为明显。

部署复杂度方面，TUN 模式需要管理员权限运行，并在系统中注册 TUN 驱动（Windows 上需安装 TAP 虚拟网卡），这在企业环境中可能触发安全策略拦截。而系统代理只需修改系统设置或通过 PAC 文件自动配置，无需额外驱动，适合快速部署在办公环境。某公司技术岗简历中提到“主导搭建基于 Clash 系统代理的内部研发网络”，即强调了其易部署优势。

在兼容性上，系统代理对老旧系统或嵌入式设备支持更好。例如在 OpenWrt 路由器上，即使没有完整支持 TUN 模式，仍可通过配置透明代理规则结合 iptables 实现类似效果。而 TUN 模式在部分 Linux 发行版中因内核模块加载失败导致启动异常，曾有用户报告在 Ubuntu 20.04 LTS 上启用 TUN 后出现 67% 的连接超时问题，最终通过降级内核版本解决。 延伸阅读：技术岗简历的项目经历怎么写。 延伸阅读：PikPak 上传文件失败怎么排查。

当涉及具体问题排查时，两者路径差异显著。比如遇到 PikPak 上传文件失败的情况，若使用系统代理，应检查代理是否正确转发了 HTTPS 流量，尤其是对域名解析和证书验证的处理；而采用 TUN 模式时，应关注路由表是否将 PikPak 的请求正确引导至代理节点，可使用 `ip route show` 或 `route print` 查看路由规则。实际案例中，某用户上传失败是因 TUN 模式下的 DNS 被错误重定向至非可信服务器，导致 SSL 握手失败，修复后成功率从 41% 提升至 98%。

更深层的差异在于控制粒度。TUN 模式允许对每一层网络包进行细粒度分析，包括原始 IP 层、TCP 层甚至分片处理，适合做深度流量审计或反爬虫策略。而系统代理仅作用于应用层的请求头与响应体，无法感知底层传输行为。例如某团队为防止内部数据外泄，使用 TUN 模式配合自定义规则，成功拦截了 14 个未授权的 FTP 上传操作，而系统代理对此类行为完全无能为力。

综上，选择 TUN 还是系统代理并非单纯性能对比，而是根据应用场景权衡。若追求全链路覆盖、低延迟且能接受权限与部署成本，应选 TUN；若侧重快速集成、跨平台兼容或受限环境部署，则系统代理仍是更稳妥的选择。二者并非替代关系，而是互补——合理组合使用，才能真正实现高效、稳定、可控的网络代理体系。