先按应用选择接管方式

只需要浏览器、遵循系统代理设置的桌面应用联网时，先用系统代理。需要接管不读取代理设置的程序、部分游戏或 UDP 流量时，再考虑 TUN。TUN 的覆盖范围通常更广，但是否接管成功，还取决于路由、权限、DNS 和其他 VPN 的影响。

两者解决的是“流量怎样进入内核”，不是“流量最终走哪个节点”。进入 Clash 或 mihomo 后，仍然要经过规则与策略组。开启 TUN 不等于开启全局代理；规则命中 DIRECT 的连接依然直连。

系统代理与 TUN 的接管原理

系统代理：应用主动连接本地端口

系统代理通常向操作系统登记代理地址，例如 127.0.0.1:7890。读取该设置的应用，会把请求交给本机监听端口。HTTPS 网站一般通过 HTTP 代理的 CONNECT 方法建立隧道，这不代表网站连接被降级成 HTTP。

应用是否读取系统设置，由应用使用的网络库决定。有的命令行工具只读取 HTTP_PROXY、HTTPS_PROXY 等环境变量；有的应用使用自己的代理选项。Windows 中常见的用户代理设置与 WinHTTP 设置也不是同一套，服务进程不一定遵循桌面用户的代理。

TUN：路由把 IP 数据包送入虚拟网卡

TUN 建立三层虚拟网络接口，再通过路由把符合条件的 IP 数据包交给内核。应用不必理解 HTTP 或 SOCKS 代理，因此原本直接建立 TCP、UDP 连接的程序，也可能被纳入分流。

这不是自动覆盖一切。已有的更具体路由、其他 VPN 的策略路由、网卡绑定、IPv6 设置，都可能改变实际路径。TUN 也不意味着所有协议都能被代理；UDP 还需要所选出站节点和服务端支持，不能把 TCP 可用直接推定为 UDP 可用。

比较项目系统代理TUN 模式
接管入口应用主动连接 HTTP 或 SOCKS 监听端口系统路由把数据包送入虚拟网卡
应用要求需要支持代理设置或显式指定代理通常不要求应用提供代理选项
UDP 流量常见系统 HTTP 代理设置不接管普通 UDP可接管，但还取决于出站与路由支持
运行权限监听普通本地端口通常不需要管理员权限通常需要提权、服务模式或网络管理权限
DNS 行为应用可能仍使用系统 DNS，也可能交给代理解析可配合 DNS 劫持与内置解析器统一处理
主要冲突点端口占用、应用忽略系统设置VPN 路由、虚拟网卡、DNS、防火墙

DNS 是两种模式的关键差异

“网页能打开”不能证明 DNS 也按预期处理。系统代理开启后，某些应用仍会先向操作系统查询域名，然后再连接代理；其他应用会把域名直接交给代理。SOCKS 的本地解析与远端解析也有区别，测试时必须说明具体方式。

端口 53 劫持与加密 DNS 的边界

mihomo 的 dns-hijack 可以把匹配的传统 DNS 请求转给内置 DNS。常见的 any:53 针对 UDP 53，若还要处理 TCP 53，可另加 tcp://any:53。这不等于自动识别所有域名查询。

浏览器的 DoH 使用 HTTPS，DoT 通常使用 TCP 853，DoQ 通常使用 UDP 853。它们不会仅因配置了端口 53 劫持就改由内置 DNS 解析。连接本身可能进入 TUN，但加密查询内容不等于交给了内核 DNS；按域名分流的效果还取决于域名映射与嗅探配置。

fake-ip 返回地址不等于解析错误

启用 fake-ip 后，内置 DNS 可返回映射地址，常见范围为 198.18.0.0/16，再由内核把后续连接关联到原始域名。看到 198.18.x.x 不应立即更换 DNS。需要确认应用是否仍由 TUN 接管，以及映射是否有效。

  • 切换 DNS 模式后，关闭并重新打开测试应用，避免继续使用旧连接和旧缓存。
  • Windows 可执行 ipconfig /flushdns 清理系统解析缓存，但浏览器可能仍有独立缓存。
  • 局域网设备名、企业内部域名应使用可达的内部 DNS；不要直接把所有查询都交给公共解析器。
  • IPv4 测试正常而 IPv6 失败时，应分别检查 IPv6 路由与 DNS 返回结果，不能只检查 A 记录。

mihomo 配置与启用步骤

先保留一份可正常使用的配置，再修改接管方式。下面是字段合并示例，不是完整订阅；保留现有的 proxies、proxy-groups 和 rules。如果原文件已有 tun 或 dns，应合并到原有映射中，不能重复建立同名顶层字段。

先确认本地代理入口

mixed-port: 7890
allow-lan: false
mode: rule

mixed-port 让 HTTP 与 SOCKS 共用端口。allow-lan: false 用于不向其他局域网设备开放代理服务；TUN 接管本机流量，并不要求开启局域网访问。这里的 mode: rule 保留规则分流，不能替代节点和规则本身。

再合并 TUN 与 DNS 字段

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

