Mihomo 连接不上节点怎么办？按日志、DNS、TUN 逐步排查
简答：Mihomo 节点可见但连接不上时，先关闭 TUN 和系统代理，手动测试单个节点，再按日志区分端口、DNS、节点或规则问题。单节点失败通常查节点参数，全部节点失败则优先查订阅、DNS、系统时间和网络环境。
定义：Mihomo 连接不上节点，是指配置已经加载、节点能够显示，但节点测速、代理握手或实际连接无法完成的情况。
先做这一分钟判断：节点可见但连接失败，先不要改 DNS
本文是第三方使用指南，不代表 Mihomo 或任何客户端项目的官方页面。假如配置已经导入、节点列表也能显示，请先按下面顺序缩小范围：关闭 TUN，暂时关闭系统代理和其他代理软件，切换到手动选择的单个节点，再执行一次延迟测试或打开一个普通网页。
| 现象 | 优先检查 | 下一步 |
|---|---|---|
| 只有一个节点失败 | 节点域名、端口、认证参数或该节点状态 | 换同一订阅中的另一个节点对比 |
| 全部节点都失败 | 订阅、DNS、系统时间、本地网络、代理端口 | 先检查配置加载和域名解析 |
| 测速失败但网页偶尔能开 | 测速地址、策略组、URL-test 条件 | 手动选择节点并用实际网页复测 |
| 连接成功但应用打不开 | 规则模式、TUN、DNS 劫持和应用代理设置 | 先用全局模式或关闭 TUN 做对照 |
| 节点列表为空或更新失败 | 订阅地址、订阅有效期、网络和更新时间 | 先解决订阅更新，再测试节点 |
代理端口、控制器地址和配置字段以你使用的客户端设置页为准。Mihomo 官方文档说明，代理流量可以通过 HTTP、SOCKS、mixed-port、TUN 或 listeners 接入，不同客户端可能会自行分配端口，因此不要直接套用其他教程里的端口值。参考：Mihomo 入站配置。
第一步：确认内核运行、配置加载和代理端口监听
节点显示出来，不等于 Mihomo 内核已经正常工作。先在客户端日志或内核状态页确认没有配置解析错误，再确认代理端口确实处于监听状态。
- 检查配置是否加载成功：重新加载配置后观察日志，重点看是否出现 unknown field、配置解析失败、provider 更新失败或启动后立即退出。配置字段应以 Mihomo 官方配置文档为准；不认识的字段不要直接保留。
- 检查代理端口：在客户端设置页找到当前 mixed、HTTP 或 SOCKS 端口，记下实际值，不要使用示例中的固定端口。
- Windows：打开 PowerShell，替换占位符后执行：
Get-NetTCPConnection -State Listen -LocalPort <混合端口>- macOS 或 Linux：打开终端执行：
lsof -nP -iTCP:<混合端口> -sTCP:LISTEN如果没有监听结果，优先回到客户端检查内核是否启动、端口是否被其他程序占用，以及配置是否能通过校验。Mihomo 的运行模式包括 rule、global 和 direct；如果当前处于 direct，节点本身可能不会被实际使用。模式定义见 Mihomo 全局配置。
第二步：手动选择单个节点，区分节点故障和全局故障
不要一开始就依赖自动选择或 URL-test。进入代理组，手动选一个节点，记录结果，再换第二个节点复测。这样可以把“某个节点失败”和“所有节点失败”分开。
| 测试结果 | 较可能的故障层 | 建议动作 |
|---|---|---|
| A 节点失败，B 节点成功 | 单节点地址、端口、协议、认证或节点侧状态 | 检查订阅是否更新，暂时使用可连接节点 |
| 所有节点都超时 | 订阅参数、DNS、系统时间、本地网络或出口网络 | 继续做 DNS 和基础网络测试 |
| 节点能测速，实际网页打不开 | 规则、模式、DNS 或应用没有走代理 | 切换 global 做对照，再检查应用代理 |
| 自动组总是选到失效节点 | URL-test 测试地址、超时或策略组成员 | 手动选节点，并检查 url、interval、timeout |
URL-test 只会测试代理组中配置的 proxies；如果节点是通过 provider 或筛选条件加入，还要确认它确实进入了目标组。官方字段说明见 proxy-groups 配置和 url-test 配置。测速失败只说明指定测试请求没有按预期完成，不等同于所有业务都不可用，最好再用手动节点访问实际业务页面复测。
第三步：按日志关键词判断是端口、DNS 还是节点连接问题
把日志级别临时调整为 debug，重新发起一次连接，然后只截取与本次连接相关的几行，并删除订阅地址、用户名、密码、节点域名和 API 密钥。Mihomo 官方 API 提供实时日志接口，并支持 info、warning、error、debug 等级别，详见 Mihomo API 文档。
| 日志关键词或现象 | 常见判断方向 | 最小改动 |
|---|---|---|
| connection refused | 目标端口没有接受连接，或本地代理端口、节点端口填写错误 | 核对客户端实际监听端口和节点参数 |
| timeout | 连接在规定时间内没有完成，可能是节点、路由、丢包或防火墙 | 换一个节点，并用普通网络对比 |
| no such host、dns resolve failed | 域名没有解析成功，可能是订阅域名、节点域名或目标域名 | 先用 nslookup 或 dig 单独验证对应域名 |
| unknown field | 配置使用了当前内核不识别的字段 | 定位字段并对照官方文档删除或改正 |
| 连接成功但无流量 | 策略组未选中、规则走 DIRECT，或应用没有使用代理 | 切换 global，确认代理组当前选中的节点 |
这些关键词只能作为定位线索，不能脱离上下文直接下结论。特别是 timeout，既可能是节点问题，也可能是本地网络丢包、DNS 延迟或 TUN 路由异常。
第四步：检查节点域名解析和 DNS 配置
如果日志出现 no such host 或 dns resolve failed，先确定失败的是哪个域名：订阅地址、节点服务器域名，还是目标网站域名。三者处理方式不同。
- Windows：打开命令提示符或 PowerShell，执行：
nslookup <节点域名>- macOS 或 Linux：执行：
dig <节点域名>- Android：暂时关闭系统的私人 DNS，再关闭 Mihomo 的 TUN，使用普通代理测试；Android 开启私人 DNS 时，Mihomo 官方文档说明 DNS 请求可能无法被自动劫持。
- 配置层面：确认 default-nameserver 能解析 DNS 服务器地址，nameserver 用于普通域名解析，proxy-server-nameserver 专门用于解析代理节点域名。不要把一个无法通过当前网络访问的 DNS 地址同时作为唯一解析路径。
官方 DNS 文档明确区分了 default-nameserver、nameserver、fallback 和 proxy-server-nameserver 的作用。修改时只改一层，改完重新加载配置并复测，不要同时替换所有 DNS 字段。参考：Mihomo DNS 配置。
dns:
enable: true
default-nameserver:
- <可用的 DNS IP>
nameserver:
- <你的 DNS 地址>
proxy-server-nameserver:
- <用于解析节点域名的 DNS 地址>上面的地址只是占位符，必须替换为你已核验、且适合当前网络环境的 DNS 地址；不要直接复制占位符。
第五步：关闭 TUN、系统代理和其他代理软件做最小化对照
同时开启 TUN、系统代理、浏览器代理和其他网络工具时，可能出现端口冲突、路由重复、DNS 劫持互相覆盖或应用走错出口。排查时先只保留一种接管方式。
- 退出其他代理客户端、网络过滤器和可能修改系统代理的工具。
- 在 Mihomo 中暂时关闭 TUN。
- 关闭系统代理自动脚本或手动代理，只保留 Mihomo 的普通 HTTP、SOCKS 或 mixed 代理。
- 让浏览器或测试工具明确指向客户端设置页显示的代理地址和端口。
- 手动选择一个节点，重新测试 DNS、节点延迟和实际网页。
如果关闭 TUN 后恢复，问题范围就集中到 TUN 权限、路由、DNS 劫持、网卡选择或防火墙。Mihomo 官方 TUN 文档说明，auto-route 用于自动设置路由，auto-detect-interface 用于选择出口网卡，strict-route 会强化路由约束；dns-hijack 会把匹配的 DNS 请求导入内部 DNS 模块，具体行为还与系统有关。参考：Mihomo TUN 配置。
Windows、macOS、Linux 和 Android 的差异可按下面判断：
- Windows：优先检查 TUN 权限、系统代理和防火墙；启用 dns-mode 为 hijack 时，strict-route 可能影响 DNS 劫持行为。
- macOS：检查 VPN 或网络扩展授权、当前网络接口，以及是否存在其他代理配置。
- Linux：检查路由表、iptables 或 nftables；auto-redirect 仅适用于 Linux，并要求相关 TUN 路由条件满足。
- Android：检查 VPN 权限、私人 DNS、电池限制和应用是否被排除在 TUN 之外。
第六步：检查规则模式、策略组和代理是否真的被使用
如果节点本身可以连接，但浏览器或应用仍然直连，重点看运行模式和规则。rule 模式会按 rules 从上到下匹配；global 模式要求在 GLOBAL 策略组中选择代理；direct 模式则是全局直连。规则顺序越靠前优先级越高，最终的 MATCH 规则通常应放在规则末尾。参考 Mihomo 路由规则。
- 把模式临时切换为 global，并在 GLOBAL 或对应策略组手动选择节点。
- 如果 global 可以使用，rule 模式不可用，检查是否存在 GEOIP、DOMAIN、RULE-SET 或 MATCH 规则把请求送到了 DIRECT。
- 如果只有某个应用打不开，检查该应用是否使用独立代理设置、是否被 TUN 的 include 或 exclude 条件排除。
- 检查代理组当前的 now 或 selected 状态，不要只看节点是否出现在列表里。
rules:
- IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
- GEOIP,CN,DIRECT
- MATCH,<你的代理组名称>这是结构示例，不是可直接套用的完整配置；代理组名称必须替换为实际存在的名称。不要把不存在的组名写进 MATCH，也不要在不清楚作用时同时修改多条规则。
第七步：订阅、系统时间和网络环境检查
如果所有节点都失败，或节点列表刚刚更新后突然全部不可用，继续检查订阅和基础网络：
- 订阅更新：确认订阅地址仍可访问，更新结果没有报错，配置文件内的节点数量没有变成空值。
- 订阅状态：核对服务端显示的有效期、流量或节点参数是否变化；这些信息取决于订阅提供方，本文不对具体状态作推断。
- 系统时间：确认设备日期、时区和自动校时正常。TLS 连接对时间敏感，时间明显错误时可能出现证书或握手失败。
- 普通网络：先暂停 Mihomo，用浏览器访问常规网站，或在 Windows 执行
ping <网关地址>检查本地网络；不要把 ping 节点地址的结果直接当成应用层可用性结论。 - 网络切换：用另一条 Wi-Fi、手机热点或有线网络做一次对照，记录是所有网络都失败，还是只有当前网络失败。
如果更换网络后只有部分节点恢复，优先比较 DNS、丢包、出口策略和防火墙差异；如果所有网络都失败，再回到订阅、节点参数和配置解析检查。
复测标准：什么结果可以说明问题已定位
不要只看“节点列表变绿”或一次测速结果。完成修改后，按同一顺序复测并记录结果：
- 配置可以重新加载，日志不再出现新的 unknown field 或配置解析错误。
- 代理端口处于监听状态，客户端界面显示内核仍在运行。
- 手动节点测试至少完成一次，能区分单节点失败还是全部节点失败。
- 代理域名可以解析，且日志不再出现对应的 no such host 或 dns resolve failed。
- 关闭 TUN 的普通代理测试与开启 TUN 的系统流量测试结果一致，或已明确知道差异来自 TUN。
- 在当前模式下确认请求实际命中了目标代理组，而不是 DIRECT。
如果仍然失败，提交问题时只提供脱敏后的系统类型、客户端版本、配置字段片段、日志关键词和复现步骤。不要公开订阅链接、API 密钥、节点密码、完整节点地址或个人 IP。
常见问题
为什么 Mihomo 能看到节点，但节点测速全部失败？
节点显示只说明配置被读取，不代表代理握手成功。先手动选择单个节点，关闭 TUN 和系统代理，再检查节点域名解析、代理参数和日志中的 timeout、connection refused 或 no such host。
测速失败是不是说明节点一定失效？
不一定。URL-test 依赖测试地址、超时、预期状态和策略组成员；测速失败可能来自测试地址不可达、DNS 或网络丢包。应使用手动节点测试和实际业务页面复测。
出现 no such host 时应该改 nameserver 还是 proxy-server-nameserver？
先看日志中失败的域名。如果是节点服务器域名，优先检查 proxy-server-nameserver；如果是普通目标域名，再检查 nameserver、nameserver-policy 和系统 DNS。订阅地址解析失败则应先查当前网络和订阅地址本身。
关闭 TUN 后能用，打开 TUN 后不能用怎么办？
优先检查 TUN 权限、auto-route、auto-detect-interface、strict-route、dns-hijack、系统 VPN 权限和防火墙。Android 还要检查私人 DNS及应用是否被排除；Linux 还要检查路由和透明转发规则。
为什么切换到 global 后能用，rule 模式却不能用？
这通常说明节点本身可用，但规则或策略组没有把请求送到目标代理。检查规则顺序、DIRECT、GEOIP、RULE-SET、MATCH 和当前策略组选择，并确认应用没有单独配置直连。
连接失败时可以直接把配置全部换成网上的示例吗？
不建议。不同订阅、客户端和内核版本支持的字段可能不同。应先备份配置，只修改一个变量，并优先对照 Mihomo 官方配置文档核验字段。
常见问题
为什么 Mihomo 能看到节点，但节点测速全部失败？
节点显示只说明配置被读取，不代表代理握手成功。先手动选择单个节点，关闭 TUN 和系统代理，再检查节点域名解析、代理参数和日志中的 timeout、connection refused 或 no such host。
测速失败是不是说明节点一定失效？
不一定。URL-test 依赖测试地址、超时、预期状态和策略组成员；测速失败可能来自测试地址不可达、DNS 或网络丢包。应使用手动节点测试和实际业务页面复测。
出现 no such host 时应该改 nameserver 还是 proxy-server-nameserver？
先看失败的域名。如果是节点服务器域名，优先检查 proxy-server-nameserver；如果是普通目标域名，再检查 nameserver、nameserver-policy 和系统 DNS。
关闭 TUN 后能用，打开 TUN 后不能用怎么办？
优先检查 TUN 权限、auto-route、auto-detect-interface、strict-route、dns-hijack、系统 VPN 权限和防火墙。Android 还要检查私人 DNS及应用是否被排除。
为什么切换到 global 后能用，rule 模式却不能用？
这通常说明节点本身可用，但规则或策略组没有把请求送到目标代理。检查规则顺序、DIRECT、GEOIP、RULE-SET、MATCH 和当前策略组选择。
连接失败时可以直接把配置全部换成网上的示例吗？
不建议。不同订阅、客户端和内核版本支持的字段可能不同。应先备份配置，只修改一个变量，并优先对照 Mihomo 官方配置文档核验字段。