Mihomo连接失败怎么办？从端口、DNS到TUN逐步排查
简答：先关闭 TUN，用 HTTP 或 SOCKS 本地端口测试；若端口可用，再按节点、DNS、订阅和系统代理分层排查。只有 TUN 失败时，重点检查 auto-route、dns-hijack、strict-route 与权限。
定义：Mihomo连接失败，是指内核未正常启动、代理端口不可用、节点握手失败，或流量经过DNS、系统代理、TUN路由时被中断。
先做五分钟分流：不要一开始就改 DNS
本文与 Mihomo 项目及其开发者无隶属关系。Mihomo连接失败时，先判断故障发生在哪一层：内核是否启动、配置是否加载、本地代理端口是否监听、单个节点还是全部节点失败，以及关闭 TUN 后普通代理是否可用。项目文档说明，Mihomo既可以通过固定代理端口接收流量，也可以通过 TUN 捕获系统流量；两条路径应分开验证。Mihomo入站配置文档
| 现象 | 先检查 | 判定标准 | 下一步 |
|---|---|---|---|
| 客户端界面打不开或没有配置 | 配置文件、内核状态、日志 | 能看到当前配置且内核持续运行 | 先修复配置加载，不要测试节点 |
| 所有节点都失败 | 订阅内容、节点域名DNS、本地端口 | 至少一个节点能完成连接测试 | 检查订阅是否返回HTML、403、404或空内容 |
| 只有一个节点失败 | 该节点域名、端口、协议参数 | 其他节点能连接同一测试网址 | 保留日志，暂不改全局DNS |
| 关闭TUN后可用，开启TUN后断网 | auto-route、dns-hijack、strict-route、权限 | 普通代理端口可用，TUN路径失败 | 按TUN章节逐项恢复 |
| 只有某个应用失败 | 应用是否使用系统代理、规则和DNS | 浏览器或命令行可用但目标应用不可用 | 检查应用代理设置或改用TUN对照 |
建议固定一个测试网址、固定一个节点、每次只改一个变量。本文没有提供虚构的测速或延迟数据；如需记录，可填写：测试时间、设备、Mihomo版本、节点名称、首连耗时、是否成功、CPU、内存、退出后系统代理是否恢复。不同客户端界面可能不同，但内核日志和配置字段应以实际版本文档为准。
第一步：确认内核、配置和本地代理端口
- 确认配置不是空的。检查客户端当前是否已激活目标配置，代理组是否有节点，节点提供者是否已经完成更新。若订阅地址打开后返回登录页、HTML错误页、403、404或空响应，先修复订阅来源；不要把订阅解析失败误判为节点故障。
- 关闭TUN做最小化测试。暂时关闭TUN、系统增强接管或透明代理，只保留HTTP、SOCKS或mixed端口。固定端口仅为示例，请替换为客户端实际监听端口。
- 测试本地端口是否监听。Windows PowerShell可执行：
Test-NetConnection 127.0.0.1 -Port 7890；macOS或Linux可执行：nc -vz 127.0.0.1 7890。把7890替换为实际端口。看到TcpTestSucceeded为True，或nc显示succeeded，说明端口层面可连接；失败则先检查端口配置、内核进程和端口占用。 - 测试代理请求。需要系统已安装curl；命令中的7890和https://example.com必须替换为实际本地端口和目标域名：
curl -v -x http://127.0.0.1:7890 https://example.com/。若能建立代理连接并收到HTTP响应，说明普通代理链路基本可用；若提示Connection refused，优先看端口；若提示Could not resolve host，转到DNS分支；若出现超时，转到节点或路由分支。
如果客户端只提供SOCKS端口，可将命令改为curl -v --socks5-hostname 127.0.0.1:替换为SOCKS端口 https://替换为目标域名/。这里使用--socks5-hostname是为了让域名解析交给代理链路；curl版本过旧或不支持该参数时，先执行curl --version确认安装版本，或在客户端内直接使用连接测试功能。
第二步：区分单节点失败、全部节点失败和DNS失败
不要一看到超时就批量更换节点。先用同一个目标网址测试两个节点，并记录结果。若仅一个节点失败，重点查看节点域名、端口、TLS或协议参数；若所有节点都失败，重点检查订阅、代理端口、节点域名解析和本地网络。
| 日志关键词 | 通常表示的层级 | 可执行检查 | 正常判定 |
|---|---|---|---|
connection refused | 目标端口主动拒绝或本地服务未监听 | 确认本地端口、节点端口与防火墙 | 端口测试不再被拒绝 |
i/o timeout | 连接或读写在超时期限内没有完成 | 固定节点测试，比较直连DNS、节点域名和网络出口 | 同一节点可完成握手并返回响应 |
context deadline exceeded | 操作超过截止时间 | 先排除端口、DNS和TUN，再看节点协议 | 日志不再持续出现该错误 |
network is unreachable | 系统没有可用到目标地址的路由 | 检查IPv6、TUN路由、auto-route和系统网卡 | 目标地址存在可用路由 |
no such host或DNS resolve failed | 域名解析失败，可能是目标域名或节点域名 | 分别测试节点域名和目标域名，不要混为一谈 | 两类域名都能获得有效解析结果 |
官方DNS文档区分了default-nameserver、nameserver和proxy-server-nameserver：前者用于解析DNS服务器域名，后者用于普通域名解析，代理节点域名则可单独使用proxy-server-nameserver。Mihomo DNS配置文档
可先采用最小配置思路，不要一次加入大量策略。示例字段如下，DNS地址仅作格式示例，需替换为你实际可访问的DNS服务：
dns:
enable: true
default-nameserver:
- 替换为可用的DNS服务器IP
nameserver:
- 替换为普通域名解析服务器
proxy-server-nameserver:
- 替换为可解析节点域名的DNS服务器若只有节点域名无法解析，优先检查proxy-server-nameserver；若节点域名能解析但目标网站失败，再检查nameserver、规则和代理链路。不要公开订阅链接、UUID、密钥、完整配置或包含节点域名的原始日志。
第三步：TUN开启后断网，按字段和权限逐项检查
官方TUN文档说明，auto-route用于自动设置全局路由，auto-detect-interface用于自动识别出口网卡，dns-hijack用于把匹配的DNS请求导入内部DNS模块；Windows上strict-route还涉及防止普通多网卡DNS解析造成的泄漏。Mihomo TUN配置文档
- 先确认普通代理可用。如果关闭TUN后HTTP或SOCKS测试已经失败，先回到端口、节点和DNS分支，暂时不要继续改TUN。
- 确认TUN权限。Windows首次启用TUN可能需要管理员授权；macOS、Linux也可能受防火墙或系统权限影响。官方文档明确列出了Windows防火墙放行核心程序、macOS允许应用以及Linux放行TUN接口出站流量的处理方向。TUN权限与防火墙说明
- 检查核心字段。可从以下最小片段开始，字段是否可用仍取决于客户端和内核版本：
如果开启后立即断网，先关闭tun: enable: true auto-route: true auto-detect-interface: true strict-route: true dns-hijack: - any:53strict-route或dns-hijack做单变量对照；如果恢复，说明问题集中在路由或DNS接管，不代表节点一定失效。 - 检查多网卡和冲突软件。电脑同时连接有线、无线、虚拟机、容器或其他VPN时，自动识别出口可能选错。官方文档建议多出口设备手动指定出口网卡。先关闭其他VPN、虚拟网卡或代理软件，再重复同一测试。
- 检查IPv6分支。出现
network is unreachable且日志涉及IPv6地址时，可临时关闭IPv6或仅测试IPv4。若IPv4正常、IPv6失败，说明应继续检查IPv6路由，而不是反复更换节点。
Android上的TUN还会受到系统VPN和Private DNS影响；官方文档指出，Private DNS开启时DNS请求可能无法被自动劫持。可暂时关闭Private DNS做对照，测试结束后再按隐私和网络需求恢复设置。Android与DNS劫持说明
第四步：用日志和API确认到底是哪一层失败
将日志级别临时调到debug，只复现一次失败请求，随后恢复较低日志级别。官方API文档显示，启用外部控制器并配置密钥后，可以通过/logs以GET或WebSocket方式获取实时日志，日志级别可使用info、warning、error和debug。Mihomo API与日志文档
示例命令需要先启用外部控制器，并把127.0.0.1:9090和替换为你的密钥改成实际值：
curl -H "Authorization: Bearer 替换为你的密钥" "http://127.0.0.1:9090/logs?level=debug&format=structured"如果返回未授权，检查密钥和控制器地址；如果连接被拒绝，检查控制器是否监听；如果日志有DNS解析记录但随后出现节点超时，优先排查节点链路；如果连DNS记录都没有，先看配置是否加载或请求是否进入Mihomo。外部控制器不应暴露到公网，完成排查后关闭或限制监听地址。
建议把每次测试记录成一行：时间｜设备｜内核版本｜是否TUN｜模式｜节点｜目标域名｜首连耗时｜结果｜关键日志。这样能判断是配置改动带来的变化，还是网络本身的偶发波动。本文不提供未经复现的延迟、丢包、CPU或内存代表值。
Windows、macOS、Android、Linux的最小操作路径
- Windows：先关闭TUN，确认系统代理地址和端口与Mihomo监听端口一致；用PowerShell执行端口测试。若TUN失败，检查管理员授权和Windows防火墙是否允许核心程序。
- macOS：先用HTTP或SOCKS端口测试，再检查系统代理开关、其他VPN和防火墙。TUN设备名称应遵循项目文档要求；多网卡时不要只依赖自动识别。
- Android：检查系统VPN是否被其他应用占用，暂时关闭Private DNS做对照；先验证单个应用或浏览器，再判断是否为全局TUN故障。
- Linux：先检查端口监听、默认路由和防火墙；启用TUN后确认网卡和路由表是否变化。使用
ip route、ip addr等系统工具时，先确认系统已安装iproute2，并只记录与本次测试相关的输出。
四个平台的共同原则是：先确认直连网络正常，再确认内核和端口，接着测试单节点，最后才恢复TUN、DNS劫持和规则分流。不要把多个代理、VPN、虚拟网卡同时打开，否则日志很难对应到唯一故障层级。
常见问题
Mihomo所有节点都连接失败，应该先换节点吗？
不建议先批量换节点。先确认配置不是空的、订阅没有返回HTML或错误页、本地代理端口正在监听，再用同一个网址测试两个节点。若所有节点都失败，优先检查订阅、节点域名DNS和本地端口。
Mihomo关闭TUN后能用，开启TUN后断网怎么办？
先保持TUN关闭，确认HTTP或SOCKS端口测试成功，再逐项检查auto-route、auto-detect-interface、strict-route、dns-hijack、系统权限和防火墙。每次只改一个字段，观察是否恢复。
日志里的i/o timeout和network is unreachable有什么区别？
i/o timeout表示连接或读写在期限内没有完成，常见于节点链路或目标端响应异常；network is unreachable表示系统没有可用路由，优先检查IPv6、TUN路由、出口网卡和防火墙。两者都不能直接证明节点已经失效。
Mihomo提示no such host，应该改nameserver还是proxy-server-nameserver？
先判断报错域名是代理节点域名还是目标网站域名。节点域名优先检查proxy-server-nameserver，普通目标域名再检查nameserver和规则；不要在未分层前同时修改所有DNS字段。