月神云 - 全终端加速服务

Mihomo TUN模式开启后无法上网怎么办？

更新于 2026-10-27 · moontoday.store

简答：先关闭 Mihomo 的 TUN 开关，确认普通代理或系统网络是否恢复：恢复了，问题通常集中在虚拟网卡、权限、自动路由或 DNS 接管；仍然无法上网，则先检查节点、基础配置和 DNS。不要一开始同时修改 Fake-IP、strict-route、MTU 等多个选项，先备份配置，再按“关闭 TUN—验证节点—检查日志—一次改一项—重新载入”的顺序处理。

定义：Mihomo 的 TUN 模式是通过虚拟网络接口和系统路由接管更多应用流量的工作方式；开启后无法上网，通常需要区分核心、节点、DNS、路由、权限和其他网络软件冲突。

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

如果打开 TUN 后立刻全局断网，先在客户端关闭 TUN，并保留原配置备份。然后分别测试浏览器、命令行或其他已知可用应用。

  1. 关闭 TUN：在客户端中搜索“Tun”“TUN 模式”“虚拟网卡”或“透明代理”开关，将其关闭。
  2. 保留普通代理：如果客户端有系统代理、HTTP、SOCKS 或 mixed-port 开关，只保留一种方式测试，避免多个客户端同时接管网络。
  3. 测试基础连接：先访问一个确认可用的网站，再在客户端查看节点或代理组是否有连接记录。
  4. 根据结果分流：关闭 TUN 后恢复，继续检查权限、路由、DNS 和虚拟网卡；关闭后仍失败，优先检查节点、订阅配置、代理组和 DNS。
现象优先怀疑下一步
TUN 开关无法打开权限、服务模式、虚拟网卡或系统安全软件检查管理员授权、Service Mode、Wintun 或系统网络扩展
TUN 打开后所有应用断网自动路由、DNS 劫持、出口网卡或路由冲突关闭 TUN 验证，再逐项检查 auto-route、dns-hijack 和出口接口
只有域名打不开，IP 测试正常DNS、Fake-IP、私人 DNS 或 DNS 死循环查看 DNS 日志，清理 DNS 与 Fake-IP 缓存
只有部分应用无法连接规则命中、应用自身代理设置、IPv6 或 QUIC查看连接记录中的规则、进程和目标地址

官方 TUN 文档说明，auto-route 会自动设置全局路由，dns-hijack 会把匹配的 DNS 请求交给内部 DNS 模块，而 strict-route 会强化路由约束；这些选项组合错误时，可能表现为系统范围断网或 DNS 异常。可参考 Mihomo TUN 配置文档。

按现象检查配置：权限、路由、DNS 和 MTU 一次只改一项

先备份，再改配置。如果客户端支持导出或复制当前配置，先保存一份可回滚版本。修改后按“保存—校验—重新载入—查看日志—验证业务”执行，不要同时改动多个字段。

1. TUN 无法开启或提示权限不足

  • Windows：以管理员权限启动客户端，检查是否有 Service Mode、服务安装或虚拟网卡驱动提示。若其他 VPN、虚拟机、Docker、远程控制软件或安全软件也在创建虚拟网卡，先完全退出它们，再重试。
  • macOS：检查系统是否弹出网络扩展或权限授权；TUN 设备名必须符合系统要求，官方文档指出 macOS 设备名只能使用以 utun 开头的接口名。
  • Linux：确认运行用户具备创建 TUN 和配置路由所需的权限；使用 systemd 部署时，可用 systemctl status mihomo 和 journalctl -u mihomo -f 查看服务状态与实时日志，具体方式见 Mihomo 服务部署文档。
  • Android：检查系统 VPN 权限和私人 DNS。官方文档提示，Android 开启 Private DNS 时，DNS 请求可能无法被自动劫持。

2. 检查 auto-route、auto-detect-interface 与 strict-route

auto-route: true 会把全局流量导入 TUN；多网卡、Wi-Fi 与网线并用、虚拟机网卡存在时，auto-detect-interface 可能选择的出口不是你想要的接口。可以先关闭其他网络接口或明确指定出口，再重新测试。

strict-route 能加强路由约束，但官方文档也提示，Windows 下它可能导致部分应用（例如某些虚拟化网络场景）异常。因此，若 TUN 能打开但所有连接失败，可在备份后暂时将其设为 false 进行对照测试；如果恢复，再检查路由排除项和冲突软件，而不是长期忽略安全边界。

