高墙之外❤️返回首页

Mihomo TUN 模式连接不上怎么办？

更新于 2026-10-26 · passwall.buzz

简答：先关闭 TUN 并恢复系统网络，再确认普通代理、节点和 DNS 是否正常；若只有 TUN 失败，重点检查管理员权限、auto-route、网卡选择、dns-hijack 与其他 VPN 冲突，按日志定位后通常能明确是权限、路由还是解析问题。

定义：Mihomo TUN 模式是通过虚拟网卡和系统路由接管未设置代理的应用流量，而不是只监听 HTTP 或 SOCKS 代理端口。

先试这一步：关闭 TUN，判断是不是 TUN 层故障

如果开启 TUN 后整机断网，先不要继续修改节点、规则和 DNS。关闭 TUN，关闭系统代理或恢复原来的系统代理设置，然后重新打开一个普通网页。

  1. 普通网络也打不开：先检查本地网络、系统代理残留、其他 VPN、虚拟机网卡和防火墙，不要把问题直接归因于 Mihomo。
  2. 普通网络正常，但 Mihomo 的 HTTP 或 SOCKS 代理不可用：检查内核是否启动、配置是否加载、代理端口是否被占用，以及当前节点是否能建立连接。
  3. 普通代理正常，只有 TUN 不通：优先检查管理员或 root 权限、TUN 虚拟网卡、auto-route、auto-detect-interface、strict-route 和 DNS 接管。

本站是独立第三方使用指南，与高墙之外❤️及相关客户端官方项目均无关联。Mihomo 官方文档将 TUN 的 auto-route 定义为自动设置全局路由，auto-detect-interface 用于自动识别出站网卡；多网卡设备可以改为手动指定出站接口。详见 Mihomo TUN 配置说明。

按症状对照：先判断故障在哪一层

现象优先检查处理方向
开启 TUN 立即全断网权限、auto-route、默认网卡、旧路由关闭 TUN 恢复网络，重新以管理员或 root 权限启动，再检查路由与网卡。
提示 permission denied 或无法创建 TUN系统权限、服务模式、虚拟网卡组件Windows 以管理员权限运行；macOS 或 Linux 检查系统授权；Android 检查 VPN 权限和 Private DNS。
普通代理能用，TUN 无法连接auto-route、strict-route、dns-mode、网卡冲突先关闭其他 VPN 和代理软件，确认 TUN 真正创建，再逐项恢复路由接管。
网页打不开但 IP 连接正常DNS、dns-hijack、nameserver、Fake-IP查看 DNS 日志；确认配置中有可用的 DNS 段，并检查代理节点域名解析。
只有部分应用或局域网不通规则顺序、Fake-IP 过滤、strict-route、局域网地址先切换全局模式验证，再检查规则是否误匹配 DIRECT 或局域网是否被 TUN 接管。
开启 TUN 后过一会儿失效睡眠唤醒、网络切换、多网卡、其他 VPN关闭并重新启用 TUN，确认默认出站网卡是否改变，再查看新的错误日志。

上表是排障顺序，不代表所有客户端都有相同菜单名称。不同 GUI 对 TUN 开关、服务模式和恢复网络功能的命名可能不同，应以当前客户端界面和 Mihomo 内核日志为准。

看日志：用关键词确认是内核、DNS 还是路由问题

不要只看“已开启 TUN”的状态提示。打开客户端的日志面板，临时将日志级别调到 debug，重新关闭并开启一次 TUN，然后搜索下列关键词：

  • permission denied：通常先查管理员权限、root 权限、VPN 授权或系统安全软件拦截。
  • network is unreachable：重点查默认路由、auto-route、出站网卡和网络切换后的旧路由。
  • dns resolve failed：重点查 nameserver、proxy-server-nameserver、DNS 接管和节点域名是否能解析。
  • timeout：区分节点连接超时、DNS 查询超时和目标站点超时，分别测试普通代理与 TUN。
  • Start TUN listening error：优先确认 TUN 接口是否创建、权限是否足够，以及是否有其他 VPN 或虚拟网卡占用。

