代理TUN模式和系统代理有什么区别？按场景选择

更新于 2026-11-03 · xcyun.buzz

简答：一句话结论：只用浏览器和能读取系统代理的常规应用，先用系统代理；如果命令行、Docker、游戏或其他应用不认系统代理，再考虑TUN。TUN通过虚拟网络接口和路由接管符合条件的IP流量，但并不等于无条件接管设备上的所有连接。遇到断网时，先关闭TUN并恢复原来的系统代理，再逐项排查。

定义：系统代理是应用主动读取的HTTP、HTTPS或SOCKS代理设置；TUN模式则通过虚拟网络接口和路由规则接收符合条件的IP流量，两者处于不同的流量接入层。

先看结论：你该开系统代理还是TUN？

本文是本站的商业推荐内容，推荐部分只用于说明可选服务入口；下面的判断标准、操作步骤和故障排查以公开技术资料为依据，不代表任何客户端或服务一定兼容。

这里的“优先”不是绝对规则。系统代理、TUN、规则模式和全局模式解决的是不同问题：系统代理与TUN决定流量如何进入客户端；规则、全局或直连决定进入客户端后如何选择出口。

系统代理和TUN分别是怎么工作的？

系统代理：应用主动来取设置

系统代理通常提供HTTP、HTTPS或SOCKS等代理地址。应用只有在读取系统代理、读取PAC配置，或自身支持对应代理设置时，才会把请求交给代理。微软文档也说明，不同应用获取代理设置的方式不同，未读取系统设置的应用可能需要在应用内部单独配置。可参考Windows代理设置说明。

因此，浏览器能打开并不代表所有软件都已经走代理。命令行工具可能需要设置HTTP_PROXY、HTTPS_PROXY或软件自己的代理字段；Docker还区分客户端、守护进程、构建过程和容器中的代理配置，不能只改一个位置。相关边界见Docker CLI代理文档。

TUN：系统把符合条件的IP流量送到虚拟接口

TUN模式通常创建虚拟网络接口，再通过路由、自动路由或DNS处理规则接收符合条件的流量。Mihomo文档将TUN列为一种入站方式，并说明它可用于自动路由、DNS劫持和按应用路由，但实际效果仍取决于路由表、防火墙、系统服务、应用自定义网络栈和客户端实现，不能简单理解为“所有流量都会被接管”。可参考Mihomo入站配置文档。

在Apple平台，Packet Tunnel Provider可以使用虚拟网络接口，并通过包含路由和排除路由决定哪些IP目的地进入隧道；Apple也明确说明，系统路由、特定网络接口和例外规则可能影响最终路径。可参考Apple Packet Tunnel Provider文档和Apple VPN流量路由文档。

两者最容易混淆的五个区别

表中的“覆盖更多”不代表“覆盖全部”。例如，应用可能使用自定义网络栈、绑定特定网络接口，或者受到系统服务和安全软件影响；Apple的路由文档也指出，系统路由和接口范围可能优先于隧道设置。

按应用类型选择：浏览器、命令行、Docker和游戏

1. 浏览器能用，命令行不能用：先确认命令行程序是否支持系统代理；如果不支持，按该工具文档设置HTTP_PROXY、HTTPS_PROXY、ALL_PROXY或应用内部代理。测试完成后，删除临时环境变量，避免影响后续直连请求。
2. Docker不能用：不要只看桌面系统代理。检查Docker客户端、daemon、构建阶段和新容器分别使用的配置。Docker官方文档特别提醒，容器代理环境变量与Docker CLI或Engine本身的代理设置不是同一层。
3. 游戏或自带网络设置的应用不能用：先查看应用是否有独立代理、网络接口或启动参数。若没有可用的代理入口，再考虑TUN；开启前记录当前代理和DNS设置，以便回退。
4. 聊天软件或商店应用异常：不要直接判断是TUN或系统代理“失效”。先分别关闭TUN、关闭系统代理，确认是哪一个开关改变了现象；Windows文档也提示，不同类型应用对代理配置的读取方式可能不同。
5. 手机端需要TUN：先确认客户端是否要求系统VPN授权，以及是否有其他VPN、企业管理配置或Private DNS。权限页面、菜单名称和可用模式会随系统与客户端版本变化，找不到入口时应以客户端帮助文档和系统当前提示为准，不要照搬其他版本的配置文件。

开TUN前后的四步验证与安全回退

