Mihomo连接成功但无法上网怎么办？按节点、DNS与TUN排查
简答：Mihomo显示“已连接”通常只代表核心、配置或TUN已启动，不等于浏览器和应用的流量已经通过可用节点。最快的处理方法是：先确认关闭Mihomo后普通网络正常，再暂时关闭TUN，仅用HTTP、SOCKS或mixed端口测试；如果端口代理能上网，问题多半在TUN、系统路由或DNS接管。若端口代理也打不开，再检查当前节点、代理组、规则、订阅和日志。
定义：Mihomo连接成功但无法上网，是指客户端或内核显示运行正常，但浏览器、系统应用或部分App仍无法建立可用的DNS解析或网络连接。
先试这一步：5分钟判断故障在哪一层
不要同时修改节点、DNS、规则和TUN。先按下面的顺序做一次最小化测试，目标是把问题分成“普通网络、节点与代理、规则、DNS、TUN接管”五层。
| 顺序 | 操作 | 观察结果 | 下一步 |
|---|---|---|---|
| 1 | 完全退出Mihomo，打开普通网页 | 普通网络也打不开 | 先修复Wi-Fi、网线、系统网络或路由器，不要继续改Mihomo |
| 2 | 重新启动Mihomo，暂时关闭TUN，只保留普通代理端口 | 普通代理可以上网 | 重点检查TUN、系统路由、DNS接管和权限 |
| 3 | 确认系统代理已打开，或在浏览器中手动填写Mihomo的HTTP/SOCKS端口 | 端口代理也不能上网 | 检查节点、代理组、订阅和日志 |
| 4 | 查看连接记录、流量统计和当前策略 | 请求被DIRECT、REJECT或无连接记录 | 检查运行模式、规则顺序和策略组 |
| 5 | 最后再恢复TUN并观察 | 开启TUN后再次断网 | 检查auto-route、strict-route、DNS模式、出口网卡和系统权限 |
官方文档将TUN描述为用于接管系统流量、自动路由和DNS处理的入口；因此，TUN开启后出现“客户端已连接但整机无网”，应优先把它作为独立故障层排查，而不是直接认定节点失效。可参考Mihomo TUN配置说明。
第一层：确认节点、配置和代理组真的在工作
- 确认配置已加载。在客户端面板查看当前激活的配置文件，避免只完成订阅导入但没有激活配置。部分前端会在切换配置后自动重载，菜单名称可能不同。
- 确认订阅状态。检查订阅更新时间、剩余流量或到期提示。如果订阅刷新失败、节点列表为空或所有节点都显示不可用，应先重新更新配置；具体状态以客户端当前显示为准。
- 确认策略组不是DIRECT或REJECT。在规则模式下，命中的策略可能是直连或拒绝；全局模式则需要在GLOBAL策略组中选中一个实际节点。Mihomo官方配置说明列出的运行模式包括rule、global和direct，其中rule是默认模式。参考Mihomo全局配置与运行模式。
- 手动选择一个可用节点。先不要使用自动选择、故障转移或复杂代理组，选择一个明确显示可用、延迟测试能返回结果的节点进行测试。延迟测试成功不等于网页一定可用，但完全没有测试结果通常值得先查节点域名解析或连接超时。
- 检查连接记录。打开面板中的Connections、连接、流量或类似页面，访问一个网页后观察是否出现新请求、请求的策略名称、最终链路和错误信息。官方Dashboard支持连接跟踪、实时日志和代理组管理，可参考MetaCubeX官方Dashboard说明。
如果访问网页时完全没有连接记录，优先检查系统代理是否打开、浏览器是否使用了自己的代理设置，以及当前应用是否绕过系统代理。如果有连接记录但请求立即被拒绝或命中REJECT，优先检查规则和策略。
第二层：用普通代理端口隔离TUN问题
暂时关闭TUN，只保留HTTP、SOCKS或mixed代理端口，是最有价值的分流动作。普通代理只接收明确指向该端口的应用流量；TUN则在网络层接管更广泛的系统流量，两者出现问题时排查范围不同。
- 关闭TUN或“增强模式”，保存并重新载入配置。
- 打开系统代理开关；如果前端没有自动设置，可在浏览器或系统网络代理中填写客户端显示的HTTP或mixed端口。
- 访问一个平时可打开的网页，再访问一个需要代理策略的网页。
- 查看连接记录，确认请求是否进入Mihomo，并观察最终策略是节点、DIRECT还是REJECT。
结果判断：如果关闭TUN后可以访问，节点和基础代理端口大概率可用，问题集中在TUN路由、DNS接管、系统权限、防火墙或多网卡出口。如果关闭TUN后仍打不开，则继续检查节点、代理组、规则和DNS。
并非所有应用都会遵循系统代理。浏览器通常可以单独设置代理，但部分游戏、终端程序、后台服务或移动应用可能需要TUN、VPN模式或应用自身的代理设置；不要把“浏览器能用”直接当成“所有应用都能用”。
第三层：根据日志区分DNS、超时、拒绝和路由错误
将日志级别临时调整为debug后，只复现一次问题，再恢复到info或warning，避免长期产生大量日志。官方全局配置文档说明，debug会尽可能输出运行中的信息。
| 日志或现象 | 通常说明 | 先做什么 |
|---|---|---|
| dns resolve failed | 域名解析失败，可能是DNS服务器、代理节点域名或DNS规则问题 | 检查DNS模块是否启用、nameserver是否可用，并确认代理节点域名能解析 |
| connect timeout或i/o timeout | 目标连接在规定时间内没有建立 | 更换一个明确可用的节点，检查本地网络、防火墙和节点服务器地址 |
| connection refused | 目标端口主动拒绝连接 | 检查节点地址、端口、协议参数和订阅内容，不要只看延迟 |
| network is unreachable | 系统没有可用路由或TUN出口异常 | 关闭TUN、恢复系统网络，再检查auto-route和出口网卡 |
| 请求命中DIRECT或REJECT | 规则或策略组没有按预期选择节点 | 查看规则命中结果，确认规则顺序和最终MATCH策略 |
Mihomo规则按从上到下的顺序匹配，顶部规则优先级更高；因此，一条过早命中的DOMAIN、GEOIP、RULE-SET或MATCH规则，可能让请求进入DIRECT或REJECT。不要只看“已连接”状态，应结合连接记录和日志判断实际出口。参考Mihomo路由规则文档。
第四层：DNS异常时检查哪些设置
如果网页表现为长时间转圈、浏览器提示找不到服务器、部分域名能打开而部分域名打不开，优先检查DNS。Mihomo的DNS配置涉及enable、nameserver、default-nameserver、proxy-server-nameserver、enhanced-mode、fake-ip和dns-hijack等字段，不建议一次性全部改动。
- 确认dns.enable。如果DNS模块被关闭，系统会继续使用系统DNS，TUN或规则接管可能与预期不同。
- 区分default-nameserver与nameserver。官方文档说明，default-nameserver主要用于解析DNS服务器自身的域名；nameserver用于普通域名查询。不要把二者当成同一个字段。
- 节点域名无法解析时看proxy-server-nameserver。该字段专门用于解析代理节点域名；如果节点服务器使用域名且这里没有可用解析路径，可能出现节点看似存在但无法建立连接。
- 检查fake-ip与应用兼容性。fake-ip是增强DNS模式之一，部分局域网设备、内网域名或特殊应用可能需要加入fake-ip-filter，具体以当前配置和应用表现为准。
- 检查dns-hijack和私人DNS。官方说明指出，Windows和macOS不能自动劫持发往局域网的DNS请求；Android开启“私人DNS”时，也可能无法自动劫持DNS请求。
DNS设置有较强的配置依赖，建议先保存原配置，再只改一个字段并复测。官方DNS文档可用于核对字段定义和解析流程：Mihomo DNS配置。
第五层：开启TUN后断网的恢复与检查
如果关闭TUN后恢复正常，说明需要重点检查TUN接管，而不是继续更换节点。先恢复网络，再逐项调整。
- 先关闭TUN。如果前端提供“恢复网络”“Recover network”功能，优先使用它；该功能用于拆除TUN路由并恢复普通网络。
- 正常退出客户端。不要直接结束进程或强制关机。官方Dashboard文档说明，正常退出会清理TUN并恢复路由；如果之前强制退出，重新打开客户端后再执行网络恢复。
- 检查auto-route。它负责把全局流量自动路由到TUN。配置错误或路由未清理时，可能导致系统流量没有可用出口。
- 检查auto-detect-interface。多网卡、虚拟网卡、Wi-Fi与网线同时连接时，自动识别的出口可能不是你希望使用的接口。官方建议多出口设备考虑手动指定出口网卡。
- 检查strict-route和dns-mode。Windows上的strict-route会增加用于阻止DNS泄露的防火墙规则，但也可能使某些应用在特定情况下异常；dns-mode为hijack时，在Windows通常还需要strict-route配合。
- 检查权限与防火墙。TUN需要系统级网络权限。Windows检查防火墙是否允许核心程序，macOS检查系统网络和后台辅助权限，Android检查VPN授权、私人DNS和电池后台限制。
官方TUN文档明确区分了Windows、macOS、Linux和Android的行为，菜单名称则取决于你使用的前端。不要直接复制其他系统的完整配置，尤其不要未经验证修改MTU；官方说明中MTU一般建议普通用户保持默认。
Windows、macOS、Android的分场景操作路径
Windows
- 先在系统设置中确认关闭Mihomo后网页正常。
- 关闭TUN，打开系统代理，访问网页并观察连接记录。
- 若普通代理可用而TUN不可用，检查Windows防火墙是否允许Mihomo核心程序，并确认是否有虚拟网卡、公司VPN或其他网络过滤软件冲突。
- 若开启strict-route后某些虚拟机、容器或局域网工具异常，先关闭strict-route复测，再决定是否需要保留。
macOS
- 先关闭TUN并测试浏览器代理，确认节点和代理端口是否正常。
- 开启TUN时留意系统管理员授权和网络扩展提示；如果强制退出后断网，重新打开客户端并执行网络恢复。
- macOS默认情况下的TUN DNS行为与Windows、Linux不同，局域网DNS请求也可能无法被自动劫持，应结合DNS日志判断。
Android
- 确认系统VPN授权已允许Mihomo运行，并检查当前是否开启了私人DNS。
- 如果只有某个App无法访问，查看TUN的应用包含或排除列表，确认该App没有被排除。
- 如果浏览器可用但某个App不可用，先检查应用分流和后台限制，不要直接判断节点失效。
以上路径只适用于具备相应功能的前端和系统版本，菜单名称可能显示为TUN、VPN、增强模式、系统代理、服务模式或网络恢复。
复测、回滚与安全检查清单
每次只改一项，改完后完成同样的复测：访问一个普通网页、一个需要代理策略的网页，并查看连接记录是否出现请求、命中了什么策略、是否产生错误日志。
- 保留修改前的配置文件或配置备份，无法判断时先恢复原配置。
- 确认配置能够通过客户端的配置校验，再重新载入或重启内核。
- 不要把订阅链接、UUID、密码、Token、完整节点参数和控制器密钥发到公开论坛或截图中。
- 如果提交问题，至少提供系统、设备架构、客户端前端、Mihomo核心版本、复现步骤和脱敏后的错误信息。
- 如果关闭Mihomo后仍然断网，优先修复系统网络或清理残留路由，不要继续修改DNS和规则。
如果已经修改了TUN、DNS或系统代理但问题变得更复杂，最稳妥的回滚顺序是：关闭TUN→恢复系统代理→退出客户端→确认普通网络→重新载入原配置→只开启普通代理端口测试。
本文结论
Mihomo“连接成功但无法上网”最应先做的不是换节点，而是关闭TUN、用普通代理端口验证链路。普通代理能用，重点查TUN、路由、DNS、权限和防火墙；普通代理也不能用，重点查节点、订阅、策略组、规则和日志。定位后只修改对应层，避免把多个变量同时改掉。
常见问题
Mihomo显示已连接，为什么浏览器还是打不开网页？
“已连接”可能只表示核心、配置或TUN已经启动，不代表浏览器流量已进入代理并通过可用节点。先关闭TUN，打开系统代理或手动填写HTTP、SOCKS或mixed端口，再查看连接记录。
关闭TUN后能上网，说明节点一定没问题吗？
不能完全确定，但说明普通代理端口、当前节点或策略至少具备一定可用性，故障范围更集中在TUN路由、DNS接管、系统权限、防火墙或多网卡出口。还应通过连接记录和实际网页访问复测。
只有一个App无法联网，应该换节点吗？
不建议先换节点。先确认该App是否遵循系统代理，是否被TUN的应用包含或排除规则影响，Android还要检查私人DNS和后台限制。浏览器能用而单个App不能，通常需要按应用分流或应用自身代理设置继续排查。
Mihomo的DNS应该怎么改才不会断网？
不要直接套用整段配置。先确认dns.enable、nameserver、default-nameserver和proxy-server-nameserver的作用，再一次只修改一个字段并复测。若使用TUN，还要检查dns-mode、dns-hijack、fake-ip以及系统或Android私人DNS的影响。
开启TUN后断网，怎样最快恢复？
先关闭TUN；如果前端提供“恢复网络”或“Recover network”，优先使用；随后正常退出客户端并确认普通网络恢复。恢复后再检查auto-route、auto-detect-interface、strict-route、出口网卡、系统权限和防火墙。
排查日志时可以把订阅链接发给别人吗？
不建议。订阅链接、UUID、密码、Token、控制器密钥和完整节点参数都应脱敏或删除。提交问题时只保留系统、客户端、核心版本、复现步骤和必要的错误文本。