紫溪网络官网

Mihomo Party 连接失败怎么办？按现象逐步排查

更新于 2026-10-30 · zixi2019.shop

简答：Mihomo Party 连接失败时，先关闭 TUN 和系统级增强功能，只保留一个有效订阅、一个可用节点，并切换到全局模式测试。若普通代理能用，问题多半在规则、DNS、TUN 或系统代理；若节点本身也连不上，应先检查订阅有效性、配置解析和节点状态。

定义：Mihomo Party 连接失败，是指客户端能够启动但订阅无法更新、节点无法建立连接、系统代理不生效，或开启 TUN 后设备无法正常访问网络。

先试这一步：关闭 TUN，用全局模式做基线测试

本文面向已经安装 Mihomo Party、使用 Mihomo 配置或订阅，并遇到“客户端打开了但无法连接”的 Windows、macOS、Linux 用户。不同版本的菜单名称可能变化，本文不覆盖 iOS、Android，也不把单个网站打不开直接等同于客户端故障。Mihomo Party 的版本和名称应以其公开项目页面为准，旧版本发布说明中曾出现产品名称和安装方式变化，不能机械照抄其他教程的菜单路径。

最快排查顺序：先备份当前配置或订阅地址，然后关闭 TUN，确认系统代理使用客户端设置页显示的 HTTP 或 mixed 端口；将代理模式临时切到“全局”，手动选择一个节点，再打开一个普通网页测试。Mihomo 的全局模式需要选择代理组或策略组，规则模式则会按照规则从上到下匹配，二者不能混为一谈。Mihomo 通用配置文档说明了 rule、global、direct 三种运行模式。

现象优先判断先做什么
订阅更新失败链接、网络或返回内容异常重新复制完整订阅地址，用浏览器或其他网络检查是否能取得配置文本；不要公开订阅链接。
订阅能更新但节点全红配置解析、节点失效或认证信息异常查看配置是否成功加载，手动切换两个不同节点，不要只测试一个节点。
节点测试通过但浏览器打不开系统代理、规则模式或浏览器自身代理设置暂时使用全局模式，确认系统代理开关和端口与客户端当前配置一致。
关闭 TUN 后能用，开启 TUN 后断网TUN 权限、路由、DNS 劫持或防火墙先保持 TUN 关闭，确认基础代理可用后，再单独恢复 TUN 并逐项验证。
只有部分域名打不开DNS、Fake-IP、IPv6 或规则分流查看 DNS 日志和命中的规则，不要立刻修改多个 DNS 字段。

按最短路径检查订阅、配置和节点

  1. 备份当前配置。导出或复制当前配置文件，保存订阅名称和更新时间；订阅地址通常包含访问凭据，不要粘贴到公开群组、工单截图或日志中。
  2. 重新检查订阅地址。确认地址没有被截断、换行或混入空格。订阅本质上应返回 Mihomo 或 Clash Meta 可读取的配置内容，通常包括节点、代理组、规则和可能的 DNS 设置。订阅与配置概念说明对这些组成部分有明确解释。
  3. 区分“更新失败”和“配置加载失败”。如果更新按钮本身报错，优先检查网络、地址和服务端返回内容；如果更新完成但配置无法加载，重点看 YAML 格式、字段拼写、代理组引用和内核兼容性。
  4. 确认配置已被选为当前配置。只更新订阅但没有切换到当前配置，客户端可能仍在使用旧文件。切换后重新启动核心或重新载入配置。
  5. 手动选择两个节点测试。一个节点失败只能说明该节点或其路径存在问题，不能直接证明 Mihomo Party 故障。若多个节点都失败，再继续检查核心、系统代理和网络环境。

如果日志中出现 YAML 解析错误、字段类型错误或代理组找不到节点，先恢复到备份配置，不要继续叠加 DNS、TUN、规则覆写等设置。Mihomo 的规则按配置顺序匹配，末尾通常需要一个明确的 MATCH 处理未命中的请求；规则引用不存在的策略组，也可能造成流量没有按预期转发。Mihomo 路由规则文档说明了规则从上到下匹配的行为。

