Mihomo TUN 模式连接不上：按现象定位权限、DNS与路由
简答：Mihomo TUN 模式连接不上时，先关闭 TUN，用同一节点通过 Mixed、HTTP 或 SOCKS 代理测试；普通代理能用而 TUN 不能用，问题通常应先从权限、虚拟网卡、路由或 DNS 排查。若 TUN 根本无法启动，看启动日志；若 TUN 已启动但全设备断网，再检查 auto-route、strict-route、dns-hijack、出口网卡和其他 VPN 冲突。不同客户端界面和 Mihomo 内核版本的菜单名称可能不同，以下配置字段以官方文档为准。
定义：Mihomo TUN 模式是通过虚拟网络接口在系统网络层接收流量，并配合自动路由和 DNS 处理让未设置单独代理的应用接入 Mihomo。
先做这组对照：确认问题在 TUN，而不是节点或配置
先不要反复修改 DNS、MTU 和协议。保持同一个配置、同一个节点和同一个目标网站，只关闭 TUN，改用客户端提供的 Mixed、HTTP 或 SOCKS 代理进行测试。Mihomo 官方将代理端口和 TUN 视为不同的流量入口：TUN 负责系统层流量，代理端口只接收已经指向该端口的应用流量。可参考Mihomo 入站配置文档。
| 现象 | 优先检查 | 停止条件与验证边界 |
|---|---|---|
| 开启 TUN 就报错或自动关闭 | 系统授权、虚拟网卡、已有 TUN 接口、客户端服务权限 | 日志不再出现 Start TUN listening error，才进入下一步；这不等于网页已经可用 |
| TUN 显示启动但所有应用断网 | auto-route、strict-route、出口网卡、DNS 劫持、其他 VPN | 先关闭 TUN 恢复网络，再一次只改一个字段 |
| IP 类地址能访问，域名打不开 | dns-mode、dns-hijack、nameserver、Private DNS | 日志能看到 DNS 请求并得到响应，才说明 DNS 链路有进展 |
| 只有某个应用或某类协议失败 | 规则、应用代理支持、UDP、IPv4/IPv6、MTU | 不要把单个应用失败扩大为整个 TUN 不可用 |
| 普通代理也失败 | 配置加载、节点、规则、基础网络和域名解析 | 先解决普通代理，暂时不要继续调 TUN |
验证时建议只观察三个结果：TUN 是否保持运行、日志是否持续出现错误、浏览器或目标应用是否真正完成连接。浏览器能打开一个页面、端口处于监听状态或客户端显示“已连接”，都不能单独证明所有应用和域名均已正常。
不超过 5 步的排查路径
- 备份配置并关闭其他网络接管工具。先复制当前 YAML 或导出配置；暂时退出其他 VPN、TUN、虚拟网卡工具和可能修改系统 DNS 的软件。若关闭 TUN 后网络恢复，先记录恢复前后的日志，不要立刻删除配置。
- 确认客户端和内核有系统授权。Windows 需要允许客户端或其辅助服务完成管理员操作；macOS 需要批准系统弹出的网络或管理员授权；Linux 运行 Mihomo 的进程需要具备创建 TUN 和配置路由的权限；Android 需要在系统 VPN 授权提示中允许该应用。官方文档说明 TUN 属于高级入站方式，具体授权方式取决于客户端和系统。桌面端辅助程序的授权机制可参考MetaCubeX Dashboard 的 TUN 说明。若日志仍是 permission denied，不要先改 DNS，而是先处理权限或设备访问。
- 核对最小 TUN 配置。先只保留必要字段，确认 YAML 缩进正确，再重载配置或重启核心。官方文档示例使用
enable、stack、auto-route、auto-detect-interface、dns-hijack和strict-route等字段；字段名称应以当前版本文档为准，不能把下划线和连字符混用。可参考Mihomo TUN 官方配置说明。 - 只改一个变量后验证。先保持
auto-detect-interface: true，确认设备只有一个主要出口网卡；多网卡、虚拟机、容器或有线与无线同时连接时，再考虑手动指定出口接口。每次修改后都要重新加载配置并观察日志，记录“修改前—修改后—结果”，不要同时改stack、DNS、MTU 和规则。 - 按结果回滚。如果开启 TUN 后完全断网，关闭 TUN、恢复备份配置并重启客户端；如果系统仍无网络，再检查系统网络设置中是否残留虚拟网卡、路由或 DNS。恢复网络后，回到普通代理测试，不要在网络未恢复时继续叠加修改。
常见日志关键词对应什么动作
| 日志关键词或现象 | 可作为的排查方向 | 下一步 |
|---|---|---|
permission denied | 进程没有创建或配置 TUN 的权限，或客户端辅助服务未获授权 | 重新批准系统权限、以正确权限启动客户端；Linux 还要核对运行用户和 TUN 设备权限。官方项目中曾记录过该类错误，但具体处理依系统和版本而不同，不能直接套用单一命令。可查看官方项目中的权限错误案例。 |
configure tun interface、interface | 虚拟接口名称、平台支持、接口状态或配置字段存在问题 | 检查 device 是否适合系统；官方文档特别说明 macOS 的接口名称需要以 utun 开头。先删除非必要的自定义设备名，再重启客户端测试。 |
device or resource busy | 接口或网络接管资源可能已被其他进程占用 | 退出其他 VPN、虚拟网络工具和旧的 Mihomo 进程，重启客户端；确认旧接口不再使用后再测试。 |
DNS resolve failed、域名打不开但 IP 可达 | DNS 监听、劫持、nameserver、Fake-IP 或系统 Private DNS | 先查看 DNS 日志是否有请求和响应；Android 开启 Private DNS 时，官方文档说明 DNS 请求可能无法被自动劫持。可暂时关闭 Private DNS 或改用明确的 DNS 配置进行对照。 |
network is unreachable | 路由没有正确进入 TUN，或自动识别到了错误出口接口 | 检查 auto-route、auto-detect-interface、strict-route 和多网卡状态；关闭 TUN 后先确认系统基础网络正常。 |
| 只有 Hysteria 或其他 UDP 流量失败 | UDP、防火墙、IPv4/IPv6、MTU 或网络环境差异 | 先用同一节点的其他协议或普通代理做对照；再一次只调整 MTU、IPv4/IPv6 或 stack。单个 UDP 协议失败不能直接证明整个 TUN 失效。 |
最小配置怎么写，哪些字段不要一开始就动
以下只是用于定位配置结构的最小示例，不包含节点、规则和 DNS 服务地址；实际可用字段仍取决于你使用的 Mihomo 版本与客户端。保存前请备份原文件。
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53auto-route负责自动设置全局路由，auto-detect-interface用于自动识别出口网卡，dns-hijack用于把匹配到的 DNS 请求交给内部 DNS 模块。官方文档还说明，strict-route在 Windows 上涉及 DNS 泄漏防护，在 Linux 上会强化路由约束，但也可能影响某些虚拟化软件；因此它不适合在故障初期与其他变量一起修改。详细边界见官方 TUN 字段说明。
如果问题集中在域名解析，检查 DNS 配置中的 enable、listen、enhanced-mode、nameserver 和 fake-ip-filter。官方 DNS 文档指出，Fake-IP、规则解析和节点域名解析可能使用不同的处理路径；不要仅凭“系统 DNS 能解析”就判断 Mihomo 的内部 DNS 已正常。可对照Mihomo DNS 官方文档。
按系统处理差异
Windows
先确认客户端的管理员授权或辅助服务已正常运行，再检查是否存在其他 VPN、虚拟机网卡或安全软件拦截。若开启 strict-route 后出现局域网或虚拟化软件异常，可回滚该字段做对照；官方文档明确提示 Windows 下 strict-route 可能影响部分应用。
macOS
检查系统是否批准网络扩展或管理员提示；如果自定义了 device，确认名称符合 macOS 的 utun 要求。多网卡环境下，记录实际出口接口，再考虑手动指定，不要先修改 MTU。
Linux
重点检查运行 Mihomo 的用户是否有创建 TUN 和设置路由的权限，以及是否存在旧的 TUN 接口或其他透明代理规则。官方文档说明 auto-redirect是 Linux 专用能力，并且需要启用 auto-route；如果只是排查基础 TUN，不要一开始同时启用多个重定向机制。
Android
重新确认系统 VPN 授权，检查 Private DNS 是否开启。官方文档还说明 Android 的 include-package、exclude-package 等应用范围字段需要配合 auto-route；如果只有某个应用不通，先检查应用是否被排除，而不是立即更换 DNS。
修复成功的验收标准与恢复规则
- TUN 启动后保持运行，日志不再持续出现权限、接口或路由错误。
- 关闭 TUN 后，普通代理使用同一节点可以复现；开启 TUN 后，不设置单独代理的目标应用也能完成实际连接。
- 至少分别验证一个域名访问和一个 IP 访问，避免把 DNS 问题误判为节点问题。
- 仅验证一个网页或一次连接，不足以证明所有应用、UDP 或 IPv6 均正常。
- 如果修改后全设备断网，先关闭 TUN并恢复备份；随后检查系统网络、残留虚拟接口和 DNS，再重新启用。
如果普通代理正常、TUN 仍失败，保留客户端版本、Mihomo 内核版本、系统版本、完整错误行和修改前后的配置差异，再向客户端维护者或 Mihomo 项目提交问题。不要在公开日志中直接暴露订阅地址、访问令牌或节点凭据。
本文是「缥缈墟 -」的第三方使用指南，不是该名称相关客户端或服务的官方页面；客户端界面、内核版本和字段支持可能变化，请以对应项目公开文档为准。
常见问题
1. Mihomo TUN 显示已开启，但浏览器仍然打不开网页，怎么办？
先关闭 TUN，用同一节点和同一配置测试 Mixed、HTTP 或 SOCKS 代理。如果普通代理也失败，优先检查节点、规则和配置加载；如果普通代理正常，再检查 auto-route、出口网卡、DNS 和其他 VPN 冲突。
2. 只改 DNS 能解决 TUN 连接不上吗？
不一定。只有域名解析失败、IP 连接仍可达时，DNS 才是优先方向。若日志是 permission denied、接口配置失败或网络不可达，先处理权限、虚拟网卡和路由；不要用更换 DNS 掩盖 TUN 未启动的问题。
3. 为什么开启 strict-route 后反而不能访问局域网？
strict-route会强化路由约束。官方文档说明它可能导致某些应用，包括部分虚拟化场景，出现异常。可以关闭该字段进行单变量对照；如果关闭后恢复，再根据局域网需求配置排除地址，而不是继续叠加规则。
4. Android 开启 Private DNS 会影响 Mihomo TUN 吗？
可能会。Mihomo 官方文档说明 Android 开启 Private DNS 时，DNS 请求无法被自动劫持。可暂时关闭 Private DNS 进行对照；如果关闭后恢复，再根据实际需求选择系统 DNS 或 Mihomo DNS 配置。
5. TUN 启动失败时，应该先换 stack 还是先检查权限？
先检查权限、系统授权、虚拟网卡和旧进程，再考虑 stack。权限错误和接口错误通常无法靠更换 stack 直接解决；每次只修改一个字段，并在重载配置后观察日志变化。
常见问题
Mihomo TUN 显示已开启，但网页打不开怎么办？
先关闭 TUN，用同一节点通过 Mixed、HTTP 或 SOCKS 代理测试。普通代理正常而 TUN 失败时，再检查 auto-route、出口网卡、DNS、strict-route 和其他 VPN 冲突。
Mihomo TUN 报 permission denied 怎么处理？
优先检查系统管理员权限、客户端辅助服务、Android VPN 授权或 Linux TUN 设备权限。不要先修改 DNS；确认权限修复后再重载配置观察日志。
Mihomo TUN 只有域名打不开怎么办？
检查 dns-mode、dns-hijack、nameserver、Fake-IP 和系统 Private DNS。Android 开启 Private DNS 时，DNS 请求可能无法被自动劫持。
开启 strict-route 后局域网不能访问怎么办？
先关闭 strict-route 做单变量对照。该字段会强化路由约束，可能影响部分局域网或虚拟化场景；确认原因后再配置必要的排除地址。
TUN 启动失败应该先换 stack 吗？
不建议。先检查权限、虚拟网卡、旧进程和接口配置，再一次只修改 stack、DNS 或 MTU 中的一个变量。