1. 记录现状：记下系统代理是否开启、客户端当前模式、DNS设置、其他VPN状态，以及出现问题的具体应用。不要同时修改MTU、DNS和路由，否则难以判断原因。
2. 只开一种接管方式：先关闭TUN，仅测试系统代理；再关闭系统代理，仅测试TUN。这样可以区分是入口未生效，还是规则、节点或DNS导致失败。不同客户端对是否自动写入系统代理的行为不同，应以状态栏或设置页显示为准。
3. 验证三件事：第一，浏览器或目标应用是否恢复连接；第二，客户端日志是否出现连接或DNS错误；第三，查看系统路由、DNS或应用代理状态是否发生预期变化。只查看公网IP不能证明每个应用都走了同一条路径。
4. 出现断网时回退：先关闭TUN或断开VPN，恢复原来的系统代理设置，再重启目标应用。若仍异常，暂时关闭客户端的自动代理切换，检查其他VPN、虚拟网卡、防火墙和DNS设置；不要先执行网络重置，因为它可能清除已有网络配置。

如果TUN开启后只有部分应用仍直连，重点检查应用是否绑定了特定接口、是否使用独立代理设置、是否被规则设为直连，以及DNS请求是否走了预期路径。Mihomo文档还说明，DNS劫持在不同系统、网络接口和Private DNS条件下存在限制，因此不能仅凭“开启了DNS模式”推断所有DNS请求都已被接管。

常见问题

系统代理和TUN可以同时开启吗？

技术上是否能同时运行取决于客户端和系统实现，但不建议把它作为第一种排障方案。两者同时开启会增加重复代理、路由循环、DNS路径不清和回退困难的可能。先只保留一种接管方式，确认目标应用能连接后，再根据客户端文档决定是否需要另一种。

TUN是不是一定比系统代理快？

不能这样判断。TUN和系统代理主要是流量接入方式，不直接等同于线路质量、节点延迟或吞吐能力。速度变化可能来自路由、DNS、协议、规则和应用本身；没有同一设备、同一目标和同一时间的可复现实验，就不应声称哪一种一定更快。

为什么浏览器能用，但Git、npm或Docker不能用？

常见原因是这些工具没有读取系统代理，或者它们的代理配置独立于桌面系统。先按工具文档设置代理环境变量或应用字段；Docker还要区分客户端、守护进程、构建阶段和容器配置。完成测试后，清理不再需要的环境变量或代理项。

TUN开启后断网，应该先改DNS还是先重置网络？

先不要重置网络，也不要同时改DNS和MTU。优先关闭TUN、断开其他VPN、恢复原系统代理，再重新打开目标应用验证。如果恢复，再逐项开启TUN、DNS或规则功能，每次只改变一个变量。

系统代理能处理UDP吗？

不能用一句“支持”或“不支持”概括。要看代理类型、客户端实现和应用是否使用该代理接口；很多应用可能绕过系统代理。若应用明确需要UDP，应查看客户端和协议文档确认，不能仅凭系统代理开关的状态判断。

常见问题

系统代理和TUN模式可以同时开启吗？

是否兼容取决于客户端和系统实现。排障时建议先只开启一种，确认连接正常后再按客户端文档决定是否同时使用。

TUN模式是不是一定比系统代理快？

不是。两者是不同的流量接入方式，速度还受线路、节点、DNS、协议、规则和应用影响，不能据此承诺哪一种一定更快。

为什么浏览器能用，但Git、npm或Docker不能用？

这些工具可能不读取系统代理，或使用独立的代理配置。先按工具文档设置环境变量或应用字段，Docker还要分别检查客户端、daemon、构建和容器配置。

TUN开启后断网怎么办？

先关闭TUN或断开VPN，恢复原来的系统代理设置，再测试目标应用。不要一开始就重置网络或同时修改DNS、MTU和路由。

系统代理支持UDP吗？

不能一概而论，取决于代理类型、客户端实现和应用是否使用该接口。需要UDP的应用应查看对应客户端和协议文档。

相关阅读

• Clash连接不上网时的系统代理、DNS与TUN排查
• 代理开了但只有部分应用能用的排查方法
• 浏览器开代理后没网的端口、模式与DNS检查
• 代理DNS设置前先区分需求与验证路径
• 按延迟、丢包和兼容性比较网络加速服务

参考资料

1. Microsoft Learn：Configure proxy server settings in Windows
2. Docker Docs：Use a proxy server with the Docker CLI
3. Mihomo Documentation：Inbound Configuration
4. Mihomo Documentation：TUN
5. Apple Developer：NEPacketTunnelProvider
6. Apple Developer：Routing your VPN network traffic