Mihomo TUN模式、透明代理、虚拟网卡与自动路由设置指南
从应用请求到虚拟接口，再到真正的出站连接。把接管范围看清楚，才能让每一个设置都有依据。
TUN与系统代理，入口有什么不同
Mihomo TUN模式通过虚拟网络接口处理被系统路由引入的IP流量。系统代理则需要应用使用HTTP或SOCKS等代理入口，应用是否遵循系统设置、是否配置了例外，都会影响覆盖范围。透明代理强调应用通常无需主动配置代理，但实际实现仍有TUN、重定向等不同入站方式与系统条件。
| 检查角度 | 系统代理 | TUN虚拟接口 |
|---|---|---|
| 流量入口 | 应用按代理设置连接监听端口 | 系统路由将相应IP流量送入虚拟接口 |
| 主要依赖 | 应用行为、代理协议与本地监听 | 权限、接口状态、系统路由与出口 |
| 常见遗漏 | 应用不遵循设置、存在独立代理 | 流量被排除、其他VPN改变路由 |
| 验证证据 | 对应应用请求出现在核心连接中 | 目标请求进入接口且出站连接正确 |
虚拟网卡出现不代表全部请求已经转发。需要将“创建接口”“流量进入”“DNS可用”“远端可达”分开验证。遇到启动阶段错误，先看虚拟接口与权限排查。
三个路由字段，三个独立判断
auto-route 自动设置路由，让适用流量进入TUN；auto-detect-interface 识别出站网络接口；strict-route 在自动路由基础上施加更严格的路由行为。它们分别影响入口、出口和约束，不是可以互相替换的同义开关。
同时连接Wi-Fi、有线网络与其他VPN时，应确认核心选择的出站接口。strict-route在不同系统上行为不同，Windows还可能涉及DNS相关防火墙规则；更严格的接管也可能影响其他应用。先记录当前路由表，再改变一个参数，避免一次开启所有选项。
tun:
enable: true
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
- tcp://any:53示例只展示关键字段的层级。接口名、协议栈、IPv6支持与路由排除应根据核心版本、官方文档和运行环境决定。无需为了追求性能盲目调整MTU或改动未知网络参数。
DNS接管不等于改写所有DNS
dns-hijack 把匹配且可接管的DNS连接交给内部DNS模块；修改系统DNS则改变系统解析器的服务器设置，过程并不相同。应用自带DoH、私人DNS或局域网DNS可能具有不同路径。官方文档也列出了不同系统的接管限制，不能把53端口匹配理解为所有DNS都已覆盖。
确认DNS模块已启用、监听与查询路径对应，再观察解析结果。TUN负责流量入口，Fake-IP负责特定DNS处理行为，规则负责后续策略。请求不是在所有环境中都按完全相同的顺序经过每个步骤。
按操作系统验证权限与接口
Windows
检查运行方式是否具备创建接口和安装路由所需的权限，查看网络适配器、默认路由及相关日志。服务启动与手动运行可能使用不同账户，防火墙许可应对应实际核心程序。
Linux
核对TUN设备、网络管理权限以及容器的设备和能力限制。Linux专用字段不能直接套用到其他系统；多套策略路由与其他VPN也需要同时考虑。
macOS与双栈网络
macOS接口名称应遵循utun前缀要求，检查运行权限、实际接口及系统路由。IPv4与IPv6应分别读取状态；只验证IPv4并不能证明IPv6也使用预期路径。具体参数支持以当前文档与实际核心为准。
启动之后，用请求验证路径
发起一次明确目标请求，检查入站记录、DNS处理与出口。若请求进入核心却走错策略，继续检查规则匹配与活动配置；完整路径可在流量路由栏目对照。遇到打印机或NAS异常，应另看本地子网与mDNS，区分自动发现和实际服务访问。