速飞云 — 香港高速节点 · 稳定不限速

Mihomo TUN 模式无法使用怎么办？按症状排查 DNS、权限与路由

更新于 2026-10-20 · sufeiyun.shop

简答：Mihomo TUN 模式无法使用时，先关闭 TUN 并用 Mixed/系统代理确认节点本身可用，再按“权限与虚拟网卡→DNS→路由→协议栈→其他 VPN 冲突”的顺序排查。完全无法联网通常优先看权限、auto-route 和出口网卡；只有域名打不开则优先看 DNS、dns-hijack 与 fake-ip；只有 Hysteria/Hysteria2 失败则重点对照 UDP、MTU 和 TUN stack。

定义：Mihomo TUN 模式是通过虚拟网卡接管系统流量，并结合自动路由与 DNS 劫持让未设置应用代理的程序也进入 Mihomo 处理链路。

先试这一步：关闭 TUN，确认节点和代理端口是否正常

本站是第三方使用指南站，不是 Mihomo 或任何相关客户端的官方页面。版本号以发布页为准，本文资料核对日期为 2026-10-20。

最快的定位方法是先在客户端中关闭 TUN，只保留 Mixed、HTTP 或 SOCKS 代理端口，然后把浏览器或系统代理指向该端口。Windows 使用 curl.exe，macOS/Linux 使用 curl，分别执行：

  • Windows：curl.exe -I -v --proxy http://127.0.0.1:7890 https://example.com
  • macOS/Linux：curl -I -v --proxy http://127.0.0.1:7890 https://example.com

如果关闭 TUN 后代理端口可以访问，而打开 TUN 后失败，问题通常集中在权限、虚拟网卡、自动路由、DNS 劫持或其他 VPN 冲突；如果两种模式都失败，先检查订阅、代理组、节点协议和节点域名解析，不要先修改 TUN 参数。

症状与优先检查项速查
现象先检查下一步
开启 TUN 后完全无法联网管理员权限、虚拟网卡、auto-route、出口网卡关闭 strict-route，切换 stack
IP 能访问，域名打不开dns.enable、listen、dns-hijack、fake-ip检查 DNS 日志与系统 DNS
国内网站正常、境外网站打不开代理组、规则、节点可用性用 Mixed 代理端口单独测试节点
只有 Hysteria/Hysteria2 失败UDP、MTU、stack、IPv6 和防火墙先换 TCP 节点，再做 MTU 对照
只有某个应用失败应用自身代理、规则、fake-ip 过滤查看连接日志中的进程和目标域名

检查 TUN 配置：先用最小配置排除复杂项

Mihomo 的 TUN 配置至少要关注 enable、stack、auto-route、auto-detect-interface、dns-hijack、strict-route 和 mtu。官方文档说明，auto-route 用于把流量自动导入 TUN，auto-detect-interface 用于自动识别出口网卡；多网卡同时在线时，文档建议考虑手动指定出口接口。具体字段请以Mihomo TUN 配置文档为准。

先暂时去掉自定义路由、复杂的 include/exclude 规则、IPv6 专用路由和非默认 MTU，只保留以下排查用结构。本文按中文文档列出的三种 TUN stack 书写：system、gvisor、mixed。

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

这段只是定位故障的最小示例，不代表所有客户端都使用相同端口或默认值。若你的客户端把 YAML 配置拆分到图形界面，请把对应字段逐项对照，不要同时改动多个选项。

三种 TUN stack 的排查顺序
stack特点适合怎样测试
system使用系统网络协议栈，资源开销相对较低，但更依赖系统路由、防火墙和网卡行为。先确认系统路由和防火墙正常后测试。
gvisor在用户空间处理网络协议栈，与系统网络栈隔离程度更高，兼容表现可能不同。system 无法启动或特定系统路由异常时对照测试。
mixedTCP 使用 system，UDP 使用 gvisor。作为常规对照项；若 TCP 正常而 UDP 失败，继续查 UDP、MTU 和节点协议。

建议顺序是先用 mixed，再用 gvisor，最后用 system 做对照。每次只改一个字段并重启 TUN，记录“能否启动、能否解析、能否访问、哪些协议失败”。

如果启用防火墙后只有 system 或 mixed 失败，官方文档建议放行 Mihomo 核心程序；Linux 还可以在确认接口名称后测试放行 TUN 网卡出站流量。不要为了排查长期关闭防火墙。

DNS 故障：IP 能访问但域名打不开时这样查

