BestVPN - 高速VPN与全能AI助手

Mihomo 连接成功但打不开网页怎么办？DNS、规则和系统代理排查

更新于 2026-11-11 · bv2.best

简答：先关闭 TUN，仅保留系统代理，再用浏览器访问测试页；如果仍打不开，检查 Mihomo 的 DNS 与运行模式，最后查看规则命中和日志。客户端显示“已连接”只代表核心或节点状态正常，不等于浏览器流量已经经过代理。成功判据是浏览器能打开测试网页，并且 Mihomo 面板出现对应请求记录。

定义：“Mihomo 连接成功但打不开网页”是指核心已启动或节点测试成功，但浏览器流量没有正确经过系统代理/TUN、DNS 解析失败，或被规则分配到了不可用的出站。

先做这 3 步：最快恢复与成功判据

本文是第三方使用指南，按 Mihomo 官方文档和 Clash Verge Rev 公开文档于 2026 年 11 月 11 日核对。先不要同时修改 DNS、规则和 TUN，否则很难判断是哪一环恢复。

  1. 关闭 TUN：在所用图形界面中关闭虚拟网卡/TUN，只保留系统代理；如果找不到完全相同的菜单名称，请查找“System Proxy”“TUN Mode”或“虚拟网卡”等对应开关。Clash Verge Rev 的界面将系统代理和 TUN 分开，并明确提示 TUN 开启后通常不需要再开启系统代理。查看界面字段
  2. 确认运行模式：将 Mihomo 运行模式暂时设为 rule；如果配置中使用了 global，确认 GLOBAL 策略组确实选中了可用代理；不要用 direct 作为“远程出站”测试，因为 DIRECT 代表直连。查看运行模式与日志级别说明
  3. 验证请求是否进入核心：打开浏览器访问一个平时可访问的网页，同时观察面板的请求/连接记录。若没有任何请求，优先查系统代理或浏览器代理；若有请求但失败，再查 DNS、规则和节点。

成功判据：浏览器网页可以打开，面板中能看到对应域名请求，且请求被分配到预期的代理组或 DIRECT 出站。节点延迟测试正常只能说明某一种测试请求成功，不能单独证明浏览器流量已经接管。

按“现象→检查→判断→处理→回滚”排查

现象先检查可能断点处理动作
面板有节点，但浏览器没有请求记录系统代理、浏览器代理、TUN 开关流量没有进入 Mihomo先关闭 TUN，只启用系统代理；仍无请求时检查 Windows 代理设置
有请求记录，但域名解析失败DNS 日志、nameserver、fallbackDNS 链路或 DNS 策略异常先回到简单 DNS 配置，清理 DNS 缓存后重试
域名能解析，但请求超时或连接被拒绝规则命中、代理组、节点日志规则分流、节点出站或目标站点临时切换到明确可用的代理组；对比 DIRECT 与代理结果
开启 TUN 后全局断网虚拟网卡、服务权限、路由和协议栈TUN 接管或网卡冲突先关闭 TUN 恢复网络，再检查 auto-route、auto-detect-interface 与权限

这张表只用于定位方向，不把“超时”简单等同于 DNS 故障：超时也可能来自规则误匹配、目标站点、路由、MTU、防火墙或代理端口。每次只改一项，并记录修改前的配置，便于回滚。

第一断点：DNS 配置不要一上来堆满 fallback

Mihomo 的 DNS 字段职责不同。nameserver 是常规域名解析服务器；fallback 是备用解析服务器；fallback-filter 用于筛选或判断备用结果；nameserver-policy 可按域名或规则集指定解析服务器；proxy-server-nameserver 专门用于解析代理节点域名。官方文档并没有要求所有环境必须使用某个固定公共 DNS。查看 Mihomo DNS 字段定义

建议的临时回退方法：

  1. 备份当前配置文件。
  2. 暂时移除复杂的 nameserver-policy、fallback-filter、proxy-server-nameserver-policy 和多层规则，只保留一组确认可达的 nameserver；DNS 地址是否可达要结合当前网络环境判断。
  3. 如果代理节点本身使用域名，再单独确认 proxy-server-nameserver 能解析节点域名；不要让解析代理节点的请求又依赖一个必须先经过该代理才能访问的 DNS 链路。
  4. 重载配置，清理 DNS 缓存，再访问同一个测试域名。