示例中的两个公共 DNS 地址是明确的上游配置示例，不代表适合所有网络。企业内网、校园网或有特定解析策略的环境，应按实际需求设置上游与域名解析策略。listen 的 1053 是内置 DNS 监听端口，不是系统代理端口，也不会仅靠该字段把系统 DNS 自动改成这个端口。

  • stack: mixed 选择混合协议栈。支持情况以内核为准，遇到兼容问题时再对照内核文档比较其他栈。
  • auto-route: true 请求自动配置流量进入 TUN 的路由，不代表其他 VPN 的路由一定会让位。
  • auto-detect-interface: true 用于自动识别出口接口。多网卡、热点与 VPN 共存时，应检查实际出口。
  • dns.enable 与 tun.enable 是不同开关。TUN 已开启，不代表内置 DNS 必然开启。

按顺序启动并验证

  1. 确认现有节点在系统代理下可用，再暂时关闭其他 VPN，记录原有网络设置。
  2. 按客户端要求安装服务或授予管理员权限，启用 TUN。移动端则通常需要批准系统 VPN 授权。
  3. 重新加载配置，检查启动日志是否出现字段错误、权限不足、网卡创建失败或端口占用。
  4. 暂时关闭系统代理，只保留 TUN，分别测试浏览器与原本不遵循代理设置的应用。
  5. 查看连接记录中的目标、命中规则和最终策略，确认流量不仅进入内核，而且走向正确。

用两组测试区分端口与路由问题

测试时一次只改变一个条件。下面命令使用同一个 HTTPS 地址，比较显式代理与不使用应用层代理的路径。Windows PowerShell 建议使用 curl.exe，避免部分环境中的 curl 别名影响参数。

测试一：只验证 HTTP 代理入口

curl --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com/

建议在 TUN 关闭时执行。--noproxy "" 清空本次请求的代理绕过列表，显式使用本地 7890 端口。若提示连接被拒绝，先查端口监听与内核启动状态；若代理已接收请求但目标超时，再查节点、规则和目标站点。

测试二：只验证 TUN 接管路径

curl --noproxy "*" --connect-timeout 10 -I https://example.com/

关闭系统代理、开启 TUN 后执行。--noproxy "*" 让 curl 不使用应用层代理，但不能绕过操作系统的 TUN 路由。执行后查看内核连接记录；命令成功本身不能证明走了代理，因为目标也可能通过直连访问。

这两条命令只测试 HTTPS 请求，不验证游戏 UDP、语音通话或 QUIC。测试这些场景时，应使用实际应用建立会话，并查看对应 UDP 连接是否出现、命中什么规则，以及出站是否支持 UDP。

检查路由与 DNS 状态

# Windows
route print
ipconfig /all
netsh winhttp show proxy

# Linux
ip rule show
ip route show table all
resolvectl status

# macOS
scutil --proxy
scutil --dns
netstat -rn

这些命令用于读取状态，不会修改网络配置。Linux 的 resolvectl 仅适用于提供该工具的系统；若不存在，检查当前网络管理器的 DNS 设置。自动路由可能写入独立路由表，所以只看主路由表不够。

常见故障与兼容性处理

系统代理有效，TUN 开启后断网

优先检查 TUN 权限、网卡创建和出口路由。先关闭 TUN 验证网络能否恢复，再单独启用 TUN。若仅在连接企业 VPN 时失败，通常需要协调路由和内部 DNS，而不是反复更换节点。

不要随意删除默认路由或结束未知网络服务。远程桌面环境中修改 TUN 路由可能中断控制连接，应先准备本地操作入口或回滚方式。

浏览器正常，命令行或游戏不通

仅开系统代理时，这往往是应用没有使用该代理入口。命令行可先显式指定代理验证；游戏则要检查是否使用 UDP，以及节点是否支持相应流量。开启 TUN 后仍不通，应查看连接记录，而不是把问题一概归为“接管失败”。

内网设备、打印机或公司域名不可达

先区分连接路由与名称解析。能通过设备 IP 访问、不能通过名称访问时，重点检查内部 DNS；IP 也不可达时，再看局域网路由和规则。把某个目标设为 DIRECT 只决定进入内核后的出站方式，不一定解决应用广播发现或多播发现问题。

能否同时开启两种模式

部分客户端支持系统代理与 TUN 同时开启，正常情况下内核会处理自身出站避免回环，但不应据此认为双开更稳定。排障时先单独验证每种方式；长期使用时按实际覆盖需求保留开关。与其他代理软件、VPN 同时运行，更容易出现入口归属不清和路由竞争。

Android 与 iOS 是否照搬桌面设置

不能。移动客户端常通过系统 VPN 接口接管流量，授权、应用排除与后台运行规则由平台和客户端决定。普通移动设备上，同一时间通常只能保留一个用户级 VPN 连接。本文 YAML 不能替代移动系统授权，也不能保证其他客户端支持相同字段。

按场景保留最小配置

  • 浏览器与常见桌面应用：优先系统代理，验证应用确实读取设置。
  • 开发工具与终端：先使用工具自身的代理参数；需要统一覆盖大量工具时再评估 TUN。
  • 游戏、语音与不支持代理的程序：可使用 TUN，但必须单独验证 UDP、节点能力与规则。
  • 企业 VPN、多个网卡与复杂内网：先记录路由和 DNS，再决定哪些连接需要接管，避免一次改动多个网络层。

稳定配置的判断依据是：目标应用进入预期入口、DNS 解析符合网络环境、规则命中正确、关闭接管后网络可以恢复。需要查阅字段时，可继续查看配置参考；遇到通用连接问题，可对照FAQ逐项排查。