如果浏览器访问 IP 正常、访问域名失败，先看 Mihomo 日志中是否出现 DNS 请求，再检查 dns.enable、listen、enhanced-mode、fake-ip-range 和 dns-hijack。Mihomo DNS 文档列出 fake-ip 与 redir-host 两种增强模式，并将 198.18.0.1/16 作为 fake IP 范围示例；完整字段见Mihomo DNS 配置文档。

在 fake-ip 模式下，nslookup 返回 198.18.x.x 不一定是故障，这可能是 Mihomo 为域名建立的 fake IP 映射。真正需要关注的是：连接日志是否能把该地址还原到原域名、代理组是否有匹配结果，以及 DNS 服务是否能访问。

  1. 在客户端日志中搜索目标域名，确认是否出现 DNS 查询、规则匹配和代理连接。
  2. 临时把 enhanced-mode 从 fake-ip 改为 redir-host，重启 Mihomo 后复测同一域名。
  3. 如果 redir-host 正常而 fake-ip 失败，检查 fake-ip-filter、应用是否依赖真实 IP，以及是否存在旧的 fake IP 缓存。
  4. 如果 Windows 或 macOS 使用局域网 DNS，注意官方文档指出这两个系统无法自动劫持发往本地网络的 DNS 请求；可先把系统 DNS 临时改为可直连的 IP 地址进行对照。
  5. 境外网络环境不要机械照抄某一组 DNS，nameserver、fallback 和 DoH 地址应选择当前网络可以直连、且符合所在地区网络条件的解析服务。

Windows：检查权限、Meta 虚拟网卡、路由和防火墙

Windows 上先完全退出客户端，再以管理员身份启动；随后确认客户端是否创建了 Mihomo、Meta 或 Wintun 相关虚拟网卡。若 TUN 开关一打开就自动关闭，优先看权限、核心日志和安全软件拦截记录。

  1. 在客户端中关闭 TUN，确认 Mixed 代理端口测试通过。
  2. 右键客户端选择“以管理员身份运行”，重新启用 TUN。
  3. 打开“设置 → Windows 安全中心 → 防火墙和网络保护 → 允许应用通过防火墙”，放行 Mihomo 核心程序；官方 TUN 文档给出了该放行路径。
  4. 在 PowerShell 中执行 Get-NetIPInterface，查看接口索引、接口别名和连接状态。该命令用于获取 IP 接口信息，具体说明见Microsoft Learn 的 NetTCPIP 模块文档。
  5. 如果存在多个物理网卡、虚拟机网卡、WireGuard 或其他 VPN，先暂时停用非必要接口，再测试 auto-detect-interface: true。若仍选错出口，按客户端支持方式手动指定物理出口接口。
  6. 用 route print 查看是否出现指向 TUN 的路由；关闭 TUN 后再次查看，确认异常路由是否消失。不要直接删除不认识的系统路由。

若 Windows 下“网页打不开但 Mixed 端口正常”，重点看 TUN 路由和 DNS；若“只有 UDP 节点失败”，把 stack 从 mixed 切换到 gvisor 做对照，并检查防火墙是否拦截核心程序。

macOS：检查 utun、权限、系统 DNS 与直连现象

macOS 的 TUN 设备名称需要以 utun 开头。启用 TUN 后可在终端执行 ifconfig，查看是否出现新的 utun 接口；如果没有，先检查客户端是否获得了必要的系统权限或辅助组件是否启动。

  1. 关闭 TUN，用系统代理或 Mixed 端口访问同一目标，确认节点本身可用。
  2. 重新启动客户端；如果客户端提供“安装 Helper、允许系统扩展”或类似按钮，按 macOS 的系统设置提示完成授权。
  3. 执行 ifconfig，确认存在活动的 utun 接口；TUN 配置中的自定义设备名不要写成非 utun 开头的名称。
  4. 检查“系统设置 → 网络 → 防火墙 → 选项”，确认 Mihomo 应用未被阻止。官方文档说明，macOS 通常会放行已签名软件，但遇到防火墙问题时可以手动添加应用。
  5. 如果日志出现 network is unreachable 或 i/o timeout，先把 stack 改为另一种进行 A/B 测试，再检查默认出口是否被其他 VPN 或虚拟接口改变。

公开的 Mihomo Issue #895 记录过一个具体的 macOS 现象：开启 TUN 后，日志出现对代理目标的 network is unreachable 和 i/o timeout。这只能作为相似症状参考，不能据此断定你的环境与该问题相同；应保留自己的客户端版本、核心版本、系统版本、配置和日志后再判断，原始记录见Mihomo Issue #895。

