系统代理、规则、全局和 TUN：怎么组合与恢复网络

“开了代理还没有效果”和“开了全局为什么游戏仍直连”经常来自同一个误会：把接管方式和转发模式当成同一开关。理解这两层后，就可以用一次请求判断问题所在，而不必同时反复切换所有选项。

开始前保留一份能工作的配置，记录客户端端口、当前系统代理、DNS 和已有 VPN。准备一个正常网站、一个需要代理的网站和实际遇到问题的应用。一次只运行一个负责接管网络的代理或 VPN，避免路径相互覆盖。

第一层：流量如何进入内核

接管方式	实际行为	适用范围与边界
应用内代理	在应用中直接指定 HTTP/SOCKS 地址	只作用于该应用；应用可能另有 DNS 与绕过策略
系统代理	系统公布代理地址或 PAC 规则，由应用读取	浏览器等通常支持，但游戏、部分终端工具和服务可能不读取
TUN	创建虚拟网络接口，并按系统路由接收 IP 流量	可覆盖更多应用和 UDP，受路由范围、权限、内核支持、排除项及 DNS 配置约束

系统代理不是对网络接口的强制拦截。某个程序忽略设置时，把规则模式切成全局，程序仍不会自动进入内核。

TUN 也不是无条件覆盖全部流量：本地网段、指定进程、IPv6 或其他网卡可能被排除；Android 等平台上的系统 VPN 接口也有自己的限制。具体行为要看所用客户端与内核版本，不能只用开关颜色判断。

第二层：进入内核后走哪里

下面以 mihomo 的常见命名说明。其他内核或图形客户端可能采用不同名称与实现。

转发模式	已接管连接的行为	合适的使用时机
规则 rule	依规则顺序决定代理组、直连或拒绝	日常分流，同时照顾本地与代理目标
全局 global	交给 GLOBAL 组当前选择的出站	临时排查规则漏判；须确认 GLOBAL 实际选了什么
直连 direct	交给直连出站	临时验证代理出口是否造成问题

全局组可以选到其他策略组，甚至直连项，所以“全局”名称本身不能证明用了哪个节点。直连模式也不等于关闭内核：流量仍可能经过它，DNS 仍可能按当前配置工作。

常见组合是“系统代理 + 规则”或“TUN + 规则”。“TUN + 全局”只表示尽可能接管符合路由范围的流量，再把这些连接交给全局出站，仍有明确边界。

用三组对照定位问题

对照一：显式代理是否能工作

固定一个节点，确认内核启动。以下命令明确把请求交给本地 HTTP/mixed 端口；把 7890 换成实际端口。Windows PowerShell 使用 curl.exe。

curl -q --noproxy localhost --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

example.com 是公开示例网站，可换成你的公开失败目标。--noproxy localhost 覆盖环境中的绕过列表，测试目标不要换成 localhost。收到 HTTP 响应表示这次请求已经走通；如果目标不接受 HEAD，去掉 -I 对照。连接不到 127.0.0.1 表示先查本地监听，节点认证失败则先查节点，DNS 报错转入 DNS 排查。

这里显式指定了代理，不能用结果反推“系统代理已生效”。终端工具也不一定自动读取操作系统代理设置。

注意区分本地代理的 200 Connection established 与目标网站响应：前者只表示 CONNECT 隧道被接受，后面仍可能出现 TLS 或目标连接错误。验证应同时包含目标响应、无传输错误，以及客户端记录的预期出站。

对照二：应用是否进入内核

1. 保持同一节点与规则模式，打开系统代理。
2. 清理客户端连接显示或记下当前时间，使用目标应用发起一条新连接。
3. 在连接记录中查找目标域名、IP 或进程；旧连接可能继续复用，应关闭对应页面或重启目标应用再试。
4. 若显式代理成功、目标应用没有连接记录，查看应用内代理、系统代理绕过列表、浏览器扩展或 PAC；应用不支持时再考虑 TUN。

若记录里有目标且走了错误出站，接管已成立，下一步应查规则，而不是反复重装虚拟网卡。

对照三：区分规则问题与接管问题

保持接管方式与节点不变，短暂切到全局并确认 GLOBAL 选中同一可用节点，再访问同一目标。

对照结果	初步判断	接下来做什么
规则失败，全局成功，均有连接记录	规则、策略组或按规则选择的 DNS 可能不同	查看原先命中的规则与出站，修正后切回规则模式
规则和全局都无连接记录	应用尚未进入内核	处理系统代理或 TUN 的接管范围
两种模式都有记录，都失败	可能是节点、DNS、认证或目标故障	按日志阶段排查，换节点作单变量对照
只有开启 TUN 后应用才有记录	应用未使用原来的代理设置	验证 TUN 下的 DNS、UDP 与业务功能

这些结果是定位线索，不是单次测试的最终定论。全局切换也可能改变 DNS 连接路径，需要同时查看 DNS 日志。

何时需要 TUN，如何验收

如果应用可以直接填写代理，先验证应用内设置；如果应用不支持代理，或需要代理 UDP，再考虑 TUN。开启前先关闭其他 VPN，确认客户端有必要的系统服务或权限，不要一开始就修改 MTU、协议栈和路由表。

按下面的顺序验收：

1. 检查基本网页。 一个直连目标和一个代理目标都能打开，连接记录与预期规则一致。
2. 检查实际应用。 登录、消息、下载、语音或游戏连接各按需要验证。网页能打开不能证明 UDP 转发正常。
3. 检查本地资源。 路由器管理页、内网 DNS、打印机等按原需求可访问；有失败时核对局域网与内网域名的排除策略。
4. 检查切网。 Wi-Fi 与有线或移动网络切换后，接口选择、DNS 和新连接仍正常。
5. 检查退出。 关闭 TUN 与系统代理后正常退出，原本可以直连的网站仍能打开。

如果出现循环连接、CPU 异常升高或全网断开，先关闭刚开启的 TUN，恢复上一份配置。多个接管程序互相导流时，增加新规则通常不能解决根本问题。

客户端退出后怎样恢复网络

能重新打开客户端时，先恢复原配置，关闭 TUN、关闭系统代理，再正常退出。随后检查以下设置：

• Windows：设置 → 网络和 Internet → 代理。检查手动代理和脚本地址是否仍指向停止的客户端；企业下发的设置应按原环境保留。
• macOS：系统设置 → 网络 → 当前网络服务 → 详细信息 → 代理，检查 HTTP、HTTPS、SOCKS 和自动代理配置；同时核对当前网络服务的 DNS。
• Linux：检查桌面网络代理设置，以及终端里是否保留了自己设置的 http_proxy、https_proxy、all_proxy；它们与桌面开关可能彼此独立。
• Android / Apple 移动平台：在客户端中断开，并检查系统 VPN 状态；若曾手动改过 Wi-Fi 代理、DNS 或私人 DNS，恢复原值。

只撤销本次操作引入的设置。系统 DNS 如果仍指向已经停止的本地监听地址，应恢复先前的自动或指定 DNS；不要把公司内网 DNS 直接换成公共 DNS。仍有残留时，重启相关网络服务或设备，再核对是否有另一个客户端自动启动。

完成的标准是：正常运行时目标应用按预期分流，退出后直连网络可以恢复。针对“系统代理开了却没作用”的详细流程见 系统代理不生效排查；想评估已连通线路的质量，下一篇是 线路测速与记录方法。