如果客户端提供 Mihomo API，可以用 GET 请求查看实时日志。以下命令在终端执行，端口号以你的 external-controller 配置为准；如果 API 设置了密钥，请在本机按客户端说明认证，不要把密钥、Cookie 或订阅内容粘贴到公开页面。

curl -A "mihomo-diagnose/1.0" "http://127.0.0.1:9090/logs?level=debug"

PowerShell 中可使用：

Invoke-WebRequest -Headers @{"User-Agent"="mihomo-diagnose/1.0"} -Method GET -Uri "http://127.0.0.1:9090/logs?level=debug"

Mihomo API 文档明确列出 /logs 使用 GET 或 WebSocket 获取实时日志，支持 info、warning、error 和 debug 等级；配置了 API 密钥时需要按文档添加认证。参考 Mihomo API 文档。

普通代理正常、TUN 失败：按平台检查权限和路由

Windows

  1. 退出其他 VPN、代理客户端、虚拟机网络工具和可能接管网卡的安全软件。
  2. 以管理员权限启动承载 Mihomo 的客户端，重新启用 TUN；如果客户端提供服务模式或网络恢复功能，优先使用它完成授权。
  3. 检查系统是否出现 Mihomo 或 Wintun 相关虚拟网卡。若 TUN 开关显示开启但没有接口，先关闭 TUN、退出客户端并重新启动，不要同时修改 DNS 和规则。
  4. 如果启用 strict-route 后虚拟机、局域网或某些应用失效，先关闭该选项做对照测试。官方说明指出，Windows 下 strict-route 会增加用于避免 DNS 泄漏的防火墙规则，但特定应用可能因此异常。详见 TUN 参数说明。

macOS

  1. 确认客户端已获得网络扩展或辅助服务所需的系统授权。
  2. 如果系统存在多个网络接口，例如 Wi-Fi、网线、手机热点或虚拟网卡，检查 auto-detect-interface 是否选到了当前真正联网的接口；必要时手动指定。
  3. macOS 的 TUN 接口名称必须以 utun 开头，这是 Mihomo 官方文档列出的限制。防火墙拦截时，将实际使用的客户端或程序加入允许列表。

Linux

  1. 创建 TUN、设置路由或使用 auto-redirect 通常需要 root 权限；先用普通代理确认节点可用，再以 sudo 或系统服务方式启动 Mihomo。
  2. 检查内核、iptables 或 nftables 是否满足当前配置。Linux 的 auto-redirect 依赖 auto-route；如果只是排查 TUN 路由，可先保留 auto-route，暂时关闭 auto-redirect 做对照。
  3. 检查防火墙是否允许 TUN 接口出站。不要一次性清空防火墙规则，先记录现有规则并做最小变更。

Android、OpenWrt 与其他系统

  1. Android 的 TUN 由系统 VPN 权限管理；如果 Private DNS 开启，官方说明指出 DNS 请求可能无法被自动劫持，可暂时关闭 Private DNS 做对照。
  2. OpenWrt 或 Linux 路由器重点检查 root 权限、路由表、iptables/nftables、默认出口和 auto-redirect；改动前备份配置，失败后先停用 TUN 并恢复原路由。
  3. Android、OpenWrt 等平台的具体菜单属于 GUI 或固件功能，不应直接套用 Windows 的菜单路径；如果日志显示权限错误，应优先处理系统授权，而不是更换节点。

DNS、Fake-IP 和规则：为什么只有域名或部分应用打不开

当 TUN 已创建、普通代理也能用，但浏览器提示 DNS 错误或只有部分域名打不开，先检查 DNS 配置是否完整。Mihomo 官方 DNS 文档列出 enable、nameserver、proxy-server-nameserver、enhanced-mode 和 fake-ip-filter 等字段；其中 proxy-server-nameserver 专门用于解析代理节点域名。

可以先备份原配置，再用最小化思路检查，而不是直接复制一整套复杂规则：

  • dns.enable 是否为 true；
  • dns.nameserver 是否至少有可用解析服务器；
  • 节点使用域名时，是否配置了 proxy-server-nameserver 或其他可用的节点域名解析路径；
  • 使用 Fake-IP 时，局域网域名、路由器域名和内网服务是否加入了合适的 fake-ip-filter；
  • dns-hijack 是否与当前平台的 dns-mode、strict-route 或 Linux 的 auto-redirect 条件匹配。

