Mihomo开启TUN后无法上网怎么办？先恢复网络再分层排查
简答：Mihomo开启TUN后完全无法上网，最快的恢复方法是先关闭TUN、关闭系统代理并退出核心，确认普通网络恢复后再逐项打开。若普通代理可用而TUN不可用，优先检查管理员权限、虚拟网卡、auto-route、strict-route、dns-hijack和系统防火墙，不要同时修改多个配置项。
定义：Mihomo的TUN模式是通过虚拟网卡和系统路由接管更多应用流量；它与只接收浏览器或应用请求的HTTP、SOCKS或mixed代理端口不是同一层。<a href="https://github.com/MetaCubeX/Meta-Docs/blob/main/docs/config/inbound/tun.en.md">Mihomo官方TUN文档</a>说明，auto-route负责设置全局路由，auto-detect-interface负责识别出口网卡，strict-route会强化路由约束，dns-hijack则把匹配到的DNS请求交给内部DNS模块。
先试这一步：关闭TUN并确认普通网络是否恢复
本站是第三方使用指南，不是Mihomo或任何相关客户端的官方网站。遇到TUN开启后断网，先不要改DNS、MTU和路由表，按下面顺序做一次最小回滚。
- 在Mihomo客户端中关闭TUN，等待虚拟网卡消失或状态变为未运行。
- 关闭系统代理，尤其是客户端设置的HTTP、SOCKS或mixed代理开关。
- 退出Mihomo核心，再打开浏览器访问一个平时可访问的网站。
- 如果仍然断网，Windows可先执行
ipconfig /flushdns；该命令用于清理DNS缓存，具体命令说明可查看Microsoft官方ipconfig文档。 - 普通网络恢复后，只重新启动核心，不立即打开TUN，先用客户端的普通代理端口测试。
判断结果：关闭TUN后网络恢复，故障范围集中在虚拟网卡、系统路由、DNS接管、权限或防火墙；关闭TUN后仍不能上网，则先排查本地网络、订阅配置、节点和系统代理残留。
用对照测试判断：核心、代理端口还是TUN接管出了问题
| 测试结果 | 优先怀疑 | 下一步 |
|---|---|---|
| 核心没有运行日志，普通网络正常 | 核心启动失败、配置校验失败或权限不足 | 查看启动日志，先恢复到最近一次可用配置 |
| 普通代理端口可用，TUN开启后断网 | 虚拟网卡、路由、DNS劫持、防火墙或VPN冲突 | 检查TUN权限、auto-route、strict-route和dns-hijack |
| 能访问IP，域名打不开 | DNS解析、DNS劫持或Fake-IP过滤 | 分别测试DNS监听端口和普通HTTP连接 |
| 只有部分应用不通 | 应用不遵守系统代理、规则匹配或QUIC/UDP路径 | 先用浏览器和curl对照，再看应用是否进入核心日志 |
| 局域网、NAS或打印机不通 | strict-route、Fake-IP或局域网地址未直连 | 暂时关闭strict-route或为局域网域名、网段设置排除规则后复测 |
这里的关键是把“核心运行”“请求进入核心”“DNS成功”“节点成功”和“应用建立连接”分开验证。只看到客户端显示已连接，不能单独证明TUN已经正确接管流量。
按四层顺序排查，不要同时修改多个参数
第一层：核心与权限
- 确认当前配置已经被客户端加载，且日志没有配置解析错误。
- 确认TUN启用时出现了虚拟网卡或TUN设备；如果没有，优先查管理员权限、系统服务或客户端授权。
- Windows首次启用系统级TUN通常需要管理员授权；官方桌面控制面板文档也说明，系统级路由需要权限或辅助服务支持，具体以当前客户端版本为准。
- 如果日志出现
permission denied，先以管理员权限启动客户端或重新授权，不要先改MTU。
第二层：流量是否进入Mihomo
- 打开日志并临时提高日志级别，访问一个普通网页，观察是否出现新的连接记录。
- 如果日志完全没有新连接，说明流量可能没有进入TUN、系统代理仍指向错误端口，或应用绕过了系统代理。
- 如果日志出现
network is unreachable，重点查看默认出口网卡、auto-detect-interface和系统路由。 - Mihomo官方文档指出，auto-route会自动设置全局路由；多网卡、虚拟机、公司VPN或容器环境下，自动识别结果可能需要人工核对，具体行为以当前内核文档和实际版本为准。
第三层：DNS是否真的成功
- 不要使用
nslookup example.com 127.0.0.1来证明1053端口生效，因为常规nslookup写法不能指定这个自定义端口。 - 如果Mihomo DNS监听在本机1053端口，应使用支持自定义端口的dig，例如：
dig @127.0.0.1 -p 1053 example.com。 - 如果DNS监听在其他端口，将命令中的
1053替换为客户端界面或配置中显示的实际端口；不要把示例端口当成固定默认值。 - 看到
198.18.0.0/16或其他Fake-IP地址，只能说明该查询可能进入了Fake-IP流程，不能单独证明TUN、路由和应用连接全部正常。域名若命中fake-ip-filter，可能返回真实地址；还要结合DNS日志、Fake-IP映射和应用实际连接继续判断。
第四层：节点与传输路径
- 如果请求已经进入核心、DNS也成功，但日志出现
timeout，再检查节点可用性、规则选择和出口网络。 - 如果网页能打开但某些应用不通，先区分TCP、UDP和QUIC，不要直接把问题归因于DNS。
- 若只在公司网络、虚拟机或多网卡环境中失败，记录当前出口接口、路由表和防火墙状态，再逐项恢复。
auto-route、strict-route与dns-hijack应该怎样检查
这三个字段经常被同时修改，但排查时应按顺序处理。
- 先看auto-route：它决定是否自动把全局流量路由进TUN。关闭后TUN可能仍显示运行，但普通应用流量未必会进入虚拟网卡。
- 再看auto-detect-interface：单网卡设备通常可以先保持自动识别；如果设备同时连接Wi-Fi、有线网、虚拟机或VPN，需核对实际出口接口，必要时按官方字段说明指定接口。
- 最后看strict-route：官方文档说明，Windows下它会增加用于阻止DNS泄漏的防火墙规则，Linux下会强化流量进入TUN的路由，但也可能导致VirtualBox等应用出现问题。因此，若开启strict-route后局域网、虚拟机或公司内网失效，应暂时关闭它做对照测试。
- 检查dns-hijack：官方文档说明，dns-hijack用于把匹配的DNS请求转入内部DNS模块；在Windows和macOS上，它不能自动劫持发往局域网的DNS请求，Android启用Private DNS时也可能无法自动劫持。此时不能只看配置字段是否存在，要结合系统DNS状态和Mihomo日志判断。
不同客户端界面可能使用“系统代理”“Tun”“增强模式”“DNS劫持”或“服务模式”等不同名称。找不到完全相同的菜单时，应以当前客户端中的关键词和核心日志为准，不要照搬其他客户端的路径。
分平台检查重点与可复制命令
Windows
- 检查客户端是否获得管理员权限，虚拟网卡是否出现在网络适配器列表。
- 打开命令提示符执行
ipconfig /all，记录物理网卡、TUN网卡和DNS服务器；恢复阶段可执行ipconfig /flushdns。 - 执行
route print查看默认路由是否存在，若启用strict-route后网络完全中断，先关闭TUN并回滚最近一次路由相关修改。 - 检查Windows防火墙是否阻止Mihomo核心；官方TUN文档建议在防火墙开启时允许核心程序通过防火墙。
macOS
- 确认客户端已获得网络扩展或系统授权，观察TUN设备是否出现。
- 如果普通应用不通但浏览器代理可用，重点检查系统DNS、应用是否使用系统解析器，以及TUN日志中是否出现DNS请求。
- Mihomo官方文档特别提示，macOS无法自动劫持发往局域网的DNS请求；因此局域网域名和本地设备应单独做直连或DNS排除测试。
Linux
- 执行
ip addr查看TUN设备，执行ip route查看路由。 - 若使用auto-redirect，注意官方文档将其标为Linux功能，并要求auto-route同时启用；iptables或nftables规则异常时，可能出现核心运行但应用无法联网。
- systemd-resolved、NetworkManager和其他VPN可能同时管理DNS，建议先暂时停用冲突组件做对照，而不是直接覆盖系统配置。
Android
- 确认系统VPN权限已经授予，并检查Private DNS是否开启。
- 官方文档说明，Android启用Private DNS时，DNS请求可能无法被自动劫持；遇到域名打不开时，先关闭Private DNS做一次对照测试。
- 如果只有热点共享或特定应用不通，不要把它与普通TUN联网混为一谈，先确认应用流量是否确实进入VPN接口。
复测、备份与回滚：确认修复不是偶然恢复
- 保存修改前的配置副本，并删除或遮盖订阅链接、节点地址、密码、UUID和访问令牌后再分享日志。
- 每次只修改一个变量，例如先只关闭strict-route，重载配置后测试；确认结果后再处理DNS。
- 依次测试：打开网页、执行域名查询、访问一个明确的IP地址、使用普通代理端口、重新打开TUN。
- DNS监听端口使用
dig @127.0.0.1 -p 实际端口 example.com验证；HTTP代理端口可用curl -I -x http://127.0.0.1:实际端口 https://example.com对照。 - 确认修复后仍要检查局域网、公司内网、虚拟机和常用应用，避免只验证一个网页就认为全部恢复。
- 如果修改后更糟，关闭TUN、退出核心、恢复备份配置，再确认系统代理和DNS回到原状态。
最终合格标准不是“客户端显示运行”，而是普通网页、域名解析、应用请求和需要的局域网访问都通过了对应测试。
什么时候应把问题交给节点或订阅排查
当TUN关闭后普通网络正常、普通代理端口可以使用、TUN日志也能看到请求，但只有特定节点或规则失败时，问题更可能位于节点、订阅返回内容、规则选择或远端传输路径，而不是虚拟网卡本身。
此时先在客户端内切换到另一个已存在的节点做对照，不要公开粘贴完整订阅链接。若所有节点都出现超时，再记录发生时间、连接协议、日志关键词和本地网络类型；这些信息比单独截图“已连接”更适合继续定位。
常见问题
Mihomo开启TUN后完全断网，第一步应该做什么？
先关闭TUN、关闭系统代理并退出核心，确认普通网络是否恢复。恢复后先测试普通代理端口，再重新开启TUN，这样可以区分节点问题和系统接管问题。
为什么nslookup不能证明Mihomo的1053端口生效？
常规nslookup写法不能像dig一样直接指定自定义端口。应使用dig @127.0.0.1 -p 实际端口 域名，并结合Mihomo DNS日志判断请求是否进入内部DNS。
看到198.18.0.0/16就代表Fake-IP配置成功吗？
不一定。该结果还受fake-ip-filter影响，而且DNS返回结果、Fake-IP映射和应用实际连接是三个不同层次。需要同时检查过滤规则、DNS日志和应用连接日志。
开启strict-route后为什么局域网、NAS或虚拟机不能访问？
strict-route会强化流量进入TUN的路由，并可能增加DNS防泄漏规则。先暂时关闭strict-route做对照，再为局域网网段或域名设置明确的直连与排除规则。
普通代理能用，为什么TUN仍然无法上网？
普通代理只证明代理端口和至少一个节点可用，不代表系统路由、虚拟网卡、DNS劫持和防火墙都正常。应重点检查管理员权限、auto-route、出口网卡、strict-route和TUN日志。