Linux：检查 /dev/net/tun、CAP_NET_ADMIN、iptables 与 nftables

Linux 上先检查 TUN 设备是否存在：

ls -l /dev/net/tun
ip link show
ip route show
ip rule show

如果 /dev/net/tun 不存在，Mihomo 无法正常创建 TUN 设备；如果文件存在但核心仍提示权限错误，可先用 root 启动做一次对照。长期以非 root 用户运行时，可以给核心程序配置最小必要能力，例如：

sudo setcap cap_net_admin+ep /usr/local/bin/mihomo
getcap /usr/local/bin/mihomo

Linux capabilities 文档说明，文件能力可以附加到可执行文件；请确认路径是你实际使用的 Mihomo 核心，升级或替换二进制后需要重新检查。相关机制见Linux capabilities 手册。

如果 Mihomo 由 systemd 管理，也可以在服务覆盖配置中使用 AmbientCapabilities=CAP_NET_ADMIN 并限制 CapabilityBoundingSet；具体写法要结合你的发行版和服务文件，修改前先备份。不要同时让多个服务管理同一个 TUN 接口。

  1. 确认 auto-route: true 时，ip route show 和 ip rule show 出现了预期的策略路由。
  2. 确认使用 auto-redirect: true 时，系统实际使用的是 iptables 还是 nftables；不要只修改其中一套规则。
  3. 如果防火墙开启，先按官方文档示例测试允许 TUN 接口出站：sudo iptables -A OUTPUT -o Mihomo -j ACCEPT。其中 Mihomo 只是示例接口名，必须替换成 ip link show 查到的真实名称。
  4. 若改为 gvisor 后恢复，记录原 stack、路由规则和防火墙状态，不要直接认定是 Mihomo 核心缺陷。

Android：先排除 VPN Service 冲突和出口接口误选

Android 的 TUN 通常与系统 VPN Service 共享关键网络能力。如果同时运行其他 VPN、Tailscale、WireGuard、广告拦截器或安全软件，先全部停止，只保留 Mihomo，再测试相同节点。Mihomo 官方文档还说明，Android 开启 Private DNS 时，DNS 请求可能无法被自动劫持。

  1. 关闭其他 VPN 或 VPN Service，重新授权 Mihomo 的 VPN 连接。
  2. 在 Mihomo 日志中查看自动选择的出口接口；如果日志显示选择了另一个 TUN 接口，尝试关闭冲突应用后再启动。
  3. 如果 IPv4 正常、IPv6 失败，先暂时关闭 IPv6 或改用 gvisor 对照。公开 Issue #1903 记录了 Android 15、特定内核环境下 system 或 mixed 访问 IPv6 失败、gvisor 可用的具体现象，但这不是所有 Android 设备的通用结论，原始记录见Mihomo Issue #1903。
  4. 如果其他 VPN 必须同时运行，不要直接照抄社区讨论中的策略路由命令；先备份当前路由，确认 Android 版本、Root 状态和接口名称，再逐项测试。

Hysteria/Hysteria2、UDP 或速度异常：做协议和 MTU 对照

公开的 Mihomo Issue #1222 记录过一个 Windows 现象：启用 TUN 后 Hysteria 与 Hysteria2 节点无法连接。该记录不能证明所有此类失败都由同一原因造成，但可以提醒你把 UDP、stack、MTU、出口网卡和防火墙列入对照范围，原始记录见Mihomo Issue #1222。

  1. 关闭 TUN，用 Mixed 端口单独测试同一个 Hysteria/Hysteria2 节点。
  2. 如果 Mixed 正常而 TUN 失败，依次将 stack 设置为 mixed、gvisor、system，每次只改一个值。
  3. 暂时关闭 IPv6 或改用 IPv4 节点做对照，避免把 IPv6 路由问题误判为 UDP 节点故障。
  4. 检查 MTU。Windows 使用 ping -f -l 数值 目标主机；macOS 使用 ping -D -s 数值 目标主机；Linux 使用 ping -M do -s 数值 目标主机。目标应选择能够响应 ICMP 的主机，逐步降低数值直到不分片或不报错；探测得到的负载数值加 28 字节，才是 IPv4 MTU 的换算值。
  5. 如果调整 MTU 后恢复，只把该值写入 TUN 配置并再次测试，不要同时修改 DNS、路由和 stack。

若只有某个节点失败，先保留节点协议、IP 版本、失败日志和连接时间；不要仅凭一次失败就判断线路或服务状态异常。