规则按从上到下的顺序匹配，顶部规则优先级更高。排查时可暂时切换全局模式：如果全局模式能打开网页，说明节点和 TUN 通常已接管流量，接下来应检查规则是否误匹配 DIRECT、规则集是否未加载或 DNS 结果是否与规则不一致。Mihomo 官方 路由规则文档说明了规则的自上而下匹配顺序。

恢复网络与回滚：修改失败时不要继续叠加变量

  1. 先关闭 TUN，再关闭客户端的系统代理；如果系统仍无网，退出客户端并重新连接 Wi-Fi 或网线。
  2. Windows 检查系统代理、默认网关和网络适配器；macOS 检查当前服务顺序和代理设置；Linux 或 OpenWrt 检查默认路由与 TUN 接口。
  3. 恢复最近一次备份的配置，只改一个变量，例如先只改 auto-detect-interface，重启 TUN 后再观察。
  4. 不要同时更换节点、DNS、规则模式和 MTU。官方文档指出 MTU 会影响极端情况下的传输速率，普通用户通常可以保留默认值；因此 MTU 不应作为 TUN 无法启动时的第一修复项。
  5. 如果仍失败，记录系统、客户端名称和版本、Mihomo 内核版本、CPU 架构、TUN 配置摘要和完整错误行，删除订阅链接、密钥和 Cookie 后再提交给对应项目。

截至 2026 年 10 月 26 日，Mihomo 官方仓库的发布页仍会区分稳定版本与 Alpha 预发布版本。排查时不要把“客户端版本”与“Mihomo 内核版本”混为一谈，先在客户端关于页或 API 的 /version 中确认实际内核版本，再决定是否升级。版本兼容性在未核实前，不应直接断定是某个版本导致。

如果你已经确认普通代理可用，但 TUN 仍因权限、路由或 DNS 接管失败，可以先保留普通代理模式完成工作，再单独处理 TUN；排查后的结果应能明确归类为内核未启动、节点不可用、DNS 失败、规则误匹配、TUN 权限不足或路由冲突之一。

常见问题

Mihomo TUN 模式一打开就断网，应该先换节点吗？

不建议先换节点。先关闭 TUN，确认普通代理和节点可用；如果普通代理正常而 TUN 断网，优先检查权限、虚拟网卡、auto-route、默认出站网卡和其他 VPN 冲突。

普通代理能用，为什么 TUN 还是连接不上？

普通代理只接管指向 HTTP 或 SOCKS 端口的流量，TUN 还需要创建虚拟网卡并修改系统路由。因此应重点检查管理员或 root 权限、TUN 接口、auto-route、strict-route、auto-detect-interface 和 DNS 接管。

Mihomo 日志里的 permission denied 怎么处理？

Windows 先以管理员权限运行承载 Mihomo 的客户端；macOS 检查网络扩展或辅助服务授权；Linux 或 OpenWrt 检查是否以 root 或 sudo 启动；Android 检查系统 VPN 权限。修复权限后重新启用 TUN，再看日志是否变化。

TUN 开启后只有域名打不开，是节点问题吗？

不一定。若 IP 连接正常，优先检查 DNS 配置、dns-hijack、nameserver、proxy-server-nameserver 和 Fake-IP 过滤；如果切换全局模式后恢复，还要检查规则是否把域名误判为 DIRECT。

strict-route 要不要一直开启？

不能一概而论。它可以强化路由和 DNS 接管，但官方文档也提示某些应用可能受影响。排查时可在备份配置后暂时关闭做对照，确认问题是否由严格路由触发，再决定是否恢复。

怎么避免修改 TUN 配置后无法恢复网络？

每次只改一个字段，先备份配置；失败时关闭 TUN、关闭系统代理并重启客户端或网络连接。不要直接清空防火墙和路由表，先记录原状态并按平台恢复。

相关阅读

参考资料

  1. Mihomo 官方 TUN 配置说明
  2. Mihomo 官方 DNS 配置说明
  3. Mihomo 官方路由规则说明
  4. Mihomo 官方 API 与日志接口说明
  5. Mihomo 官方通用配置说明
  6. Mihomo 官方发布页