Mihomo 连接失败：从日志、DNS 到 TUN 的排查步骤
简答：Mihomo 连接失败，先关闭 TUN 和自定义 DNS，用普通代理端口测试；再根据日志区分配置、端口、节点或解析问题，最后逐项恢复设置。
定义：Mihomo 连接失败，是指客户端已启动但无法加载配置、连接节点、解析域名，或流量没有被正确转发到代理端口。
先按现象分流：不要一开始就换节点
本文是第三方使用指南，不代表任何 Mihomo 客户端、订阅服务或节点服务的官方立场。先打开 Mihomo 客户端的日志面板，保持页面可见，然后访问一个普通网页或执行一次连接测试。官方文档说明，log-level 控制内核日志输出，debug 会输出尽可能多的运行信息；排查完成后可改回 info。参见Mihomo 全局配置中的日志级别说明。 github.com
| 现象或日志 | 优先怀疑 | 先做什么 |
|---|---|---|
| 客户端没有新日志 | 系统代理未生效、应用没有走 Mihomo、内核未启动 | 确认当前模式和系统代理，先关闭 TUN，再用浏览器手动设置代理端口 |
| 所有节点都 timeout | 订阅失效、节点域名解析失败、本地网络或协议参数问题 | 先确认订阅能否更新，再测试节点域名解析和单个节点 |
| 只有一个节点失败 | 该节点地址、端口、证书或服务端状态 | 换同一订阅中的另一个节点，其他设置不要同时改 |
dns resolve failed 或 no such host | DNS 上游、节点域名或目标域名解析失败 | 暂时恢复简单 DNS 配置，区分是节点域名还是目标网站域名 |
| 开启 TUN 后断网 | 权限、路由接管、DNS 劫持、防火墙或其他 VPN 冲突 | 关闭 TUN 做对照测试，再逐项恢复 TUN 选项 |
| 配置加载失败或 YAML 报错 | 缩进、字段拼写、客户端内核版本不支持 | 备份配置，恢复最近一次能启动的配置，再一次只改一个字段 |
最快判断标准：关闭 TUN 后普通代理端口能用，问题通常在 TUN、路由或 DNS 接管；关闭 TUN 后仍然所有节点超时，优先查订阅、节点解析、本地网络和协议配置。
第一步：确认客户端、内核、配置和运行模式
- 确认你使用的到底是哪个客户端。“Mihomo”是内核名称，Mihomo Party、桌面客户端或移动端应用的菜单和日志位置可能不同。先在客户端的关于、内核或版本页面记录客户端版本、Mihomo 内核版本、操作系统和当前模式。
- 确认配置已成功加载。如果客户端启动后马上提示 YAML 解析错误、字段不存在或配置无效，不要继续测试节点。先复制配置文件作为备份，再检查缩进、冒号、列表层级和字段名称。尤其不要把其他内核的字段直接复制到 Mihomo 配置中。
- 确认模式和代理组。官方文档列出的运行模式包括
rule、global和direct；其中global仍需要在全局策略组中选择代理，direct会绕过代理。排查时可先用全局模式选择一个明确节点，测试成功后再恢复规则模式。参见Mihomo 全局配置文档。 github.com - 确认内核是否真的在运行。如果客户端有控制页面，检查运行状态、当前配置和日志是否随访问请求增加。官方 API 文档提供了
/version和/configs的 GET 接口，可用于确认内核版本和当前运行配置。不要把带有订阅地址、令牌或认证信息的配置内容公开。参见Mihomo API 文档。 github.com
在本机控制端口仍为 9090 时，可在终端中执行以下 GET 请求；命令中的 User-Agent 只是为了让请求行为更接近普通客户端，不会替代认证：
curl -A "mihomo-diagnostic" "http://127.0.0.1:9090/version"
curl -A "mihomo-diagnostic" "http://127.0.0.1:9090/configs"
如果使用 PowerShell，请在 PowerShell 中执行：Invoke-WebRequest -Method GET -Headers @{"User-Agent"="mihomo-diagnostic"} -Uri "http://127.0.0.1:9090/version"。若控制端口不是 9090，替换为客户端显示的控制端口。不要在命令、截图或文章中打印 Cookie、token 或 secret。
第二步：检查 mixed-port、控制端口和系统代理
代理端口和控制端口不是一回事。官方示例使用 mixed-port: 7890 接收代理流量，使用 external-controller: 127.0.0.1:9090 提供控制 API；你的客户端可能使用其他端口，应以当前运行配置为准。参见官方最小运行配置示例和Mihomo 全局配置文档。 github.com
- 在客户端设置中找到代理端口，记录
mixed-port、HTTP 或 SOCKS 端口；不要把9090误填给浏览器作为代理端口。 - Windows 在 PowerShell 中执行
Get-NetTCPConnection -LocalPort 7890 -State Listen；如果使用其他端口，把7890换成实际端口号。 - macOS 或 Linux 在终端执行
lsof -nP -iTCP:7890 -sTCP:LISTEN，检查是否有进程监听该端口。 - 如果端口被其他程序占用，关闭冲突程序或在 Mihomo 中改用未占用的端口，然后同步更新系统代理设置。
- 先让浏览器使用 HTTP 或 mixed 代理端口进行测试。若浏览器能访问、终端或某个应用不能访问，说明应用可能没有遵循系统代理，需要在应用自身设置代理，或改用 TUN 做对照测试。
如果控制页面打不开，但内核日志正常，优先检查控制端口和监听地址；如果浏览器打不开而控制页面能打开，优先检查代理端口、代理组和系统代理，而不是继续修改控制 API。
第三步：区分订阅失败、节点失败和本地网络失败
- 订阅更新失败：检查客户端显示的 HTTP 状态、响应时间和响应内容。若返回的是登录页、错误页或普通 HTML，而不是客户端能识别的订阅内容，订阅地址、权限、服务状态或转换方式可能有问题；本文无法替你核实具体服务是否有效，应以服务提供方的公开说明为准。
- 只有一个节点失败：保留当前配置，只切换到同一订阅中的另一个节点。如果另一个节点可以连接，不要立刻修改 DNS、TUN 和规则，先把问题限定为单节点或单协议参数。
- 所有节点失败：先确认节点域名能解析、系统时间正确、网络没有被其他 VPN 或安全软件拦截，再检查订阅是否能正常更新。若换到另一条网络后所有节点仍失败，才继续查配置和内核版本。
- 日志出现 TLS 或握手失败：检查系统日期和时间、节点地址、端口、传输层参数及证书校验相关配置。不要为了“先连上”长期关闭证书校验；若必须做对照，只应短时间、在可信测试环境中进行。
升级或更换内核前先备份当前配置。Mihomo 官方发布页会列出版本、变更记录和不同系统架构的文件；下载时应根据系统和 CPU 架构选择，并核对发布页提供的 SHA-256，而不是使用来源不明的安装包。参见Mihomo 官方 Releases。 github.com
第四步：DNS 报错怎么查，什么时候暂时关闭 fake-ip
Mihomo 官方 DNS 文档将 default-nameserver、nameserver、fallback、proxy-server-nameserver 和 direct-nameserver 区分为不同用途。其中，proxy-server-nameserver 专门用于解析代理节点域名；没有单独配置时，节点域名会遵循其他 DNS 配置。参见Mihomo DNS 配置文档。 github.com
- 先看错误中的域名：是订阅域名、节点域名、目标网站，还是 DNS 上游域名。不同对象失败，排查位置不同。
- 备份配置后，暂时减少自定义 DNS 规则，只保留一个可用的
nameserver和必要的default-nameserver，一次只改一个变量。 - 如果节点域名无法解析，优先检查
proxy-server-nameserver；如果只有目标网站无法解析，再检查nameserver-policy、规则和目标域名。 - 若启用了
fake-ip后只有局域网设备、企业域名或特定应用异常，可暂时切换到另一种增强模式进行对照。确认根因前不要同时修改 fake-ip、规则和 TUN。 - 恢复连接后，逐项恢复 DNS 策略，并每次访问同一网址验证，避免无法判断是哪一项修改产生了效果。
如果客户端提供 DNS 缓存清理功能，可在控制页面执行清理；官方 API 文档列出 DNS 缓存清理接口为 POST，排查版本和配置时则使用 GET 的 /version、/configs。不要把 POST 清理接口误当成状态检查接口。 github.com
第五步：开启 TUN 后断网的排查顺序
TUN 会接管系统流量，问题范围比普通代理端口更大。官方 TUN 文档说明，auto-route 用于自动设置路由，auto-detect-interface 用于自动识别出站网卡；DNS 模式还涉及系统 DNS 设置和 DNS 劫持，不同系统的默认行为并不完全相同。参见Mihomo TUN 官方文档。 github.com
- 关闭 TUN，保留普通代理端口，确认节点和 DNS 是否能工作。若普通代理正常，说明问题集中在 TUN 接管链路。
- 重新开启 TUN 时确认系统授权：Windows 可能需要管理员权限，macOS 可能需要允许网络扩展或防火墙放行，Linux 可能需要相应权限，Android 需要允许应用创建 VPN。具体提示以当前客户端界面为准。
- 多网卡设备不要盲目依赖自动识别。Wi-Fi、网线、虚拟网卡和其他 VPN 同时存在时，检查
auto-detect-interface是否选到了正确出口。 - 如果使用 DNS 劫持或类似接管选项，先确认 DNS 配置存在且能独立解析；Windows 端按官方说明，相关 DNS 劫持模式可能依赖严格路由设置，Linux 端的对应行为可能依赖自动重定向设置。
- 暂时退出其他 VPN、虚拟网卡工具、防火墙增强模块和网络过滤软件，再测试一次。恢复时一次只启用一个组件。
- 如果 TUN 后只有某个应用异常，检查该应用是否使用自带 DNS、独立代理或自己的网络栈；这类应用不一定遵循系统代理。
Windows、macOS、Linux 和 Android 的 TUN 菜单名称可能由客户端界面决定，但排查顺序可以固定为：权限 → 出口网卡 → 路由 → DNS 接管 → 防火墙 → 其他 VPN。不要在 TUN 尚未稳定前继续叠加复杂规则。
恢复连接后的复测清单
- 先用一个固定节点和一个固定网址测试，记录日志中是否出现请求。
- 再从全局模式恢复到规则模式，确认代理组仍选择了可用节点。
- 再恢复自定义 DNS，分别测试普通域名、节点域名和局域网域名。
- 最后恢复 TUN，并检查浏览器、终端、办公软件等不同应用是否都能连接。
- 如果需要长期使用，保留一份“最小可用配置”和一份完整配置；再次失败时先回到最小配置，而不是同时重装客户端、换节点和改 DNS。
若仍然无法定位，可收集脱敏后的错误文本、操作系统、客户端和内核版本、当前模式、是否启用 TUN、失败域名类型以及单节点或全节点现象。隐藏订阅地址、用户名、密码、令牌、控制 API secret 和节点密码。
常见问题
Mihomo 连接失败，应该先换节点吗？
不建议先换节点。先看日志并关闭 TUN，用普通代理端口测试；如果只有一个节点失败，再换同一订阅中的另一个节点。如果所有节点都失败，应先查订阅、节点域名解析、本地网络和配置。
Mihomo 显示 dns resolve failed 怎么办？
先看失败的是订阅域名、节点域名还是目标网站域名。节点域名优先检查 proxy-server-nameserver，目标网站再检查 nameserver、nameserver-policy 和 fake-ip。备份配置后一次只改一个 DNS 变量。
Mihomo 开启 TUN 后断网，关闭 TUN 就正常，说明什么？
这通常说明节点本身可能可用，故障集中在 TUN 的权限、路由、出口网卡、DNS 接管、防火墙或其他 VPN 冲突。先确认普通代理端口正常，再逐项恢复 TUN 设置。
mixed-port 和 external-controller 有什么区别？
mixed-port 是浏览器或应用连接代理的入口，external-controller 是客户端面板和 API 控制内核的入口。两者用途不同，不能把控制端口直接填成浏览器代理端口。
Mihomo 没有日志，是不是节点一定失效？
不一定。没有新日志也可能是应用没有走系统代理、系统代理未启用、TUN 未接管流量或内核没有正常运行。先用固定浏览器访问并观察日志，再检查当前模式和代理端口。