恢复网络与提交问题前的记录清单

如果修改 TUN 后网络中断，先在客户端关闭 TUN 并退出核心，再恢复系统代理设置；Linux 还应检查残留的策略路由和防火墙规则。不要在不了解规则用途的情况下批量执行清空路由或清空防火墙命令。

  • 操作系统版本、CPU 架构、客户端名称和客户端版本。
  • Mihomo 核心版本；版本号以发布页为准。
  • tun、dns、代理组和相关规则片段，隐藏订阅地址、密码、UUID、密钥和公网 IP。
  • 失败时间、目标域名、节点协议、是否 IPv4/IPv6、是否只有某个应用失败。
  • 日志中的完整错误行，以及关闭 TUN、Mixed 模式和不同 stack 的对照结果。
  • Windows 的 Get-NetIPInterface、route print；macOS 的 ifconfig、netstat -rn；Linux 的 ip link、ip route、ip rule 输出。

这样可以把问题区分为“核心没有启动 TUN”“TUN 启动但没有流量”“DNS 解析失败”“路由回环或出口选错”“节点协议本身失败”五类，避免反复随机修改配置。

常见问题

Mihomo TUN 开启后，nslookup 返回 198.18.x.x 是不是 DNS 配置错了？

不一定。启用 fake-ip 时，198.18.0.1/16 是 Mihomo 文档中的 fake IP 范围；先看连接日志是否能把该地址对应回原域名，再用 redir-host 做一次对照。

应该优先用 system、gvisor 还是 mixed？

排障时建议先用 mixed，再用 gvisor 和 system 做对照。mixed 将 TCP 与 UDP 分别交给不同协议栈；如果只有 UDP 或 Hysteria 失败，应继续检查 MTU、IPv6、防火墙和出口接口，而不是只反复切换 stack。

关闭 TUN 后节点正常，打开 TUN 后所有应用都不能上网，最可能先查什么？

先查管理员或 root 权限、虚拟网卡是否创建、auto-route 是否生效、auto-detect-interface 是否选错，以及防火墙是否拦截 Mihomo 核心。Windows 可查看 Get-NetIPInterface 和 route print，Linux 可查看 ip link、ip route 和 ip rule。

Android 上能否同时运行 Mihomo TUN 和其他 VPN？

先不要假设可以稳定共存。Android 多个 VPN Service、Tailscale 或 WireGuard 可能争用 VPN 和路由能力；排障时应先关闭其他 VPN，确认单独运行 Mihomo 的结果，再考虑更复杂的共存方案。

只有 Hysteria/Hysteria2 节点失败，是否说明节点已经失效？

不能直接这样判断。先关闭 TUN，用 Mixed 端口测试同一节点，再对照 UDP、stack、MTU、IPv4/IPv6 和防火墙；如果只有一个节点失败，还要检查该节点自身的协议参数和域名解析。

常见问题

Mihomo TUN 开启后，nslookup 返回 198.18.x.x 是不是 DNS 配置错了？

不一定。fake-ip 模式会使用文档中的 fake IP 范围，先检查连接日志是否能还原原域名，再用 redir-host 做对照。

应该优先用 system、gvisor 还是 mixed？

排障时先用 mixed，再用 gvisor 和 system 做单变量对照；如果只有 UDP 失败，继续检查 MTU、IPv6、防火墙和出口接口。

关闭 TUN 后节点正常，打开 TUN 后所有应用都不能上网，先查什么？

先查管理员或 root 权限、虚拟网卡、auto-route、auto-detect-interface 和防火墙，再检查 DNS。

Android 上能否同时运行 Mihomo TUN 和其他 VPN？

排障时应先关闭其他 VPN Service、Tailscale 或 WireGuard，确认 Mihomo 单独运行正常后再测试共存。

只有 Hysteria/Hysteria2 节点失败，是否说明节点已经失效？

不能直接判断。先用 Mixed 端口测试同一节点，再对照 UDP、stack、MTU、IPv4/IPv6 和防火墙。

相关阅读

参考资料

  1. Mihomo TUN 配置文档
  2. Microsoft Learn：NetTCPIP 模块
  3. Mihomo Issue #895：macOS 开启 TUN 后无法使用
  4. Mihomo Issue #1222：TUN 后 Hysteria/Hysteria2 无法连接
  5. Mihomo Issue #1903：Android 特定环境下 system/mixed 的 IPv6 现象
  6. Linux capabilities 手册（linuxman7.org）