3. 检查 DNS、Fake-IP 与 dns-hijack

如果日志出现 dns resolve failed、context deadline exceeded 或网页提示 DNS_PROBE 类错误，先确认 DNS 模块已启用，并检查 nameserver、default-nameserver、dns-hijack 是否互相造成回流。Android 还要检查 Private DNS；macOS 和 Windows 对局域网 DNS 的自动劫持存在边界，不能把 dns-hijack 当作所有 DNS 请求都必然接管。

在客户端控制面板中清理 DNS 与 Fake-IP 缓存后重新载入配置。官方 API 文档提供了 POST /cache/dns/flush 和 POST /cache/fakeip/flush，并说明可通过 GET /logs 获取实时日志、通过 GET /connections 查看连接信息、通过 GET /rules 查看规则命中情况，详见 Mihomo API 文档。

4. MTU 不要先乱改

MTU 主要影响特殊网络条件下的数据传输。如果 TUN 已经能建立但部分 HTTPS、视频或文件传输异常，再把 MTU 作为后续变量测试；每次只改一个值，并记录改动前后的日志和业务结果。没有复现证据时，不建议直接套用其他设备的 MTU。

分系统恢复清单：Windows、macOS、Linux、Android

Windows

  1. 关闭 TUN、退出其他 VPN 和代理客户端。
  2. 以管理员身份重新启动客户端，确认虚拟网卡或服务模式已正常安装。
  3. 重新开启 TUN，只保留 auto-route 和自动识别出口进行测试，暂时不要同时修改 DNS、IPv6、MTU 和规则。
  4. 若 Windows 网络栈疑似被网络过滤器或旧驱动影响，可在管理员命令提示符执行 netsh winsock reset；Microsoft 文档说明该命令会重置 Winsock 目录，之后需要重启。若仍异常，可执行 netsh int ip reset resetlog.txt 并重启，操作前应保存现有网络配置。参考 Microsoft Winsock 文档 与 Microsoft TCP/IP 重置说明。

macOS

  1. 关闭 TUN，确认普通网络恢复。
  2. 在“系统设置—网络”中检查当前 Wi-Fi 或有线服务，确认没有残留代理、VPN 或异常 DNS。
  3. 在网络服务的“详细信息—TCP/IP”中点击“续租 DHCP 租约”；Apple 说明该操作可在部分地址租约或网络地址异常时帮助恢复连接，步骤见 Apple DHCP 说明。
  4. 在“详细信息—DNS”中检查是否存在手动添加且不可用的 DNS；Apple 提供了 DNS 服务器的添加与删除入口说明，见 Apple DNS 设置说明。
  5. 重新开启 TUN 后观察是否创建了 utun 接口，并查看 Mihomo 日志中是否出现出口接口、DNS 或连接错误。

Linux

  1. 关闭 TUN 后测试普通网络，确认基础连接未被系统防火墙或 NetworkManager 破坏。
  2. 检查 TUN 接口、默认路由、策略路由和 nftables/iptables 规则是否出现重复或冲突。
  3. 若使用 auto-redirect，注意官方文档说明它仅适用于 Linux，并且需要同时启用 auto-route。
  4. 使用 journalctl -u mihomo -f 查看实时日志；若出现 DNS 超时，先检查 DNS 回流，再检查路由。

Android

  1. 关闭 TUN 或系统 VPN，确认手机本身能正常联网。
  2. 检查系统 VPN 权限、私人 DNS、分应用 VPN 和电池后台限制。
  3. 重新开启后，若只有部分应用失败，检查 TUN 的应用包含/排除列表，以及该应用是否自行设置了代理。
  4. 若 DNS 异常，优先暂时关闭 Private DNS 做对照测试；验证完成后再决定是否恢复。

查看日志和连接记录：不要靠猜节点或反复重启

把日志级别临时调到 debug，开启 TUN 后立刻访问一个确定会产生连接的地址，然后观察是否出现连接、规则、DNS 或路由错误。官方配置文档说明，debug 会输出更详细的运行信息；日志级别设置可参考 Mihomo 通用配置文档。