“nameserver 与 fallback 冲突”不是普遍规则。更具体的循环风险是：解析代理节点需要代理，代理又依赖该节点先完成域名解析，或者多个策略把同一类 DNS 请求反复送回依赖自身的链路。判断时要看日志中解析的是普通网页域名还是代理节点域名，不能只看到 timeout 就断定存在死循环。

如果配置使用 Fake-IP，先不要随意修改 fake-ip-range 或 TTL；可以先切换到简单配置验证问题是否来自 Fake-IP，再根据应用兼容性逐项恢复。官方文档还提供了清理 DNS 缓存和 Fake-IP 缓存的 API：/cache/dns/flush 与 /cache/fakeip/flush。查看 Mihomo API 与缓存清理说明

第二断点：系统代理和 TUN 只能先选一个验证

系统代理只会影响遵守系统代理设置的应用；TUN 通过虚拟网卡接管更广泛的系统流量。排查时不要同时打开两者，因为双重接管会增加判断难度，某些应用还可能出现代理绕行或重复转发。

  1. 系统代理路径：关闭 TUN，打开 Mihomo 的系统代理开关，然后到 Windows“设置→网络和 Internet→代理”确认手动代理没有被关闭或残留错误地址。若 Mihomo 已退出但网页仍打不开，也要检查 Windows 是否还保留了旧代理设置；Clash Verge Rev 文档将此列为常见恢复动作。查看 Windows 代理排查说明
  2. TUN 路径：先恢复系统代理可用，再单独开启 TUN。确认服务模式或管理员权限已满足当前界面要求，并观察是否出现 Mihomo 虚拟网卡。Mihomo 文档说明，auto-route 用于自动设置路由，auto-detect-interface 用于检测出站网卡；多网卡设备可能需要手动指定实际出站接口。查看 TUN 参数说明
  3. 异常回滚：开启 TUN 后断网，立即关闭 TUN，不要继续修改 DNS。记录虚拟网卡是否存在、系统路由是否变化、服务是否运行，再逐项恢复。不同版本和图形界面对 stack、dns-mode、strict-route 的支持可能不同，无法确认时以当前版本文档和界面为准。

第三断点：规则命中不等于节点可用

Mihomo 规则按配置顺序从上到下匹配，前面的规则优先级更高，最后通常由 MATCH 兜底。某个域名被匹配到 DIRECT，并不表示网页一定能直连；被匹配到代理组，也不表示当前策略组已选中可用节点。查看规则匹配顺序

  1. 在面板中找到出问题的域名，记录它命中的规则和出站。
  2. 临时把策略组切换到一个明确可用的代理节点，重新访问同一个域名。
  3. 再分别对比代理出站与 DIRECT。如果只有代理成功，问题可能在直连路径或规则分流；如果两者都失败，继续看 DNS、节点握手、目标站点或本机网络。
  4. 检查规则末尾是否存在合理的 MATCH 兜底，避免部分请求没有明确处理。不要为了“强制代理”直接删除所有规则，先备份并只测试一个域名。

如果日志出现规则重复匹配、反复进入同一策略或请求迟迟不结束，应检查是否使用了 rematch、sub-rule 等高级规则。官方文档特别提醒，错误的 rematch 顺序可能形成循环；没有使用这些高级功能时，不要把普通的 DNS 超时直接称为规则死循环。查看 rematch 循环说明

终极调试：用日志定位是解析、入站还是出站

将日志级别临时调到 debug，只复现一次问题，然后恢复为 info 或更低级别。Mihomo 官方定义了 silent、error、warning、info 和 debug 等级；Clash Verge Rev 的设置字段中也提供了对应日志级别和打开日志目录的入口。查看 Mihomo 日志级别 查看界面日志入口字段

  • 没有请求记录：优先看系统代理、TUN、浏览器代理和端口监听。
  • 出现 DNS error、resolve failed：看普通域名解析与代理节点域名解析分别使用了哪组 DNS。
  • 出现 connection refused：检查本地混合端口或 HTTP/SOCKS 端口是否被占用、浏览器是否填错端口。
  • 出现 timeout：不要单独下结论；结合命中的规则、出站名称、节点握手、路由和目标站点重复验证。
  • 只有 TUN 失败：查看虚拟网卡、服务权限、自动路由、网卡选择和防火墙相关信息。