普通代理不通：检查系统代理、端口和其他网络软件

  1. 确认客户端核心正在运行。客户端界面打开不代表核心已经正常启动。查看日志中是否出现核心启动、配置加载或监听失败相关信息。
  2. 确认系统代理已开启。系统代理的地址和端口必须与 Mihomo Party 当前设置页显示的 HTTP 或 mixed 入站一致。不要直接照抄其他教程中的端口数字，因为不同配置可能使用不同端口。
  3. 排除端口占用。如果日志出现 address already in use、bind failed 或类似“地址已被占用”的提示，关闭其他代理客户端、VPN、开发调试工具后重启；也可以在系统中查找占用该端口的进程，再决定是否更换端口。
  4. 暂时关闭其他代理链路。只保留一个客户端接管系统代理。多个客户端同时开启系统代理、PAC 或透明代理，可能导致请求进入错误的端口。
  5. 单独测试浏览器。如果命令行或客户端内置测试可用，但某个浏览器打不开，检查浏览器扩展、自定义代理、企业策略和缓存；不要马上修改 Mihomo 的 DNS。

这一步的验证目标只是确认“请求能否进入 Mihomo 核心并通过选定节点发出”，并不能证明所有应用、UDP 流量或所有域名都正常。测试成功后再恢复规则模式，观察具体域名命中了哪个策略组。

关闭 TUN 后恢复，开启 TUN 后失败怎么办

TUN 会把系统或部分应用的流量导入虚拟网卡，涉及自动路由、DNS 配置、权限和防火墙。Mihomo 文档将 TUN 的 enable、auto-route、strict-route、dns-mode 等字段分别定义，普通排障时不建议一次修改全部字段。Mihomo TUN 配置文档还特别说明了不同协议栈、防火墙和平台行为的差异。

  1. 先关闭 TUN，重启客户端，确认普通系统代理能访问测试网页。
  2. 退出其他 VPN、虚拟网卡工具和网络加速软件，避免多个程序同时修改路由表。
  3. 以系统要求的权限启动客户端或核心，再单独开启 TUN；Windows 重点检查防火墙是否允许核心程序，macOS 关注网络扩展或系统授权，Linux 关注路由和防火墙规则。
  4. 开启后只测试一个网页和一个命令，不要同时改 DNS、MTU、协议栈和规则。
  5. 若开启 TUN 后完全断网，立即关闭 TUN并恢复系统代理；这表示当前 TUN 设置或权限仍未验证，不要继续使用该状态。

不要先改 MTU。Mihomo 文档将 MTU描述为影响特定情况下传输的参数，并建议一般用户保留默认值。连接失败时，优先处理权限、路由、DNS 和冲突软件，而不是把 MTU 当作万能修复项。TUN 参数说明可用于逐项核对字段。

节点能连但域名打不开：分层检查 DNS 和规则

  1. 先看是否只有域名失败。如果 IP 类请求或节点连通性正常，只有域名打不开，才把 DNS 作为主要方向；如果所有请求都失败，先回到节点和系统代理检查。
  2. 查看 DNS 是否启用。Mihomo 的 DNS 配置包含 enable、enhanced-mode、nameserver、nameserver-policy、proxy-server-nameserver 等字段，字段作用不同，不能把任意 DNS 地址直接替换进去。Mihomo DNS 配置文档提供了字段定义和解析流程。
  3. 一次只改一个变量。例如先关闭自定义 DNS 覆写并重新测试，再单独切换 fake-ip 或 redir-host；每次修改后记录结果，避免无法判断哪一项产生影响。
  4. 检查规则命中。规则模式下，域名可能被分到 DIRECT、代理组或 REJECT。查看请求日志或规则面板，确认实际命中的策略，而不是只看节点测速结果。
  5. 再检查 IPv6。如果只有部分网络或部分域名异常，比较 IPv4、IPv6 和关闭 IPv6 后的结果。不要仅凭一次浏览器失败就断定是 IPv6 问题。

Fake-IP、DNS 劫持和 TUN 通常是联动设置。若普通代理模式正常而 TUN 模式下域名异常，优先回滚 TUN 和 DNS 的临时改动，再逐项恢复，避免留下无法解释的组合配置。

日志关键词对应的处理动作

日志中出现的关键词或现象更可能的方向处理动作
connection refused、拒绝连接或连接被拒绝本地端口未监听、端口错误或目标端口被拒绝确认核心是否运行、系统代理端口是否一致，并关闭冲突软件后重试。
timeout、i/o timeout 或长时间无响应节点路径、网络环境或目标服务响应异常切换两个节点比较；若全部超时，再检查本地网络和订阅内容。
no such host、DNS resolve failed 或解析失败DNS、域名解析服务器或节点域名解析查看 DNS 设置和节点域名，先关闭复杂覆写，再测试基础配置。
YAML 解析错误、字段类型错误配置格式、缩进或字段与当前内核不兼容恢复备份，重新获取完整配置，不要把不完整模板直接合并到订阅。
permission denied、access denied 或 TUN 创建失败系统权限、防火墙或网络扩展未授权关闭 TUN 做基线测试，再按系统权限要求授权核心程序。
address already in use 或 bind failed本地监听端口被其他进程占用关闭冲突程序或更换端口，并同步更新系统代理设置。