日志或连接表现判断方向处理动作
没有任何连接记录流量未进入 TUN、权限或路由接管失败先关闭 TUN测试，再检查虚拟网卡、auto-route 和系统权限
出现 DNS resolve failedDNS 上游不可达、DNS 回流或缓存异常清理 DNS/Fake-IP 缓存，检查 dns-hijack 与 nameserver
有连接但规则走错规则集或代理组选择问题查看规则命中、目标域名和当前代理组，不要先改 TUN
直连正常、代理连接失败节点、代理组、协议或出口连接问题关闭 TUN使用普通代理验证，确认基础代理可用后再回到 TUN
只有 IPv6 目标失败IPv6 路由、DNS 返回或节点支持不匹配备份后暂时关闭 IPv6 做对照，确认是否为 IPv6 路径问题

排查结束后，将日志级别恢复为原值，并撤销临时关闭的安全软件、IPv6 或路由设置。若必须提交日志，只保留错误时间、错误类型、系统和 Mihomo 版本，不要暴露订阅地址、访问密钥、Cookie 或完整节点信息。

最小化配置对照：只用于定位，不要直接覆盖生产配置

下面的片段用于对照 TUN 相关字段，不能替代你的完整配置。请先备份原文件，并根据客户端支持的字段进行校验。注释版：

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

如果系统或客户端不接受某个字段，先删除该字段并重新校验；不要把旧版本示例中的字段直接复制到新版本。无注释版：

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

建议的验证闭环是：保存配置后校验 YAML 缩进；重新载入或重启内核；查看 TUN 创建日志；访问一个普通网页；查看连接记录中的规则和出口；再分别测试 DNS、IPv4、IPv6 与需要代理的业务。只要某一步失败，就回到上一步，不要继续叠加修改。

常见问题

Mihomo TUN 开启后完全没网，第一步是什么？

先关闭 TUN，不要先换节点或重写配置。若关闭后普通代理恢复，说明基础节点大概率可用，应重点检查虚拟网卡、权限、auto-route、strict-route、dns-hijack 和其他 VPN 冲突；若关闭后仍无法上网，再检查节点、代理组和 DNS。

TUN 能打开，但浏览器提示 DNS_PROBE 或域名解析失败怎么办？

先查看 Mihomo 日志是否有 dns resolve failed、超时或循环请求，再清理 DNS 与 Fake-IP 缓存。检查 nameserver、default-nameserver、dns-hijack 和系统私人 DNS 是否形成回流。Android 需要特别检查 Private DNS；macOS 与 Windows 对局域网 DNS 的自动劫持也存在边界。

strict-route 应该开启还是关闭？

没有统一答案。strict-route 会加强路由约束，并可能帮助减少 DNS 泄漏，但官方文档也提示 Windows 某些虚拟化应用可能受影响。排查时应先备份配置，再临时切换一个值进行对照；如果关闭后恢复，继续查路由排除项和冲突软件，而不是直接长期关闭。

为什么 TUN 开启后只有部分应用无法联网？

常见方向包括规则把目标分到了错误的代理组、应用自行设置了代理、应用使用 IPv6 或 QUIC、应用被 TUN 的包含/排除列表排除。打开连接记录，检查目标地址、进程、匹配规则和实际出口，再只修改一个条件复测。

Windows 需要重置网络吗？

不建议一开始就重置。先关闭 TUN、退出其他 VPN、检查虚拟网卡与权限；只有确认网络栈或旧过滤器异常时，再以管理员身份执行 Microsoft 文档中的 Winsock 或 TCP/IP 重置命令，并按提示重启。重置前应保存现有网络配置。

修改配置后仍然断网，如何确认改动是否生效？

按照“保存—校验—重新载入—查看日志—验证业务”闭环操作。通过 Mihomo API 或客户端面板查看运行配置中的 tun、dns、log-level 和 ipv6 字段，再查看连接记录与规则命中；如果运行配置没有变化，说明配置未成功载入。

相关阅读

参考资料

  1. MetaCubeX Mihomo TUN 配置文档
  2. Mihomo API 文档
  3. Mihomo 通用配置文档
  4. Mihomo 服务部署文档
  5. Microsoft Learn：netsh winsock
  6. Microsoft Learn：重置 TCP/IP
  7. Apple 支持：续租 DHCP 租约
  8. Apple 支持：更改 Mac DNS 设置