Mihomo TUN 模式开启后无法上网怎么办？按顺序恢复连接
简答：先关闭 TUN，只保留普通 HTTP、SOCKS 或 Mixed 代理，确认节点和配置本身能否连接；如果普通代理正常，再检查 TUN 权限、虚拟网卡、出口网卡、路由和 DNS。不要一开始同时修改 stack、auto-route、strict-route、fake-ip 和自定义 DNS，每次只改一个参数并复测。TUN 已显示运行但网页仍打不开时，优先区分 DNS 失败、规则未命中、路由回环和节点超时。
定义：Mihomo TUN 模式是通过虚拟网卡接管系统流量的运行方式，涉及虚拟网卡、系统路由、DNS 处理和代理节点，不等同于单纯打开系统代理。
先做三步速查：恢复网络，再判断故障层级
本站是面向客户端与网络问题的第三方使用指南站，不是任何客户端或服务品牌的官网。不同图形客户端的按钮名称会随版本变化，以下以“当前配置”“活动配置”“运行配置”“TUN”“日志”等同义入口为准。
| 现象 | 先做什么 | 成功判据 |
|---|---|---|
| TUN 一打开就彻底断网 | 关闭 TUN，保留普通代理测试 | 普通代理能打开测试网页或完成域名解析 |
| TUN 显示运行，但所有网页打不开 | 查看日志并检查出口网卡、auto-route、DNS | 日志不再出现 TUN、DNS、route 或 timeout 连续报错 |
| 只有部分域名或应用失败 | 分别测试 IP、域名、规则模式和 DNS | 能判断是 DNS、规则、IPv6 还是应用不兼容 |
- 在客户端中确认当前启动的是导入后正在使用的配置，而不是另一份旧配置；优先查看“当前配置/活动配置/运行配置”标记。
- 关闭 TUN，使用普通代理入口测试节点。若普通代理也失败，先处理订阅、节点、端口或网络问题，不要继续改 TUN。
- 普通代理正常后重新开启 TUN，只保留原有配置，记录开启前后的日志、默认网关和 DNS 变化。
官方文档说明，顶层 tun 配置主要负责系统流量接管、自动路由和 DNS 劫持；它与 mixed-port、socks-port 等代理端口不是同一层功能。可参考 Mihomo 入站配置说明。
先分清：TUN 没启动、启动后断网，还是只有部分流量失败
1. TUN 根本没有启动
重点看日志中的 permission denied、cannot create TUN、虚拟网卡创建失败或权限相关信息。Windows 通常需要允许客户端或 Mihomo 核心通过防火墙；macOS 需要允许网络扩展或 VPN 权限；Linux 需要确认当前用户具备创建 TUN 和配置路由的权限；Android 则需要接受系统 VPN 请求。
图形客户端如果有“以管理员身份运行”“服务模式”“允许网络扩展”或“VPN 权限”入口，应先完成权限授权，再重启客户端。若客户端没有这些入口，不要直接套用其他客户端的菜单名称，以当前版本界面和官方说明为准。
2. TUN 已启动但全局断网
优先检查是否选错出口网卡、路由回环或系统中存在第二个 VPN、虚拟网卡、流量过滤器。Mihomo 文档指出，auto-detect-interface 会自动选择流量出口；多网卡同时连接时，建议核对或手动指定实际联网的出口接口。官方 TUN 字段说明还说明，auto-route 会把全局流量导入 TUN，因此配置错误时可能表现为整体断网。
3. 只有部分应用或域名失败
这时不要直接把规则模式改成 Global。Rule、Global、Direct 主要决定流量如何选择出口，而 TUN 决定系统流量是否被接管，两者不是同一个开关。先分别测试域名解析、IP 访问、浏览器和目标应用，再决定是否检查规则、DNS、IPv6 或应用自身的代理设置。
按日志关键词分流排查
| 日志或现象 | 优先检查 | 处理与复测 |
|---|---|---|
permission denied | 管理员权限、VPN 或网络扩展权限、防火墙 | 授权后完全退出客户端，再重新启动 TUN |
cannot create TUN | 虚拟网卡、残留核心进程、其他 VPN 或安全软件 | 退出重复运行的客户端与 VPN，重新创建 TUN |
address already in use | 端口或旧进程占用 | 关闭旧核心，确认只有一个实例，再启动 |
YAML、配置解析错误 | 缩进、字段层级、字段拼写 | 撤销最近一次修改，恢复上一份能启动的配置 |
DNS、解析超时 | dns.enable、dns-hijack、Fake-IP、系统 DNS | 先临时回到原 DNS 配置，再只改一个 DNS 参数 |
timeout、节点连接超时 | 节点域名解析、出口网络、规则和节点本身 | 关闭 TUN 测试同一节点；普通代理也超时则转查节点或本地网络 |
| 日志显示 listening，但网页打不开 | 路由、DNS、规则、IPv6 或出口网卡 | 先测 IP 与域名，再检查默认路由和 DNS |
排障时不要同时更换节点、改 DNS、改 MTU 和切换 stack。每次只做一个改动，并记录“改动前现象—改动项—复测结果”，这样才能知道真正起作用的配置。
Mihomo TUN 配置怎么逐项恢复
建议先备份当前配置，再从最少字段开始恢复。下面的顺序用于定位，不代表所有平台都必须使用同一组值。
- 先确认接管：仅确认
tun.enable: true是否能创建虚拟网卡；暂时不要添加自定义路由、MTU、IPv6 或复杂的分流条件。 - 再确认路由：检查
auto-route是否开启，以及auto-detect-interface选到的是否是当前实际联网网卡。电脑同时连接有线、Wi-Fi、虚拟机网卡或手机热点时，尤其要核对这一项。 - 再处理 DNS：检查
dns.enable、enhanced-mode、dns-hijack和fake-ip-filter。官方 DNS 文档说明，Fake-IP 与 Redir-Host 是两种不同的 DNS 处理模式；不要因为“能看到 Fake-IP”就判断节点或 TUN 已经正常。参考 Mihomo DNS 配置说明。 - 最后尝试 stack：如果当前 stack 与防火墙、应用或系统兼容性有关，再一次只切换一个 stack。官方文档指出，
system与mixed在防火墙开启时可能需要放行核心程序；Windows、macOS、Linux 的处理方式不同。 - 最后才改 strict-route：
strict-route会强化路由约束。Windows 下它与 DNS 泄漏防护有关，但也可能让某些虚拟机或特殊网络应用出现兼容性问题；Android 下它还与 DNS 劫持能否工作有关。改动后必须立即复测常用应用和局域网资源。
Linux 使用 dns-mode: hijack 时，还要注意官方文档列出的平台条件：Linux 需要配合 auto-redirect；Windows 使用 DNS 劫持时需要 strict-route。因此不要把一段 Windows 配置原样复制到 Linux 或 Android。
DNS、Fake-IP 与 TUN 断网怎么验证
- 先测 IP：在关闭 TUN 和开启 TUN 两种状态下访问一个已知可用的 IP 测试地址。若 IP 可访问、域名打不开，优先怀疑 DNS，而不是节点完全失效。
- Windows：运行
ipconfig /all查看当前 DNS 与网卡，再用nslookup example.com观察是否能返回地址。测试结束后可用ipconfig /flushdns清理本地 DNS 缓存。命令只能说明系统解析结果，不能单独证明所有应用都经过了 Mihomo。 - macOS：用
scutil --dns查看解析器，用route -n get default查看默认出口。若 TUN 开启后默认出口变化异常，先关闭自定义路由和多余 VPN，再复测。 - Linux：查看
ip route与resolvectl status，确认默认路由和 DNS 服务器没有指向已经不存在的接口。 - Android：检查系统“私人 DNS”。官方文档说明，Android 开启私人 DNS 时，DNS 请求可能无法被自动劫持；应先临时改为自动进行对比测试，再决定是否保留。不要把某个公共 DNS 地址当成所有网络环境的通用答案。
DNS 选择应按网络环境复测：本地网络、出口节点所在地区和目标域名类型都会影响结果。先使用原配置建立基线，再修改一个 nameserver、fallback 或 proxy-server-nameserver 项。官方文档说明，proxy-server-nameserver 专门用于解析代理节点域名，配置不当可能形成“节点域名无法解析”的循环问题。
Windows、macOS、Linux、Android 的回滚顺序
| 设备 | 先恢复什么 | 仍失败时检查什么 |
|---|---|---|
| Windows | 关闭 TUN，关闭系统代理或恢复原代理设置 | 管理员权限、防火墙放行、默认路由、其他 VPN、网卡优先级 |
| macOS | 关闭 TUN 与网络扩展，确认 Wi-Fi 或有线网络恢复 | 网络扩展权限、utun 接口、默认路由、系统 DNS |
| Linux | 关闭 TUN，清理由客户端创建的路由或重启网络服务 | 权限、iptables/nftables、auto-redirect、默认路由和 DNS |
| Android | 停止 VPN，关闭私人 DNS进行对比 | VPN 权限、电池限制、应用分流、include/exclude package |
如果关闭 TUN 后网络仍未恢复，先退出所有重复运行的 Mihomo 核心和其他代理工具，再重新连接 Wi-Fi 或有线网络。不要在网络尚未恢复时继续修改配置，否则可能把残留路由、系统代理和新配置混在一起。
复测清单：确认不是“看起来已连接”
- 普通代理模式下，同一节点可以连接。
- TUN 虚拟网卡已创建，日志没有持续的权限或路由错误。
- 域名解析与 IP 访问都能完成。
- 浏览器、命令行和至少一个原本失败的应用分别测试过。
- 检查 Rule、Global、Direct 后，确认规则命中结果与预期一致。
- 关闭 TUN 后，系统代理、默认路由和 DNS 能恢复到原状态。
- 若问题仍存在，保留客户端版本、系统、配置片段、日志关键词和复现步骤；分享日志前删除订阅地址、节点密码、UUID、密钥和个人 IP。
若需要核对核心版本或变更记录，应直接查看 Mihomo 官方发布页；本文不把未核实的版本号或客户端界面行为写成固定规则。
常见问题
开启 TUN 后断网，先换节点还是先改 DNS？
先关闭 TUN 测试同一节点。普通代理也失败，优先查节点、订阅、端口或本地网络；普通代理正常而 TUN 失败，才进入权限、路由和 DNS 分支。这样可以避免把 TUN 接管问题误判为节点问题。
TUN 显示运行，为什么还是打不开网页？
“运行”通常只说明虚拟网卡或核心已经启动，不代表 DNS、规则、出口网卡和节点链路都正常。先用 nslookup、系统路由查看命令和客户端日志分别确认解析、路由与节点连接。
需要把 stack 改成某个固定值吗？
不能一概而论。stack 与系统、应用、内核和防火墙存在兼容性差异，先保持当前值；只有日志或复测明确指向协议栈兼容性时，才一次切换一个值并回滚验证。官方 TUN 文档列出了不同 stack 的行为差异，应以当前核心文档为准。
fake-ip 会不会直接导致所有网络断开？
Fake-IP 本身不等于故障，但 DNS、规则、fake-ip-filter 与应用兼容性组合不当时，可能表现为域名失败或部分应用异常。先对比 Redir-Host 或原 DNS 配置，确认是域名解析问题后再调整过滤规则。
为什么 Windows、macOS、Linux 的同一份 TUN 配置不能直接照搬？
因为 DNS 劫持、路由、防火墙和虚拟网卡由操作系统分别处理。官方文档明确区分了 Windows、macOS、Linux 和 Android 的 dns-mode、strict-route、auto-redirect 条件，配置应按设备逐项核对。
常见问题
Mihomo TUN 开启后无法上网，第一步做什么？
先关闭 TUN，使用同一节点和普通代理测试。如果普通代理正常，问题集中在权限、虚拟网卡、路由或 DNS；如果普通代理也失败，应先排查节点、订阅或本地网络。
TUN 显示已启动但网页打不开怎么办？
分别测试 IP 和域名，再查看系统路由、DNS 与 Mihomo 日志。IP 可访问而域名失败时优先查 DNS、Fake-IP 和 DNS 劫持；全部超时时再查出口网卡、路由和节点。
Windows 开启 TUN 后 DNS 异常怎么处理？
确认核心程序已通过防火墙，检查 <code>strict-route</code> 与 DNS 配置，并用 <code>ipconfig /all</code>、<code>nslookup</code> 对比开启前后的解析结果。每次只改一个配置项。
Android 开启 TUN 后部分应用不能联网怎么办？
先检查系统 VPN 权限、私人 DNS、应用分流和 include/exclude package。Android 开启私人 DNS 时，DNS 请求可能无法被自动劫持，应先临时改为自动进行对比测试。
排查完成后如何恢复原网络？
关闭 TUN，退出重复运行的核心和其他 VPN，恢复系统代理与 DNS，再检查默认路由。若仍无网络，重连当前 Wi-Fi 或有线网络后再复测。