这些词只是定位线索，实际日志文本会随客户端版本、核心版本和系统语言变化。不要把一次日志中的单词当成完整诊断结论，应结合出现时间、目标域名、节点名称和切换前后的结果判断。

最后的恢复顺序：从低风险到高影响

  1. 关闭 TUN，关闭系统代理，再重新启动 Mihomo Party。
  2. 确认订阅地址已备份，重新更新一次配置。
  3. 切换到刚更新的配置，选择一个节点并使用全局模式测试。
  4. 若仍失败，停用规则覆写、DNS 覆写和自定义脚本，保留最小配置测试。
  5. 若普通代理恢复，再单独恢复规则模式。
  6. 最后才恢复 TUN，并每次只启用一项相关设置。
  7. 仍无法恢复时，导出脱敏日志：删除订阅地址、密码、节点服务器敏感信息和控制器密钥，只保留错误时间、系统版本、客户端版本、核心版本和错误上下文。

重置前不要直接删除全部配置。先备份配置文件、订阅名称和必要的自定义规则；确认新配置可用后，再清理旧缓存。客户端版本、核心版本和菜单名称可能变化，下载或升级应以公开项目发布页面为准。Mihomo Party 公开发布页可用于核对可用版本和发布说明。

常见问题

Mihomo Party 显示已启动，但浏览器仍然无法上网，怎么办？

先确认系统代理开关已打开，地址和端口与客户端当前设置一致，再切换到全局模式并手动选择节点。如果客户端内置连接正常而浏览器失败，检查浏览器自定义代理、扩展和企业网络策略。

订阅更新成功，但节点列表为空或节点全部不可用，是什么问题？

这通常需要区分配置返回内容、解析结果和节点本身。先确认当前配置确实切换成功，再查看日志是否有 YAML 或字段错误，之后手动测试两个节点。若多个节点都失败，应重新核对订阅地址和配置提供方返回内容。

开启 TUN 后断网，是否应该马上修改 DNS 或 MTU？

不建议。先关闭 TUN，确认普通系统代理可用，再检查权限、防火墙、虚拟网卡和自动路由。MTU 不是通用修复项，DNS 也应在基础代理恢复后单独验证。

为什么全局模式能用，规则模式却打不开某些网站？

全局模式和规则模式的流量选择逻辑不同。规则模式会按顺序匹配域名、IP 或其他条件，某条规则可能把请求送到 DIRECT、错误的策略组或拒绝策略。查看实际命中的规则，并确认规则引用的策略组存在。

排查时可以把订阅链接和完整日志发给别人吗？

不建议。订阅链接、节点密码、控制器密钥和配置文件中的认证字段可能具有访问权限。分享前应删除这些内容，只保留系统、客户端、核心版本和脱敏后的错误片段。

常见问题

Mihomo Party 启动后没有网络，第一步做什么？

先关闭 TUN 和其他代理软件，确认系统代理地址、端口与客户端当前设置一致，再切换到全局模式并手动选择节点测试。

订阅更新失败和配置加载失败有什么区别？

更新失败主要检查订阅地址、网络和返回内容；配置加载失败则重点检查 YAML 格式、字段兼容性、代理组引用和核心日志。

为什么 TUN 关闭时正常，开启后却断网？

优先检查 TUN 权限、防火墙、自动路由、DNS 设置和虚拟网卡冲突。先恢复普通代理，不要同时修改 TUN、DNS、MTU 和协议栈。

节点测速通过就代表所有网站都能打开吗？

不代表。测速只能说明特定测试请求有响应，仍可能受到规则、DNS、应用代理设置、IPv6 或目标服务差异影响。

相关阅读

参考资料

  1. Mihomo Party GitHub 公开发布页
  2. Mihomo 通用配置：运行模式与日志级别
  3. Mihomo TUN 配置与平台注意事项
  4. Mihomo DNS 配置文档
  5. Mihomo 路由规则文档
  6. Mihomo 配置订阅与配置组成说明（app.meowx.net）