如果启用了外部控制器，可以通过 API 查看实时日志、运行配置和版本；官方 API 文档说明 /logs 支持按日志级别读取，/configs 可查看当前运行配置，/version 可查看核心版本。不要公开外部控制器地址或 secret。查看 API 日志与运行配置接口

一套可回滚的最终处理顺序

  1. 导出或复制当前配置，记录客户端版本和操作系统。
  2. 关闭 TUN，只启用系统代理，模式设为 rule。
  3. 用简单 DNS 验证网页是否恢复，不要先加入更多 fallback 或策略。
  4. 查看请求记录，确认浏览器流量已经进入 Mihomo。
  5. 检查域名命中的规则、策略组和实际出站，分别测试代理与 DIRECT。
  6. 网页恢复后，一次只恢复一个高级功能：Fake-IP、DNS 分流、TUN、自动路由或多网卡设置。
  7. 每恢复一项就访问同一个测试网页；再次失败时回滚最后一次改动。

如果无法确认配置字段、菜单含义或安装包来源，不要继续导入未知配置或绕过系统安全提示；优先使用可核验的版本说明和当前客户端界面。

常见问题

Mihomo 节点延迟正常，为什么网页还是打不开？

延迟测试只代表某一种测试请求成功，可能是 ICMP、TCP、HTTP 或代理测试，不能证明浏览器已经使用系统代理，也不能证明 DNS、规则和网页目标站点都正常。先看浏览器请求是否出现在 Mihomo 面板，再判断故障层级。

fallback 一定要配置吗？

不一定。fallback 是备用解析链路，不是所有环境的必填项。先用简单且可达的 DNS 验证基础链路，再根据域名分流需求增加 fallback-filter 或 nameserver-policy。具体可达性取决于当前网络环境。

nameserver 和 proxy-server-nameserver 应该填一样吗？

不应机械地填成一样。前者用于常规域名解析，后者主要用于代理节点域名解析。是否使用相同服务器要看解析链路是否可达，以及配置是否会让代理节点解析依赖尚未建立的代理连接。

TUN 开启后断网，直接换 gvisor 或 system 可以吗？

可以作为针对当前版本的单项测试，但不能保证适用于所有系统和图形界面。更稳妥的顺序是先关闭 TUN 恢复网络，记录服务、虚拟网卡和路由状态，再按当前版本文档逐项测试 stack、auto-route、dns-mode 和网卡选择。

日志里出现 timeout，是不是节点坏了？

不能仅凭 timeout 判定。它可能来自 DNS、规则误匹配、代理节点握手、目标站点、路由、MTU 或防火墙。对同一域名分别测试代理和 DIRECT，并结合日志中的出站名称与解析对象判断。

常见问题

Mihomo 显示已连接但浏览器没有任何请求记录，先查什么？

先关闭 TUN，只保留系统代理；然后确认 Windows 系统代理开关、浏览器代理设置和 Mihomo 监听端口。没有请求记录通常说明流量尚未进入核心。

DNS 配置中 nameserver、fallback、nameserver-policy 有什么区别？

nameserver 用于常规解析，fallback 是备用解析，nameserver-policy 可按域名或规则集指定解析服务器。它们不是互相冲突的固定组合，应结合实际解析链路判断。

开启 TUN 后断网如何回滚？

立即关闭 TUN，恢复系统代理或关闭系统代理残留，然后检查虚拟网卡、服务权限、自动路由和出站网卡。确认基础网络恢复后，再一次只测试一个 TUN 参数。

延迟测试正常是否说明网页一定能打开？

不是。延迟测试的协议和目标可能与浏览器网页不同，低延迟不能直接证明 DNS、TCP 握手、规则分流或浏览器代理均正常。

日志中的 timeout 是否等于节点不可用？

不等于。timeout 还可能由 DNS、规则、目标站点、路由、MTU、防火墙或本地代理端口造成，应结合出站、解析对象和对比测试判断。

相关阅读

参考资料

  1. Mihomo 全局配置与日志级别文档
  2. Mihomo API 文档
  3. Clash Verge Rev Windows 常见问题（clashverge.dev）
  4. Clash Verge Rev 设置字段