Mihomo订阅解析失败怎么办？按链接、YAML与Provider排查
简答：Mihomo订阅解析失败，先不要删除旧配置：先确认订阅链接返回的不是登录页、验证码或JSON错误，再检查YAML格式、订阅类型、Provider和当前Profile。若只是节点为空或连接失败，通常已经越过了解析层，应转查Provider、代理组、DNS或系统代理。
定义：Mihomo订阅解析失败，是指客户端无法把订阅地址返回的内容识别为可用的YAML配置、URI列表、Base64节点内容或Proxy Provider内容。
先看报错：按现象决定从哪一层开始
本文只处理Mihomo订阅下载、解析和载入问题，不等同于单个节点连接失败。Mihomo配置文件使用YAML，YAML区分大小写，并使用空格表示层级；缩进不能使用Tab。官方语法说明还指出，冒号后需要空格，格式错误通常会在日志中给出行号或字段附近的提示。
| 看到的现象 | 优先检查 | 判断标准 | 下一步 |
|---|---|---|---|
| 401、403、404、429或超时 | 订阅链接和网络请求 | 响应状态不是成功，或请求未完成 | 重新复制链接，检查权限、有效期和网络 |
| 返回HTML、登录页、验证码或JSON错误 | 响应正文 | 前几行不是YAML、URI或Base64内容 | 回到提供方页面重新复制可用订阅地址 |
| parse error、mapping、indentation、unexpected character | YAML语法 | 日志指向某一行或某个字段 | 检查Tab、缩进、冒号、引号和特殊字符 |
| Provider error、更新超时、节点数量为0 | Proxy Provider | 配置能打开，但Provider没有有效节点 | 检查Provider类型、URL、过滤器和更新结果 |
| 导入成功但仍显示旧节点 | Profile和缓存 | 新内容未成为当前活动配置 | 重新载入并确认当前Profile已启用 |
| 节点可见但无法连接 | 连接、DNS、TUN或系统代理 | 解析层已通过，失败发生在实际出站链路 | 转到连接问题排查，不要继续改YAML |
最快处理顺序：保留旧Profile → 检查订阅响应 → 检查格式 → 更新Provider → 载入新Profile → 最后再查节点连接。
第一步：确认订阅链接返回的是什么
订阅链接本质上是一次HTTP请求。复制链接时不要截断参数，也不要把浏览器地址栏中的登录页面地址当成订阅地址。订阅令牌、UUID和完整链接属于敏感信息，排查时不要公开粘贴。
Windows PowerShell
在PowerShell中使用以下命令，仅查看响应头和前几行正文。把命令中的链接替换成你自己的订阅地址，不要把执行结果中的完整令牌发到公开平台。
curl.exe -I -L "你的订阅地址"
重点看HTTP状态、是否发生重定向以及Content-Type。随后可以只读取前几行：
curl.exe -L --max-time 20 "你的订阅地址" | Select-Object -First 8
如果输出是HTML、登录提示、验证码或结构化错误信息，而不是配置内容，问题在下载响应或订阅权限层，不是YAML缩进。PowerShell命令需要在本机网络可访问订阅地址的前提下运行，超时只能说明这次请求没有完成，不能单独证明订阅已经失效。
macOS、Linux或OpenWrt终端
curl -I -L --max-time 20 "你的订阅地址"
curl -L --max-time 20 "你的订阅地址" | head -n 8
如果服务器要求特定请求头、登录状态或客户端类型，需以订阅提供方的当前说明为准。不要为了“能打开”而把完整订阅内容粘贴到陌生在线解析站。
第二步：判断内容类型是否与Mihomo匹配
Mihomo的Proxy Provider内容并不只有一种形式。官方文档列出，Provider可以是HTTP、file或inline；内容可使用带proxies:字段的YAML，也可以是直接排列的URI或Base64内容，但YAML、URI和Base64不能混写在同一个Provider文件中。Proxy Provider配置文档与Provider内容说明对此有明确区分。
| 返回内容特征 | 可能类型 | 常见误用 |
|---|---|---|
以proxies:开头，下面是name、type、server等字段 | YAML节点集合 | 缩进或字段层级被改坏 |
多行以ss://、vmess://等URI开头 | URI列表 | 当作完整Mihomo配置导入 |
| 长串字母、数字和符号，可能是一行或多行 | Base64节点内容 | 复制时被换行、截断或混入HTML |
包含mixed-port、proxy-groups、rules等顶层字段 | 完整配置 | 误放进只接受Provider内容的位置 |
以{开头并包含JSON字段 | 其他客户端配置或接口响应 | 直接当作Mihomo YAML订阅使用 |
不要仅凭文件后缀判断格式。可识别的关键是响应正文的结构，以及当前客户端添加入口要求的是完整Profile、Proxy Provider还是节点链接。
第三步：处理YAML解析报错
如果日志包含parse error、mapping values are not allowed、cannot unmarshal、indentation或unexpected character，先按日志行号定位，不要一次性重写整个订阅。优先检查以下项目：
- Tab缩进：YAML层级只能使用空格，Tab会导致解析失败。
- 冒号后空格：使用
name: value，不要写成容易产生歧义的形式。 - 同级对齐：列表项前的短横线和同级字段应保持一致缩进。
- 特殊字符：节点名称、密码、正则和包含冒号的字符串必要时使用引号。
- 复制污染：检查正文前后是否混入HTML、提示文字、不可见字符或截断内容。
- 字段归属：
proxy-groups中的引用名称应与节点或Provider提供的名称对应。
不要把完整订阅直接交给在线格式化或解析网站。若内容来自自己维护的本地配置，可在本机编辑器中显示空白字符，再保存一份副本进行校验；若是远程订阅，优先让订阅提供方修复源内容。
第四步：用mihomo命令行验证本地配置
如果你能获得本地配置文件，可以使用Mihomo命令行测试配置。官方项目相关工具文档展示了mihomo -t用于验证最小配置；实际参数和文件路径仍应以当前二进制的帮助信息为准。官方工具说明提供了该校验方式的示例。
先查看当前二进制支持的参数：
mihomo -h
再对本地配置文件执行测试：
mihomo -t -f ./config.yaml
在Windows中可写成：
.\mihomo.exe -t -f .\config.yaml
预期结果应是配置通过校验或没有配置错误；如果命令提示未知参数，应以mihomo -h显示的当前语法为准。此检查只能验证本地文件能否被内核读取，不能证明远程订阅仍有效、Provider能成功更新或某个节点一定可用。
回滚方法：不要覆盖唯一的旧配置。先复制一份旧Profile，再把新订阅保存为单独文件或新Profile；确认新配置能加载后，再决定是否替换旧配置。
第五步：Provider报错、节点为空或策略组找不到
配置文件能打开但节点数量为0，通常已经不再是基础YAML问题。官方Provider配置说明中，HTTP类型需要URL，Provider名称需要唯一，路径也需要满足当前运行目录和安全路径限制。官方字段说明可用于逐项核对。
- 检查Provider类型是否写成当前支持的
http、file或inline。 - 检查URL是否完整，尤其是问号后的参数、大小写和末尾字符。
- 检查Provider路径是否与其他Provider重复，或是否超出当前运行目录允许范围。
- 检查过滤器是否把所有节点排除。过滤关键词过宽时，Provider可能更新成功但显示为0个节点。
- 检查策略组的
use是否引用了实际存在的Provider名称。 - 检查策略组的
proxies是否引用了实际存在的节点或策略组名称。
官方代理组文档说明，proxies用于引用代理或其他代理组，use用于引用代理集合；因此“节点已下载但策略组为空”与“订阅没有节点”是两个不同问题。代理组字段说明可帮助核对引用关系。
不同系统的最小操作路径
| 系统或客户端形态 | 建议入口 | 成功判据 | 失败时回滚 |
|---|---|---|---|
| Windows桌面客户端 | 打开Profiles或配置列表，查看当前Profile的更新日志，再新建Profile测试 | 新Profile能加载，节点数量不再为0，日志不再出现解析错误 | 切回原Profile，不删除旧配置 |
| macOS桌面客户端 | 在配置列表中区分远程订阅、当前配置和Provider，分别执行更新 | 远程配置更新完成，当前启用项已切换到新配置 | 恢复原配置并关闭新配置的自动更新 |
| Android客户端 | 先查看订阅或配置更新日志，再检查当前激活配置；不要只看系统VPN图标 | 配置页面出现节点或Provider内容，随后再测试代理请求 | 停用新配置，保留旧配置 |
| OpenWrt上的Mihomo | 检查服务日志、配置文件路径、Provider文件路径和权限 | 服务重新载入无配置错误，Provider文件有内容且策略组能引用 | 恢复旧配置文件并重启服务 |
不同图形界面的菜单名称可能随客户端版本变化，找不到完全相同的按钮时，应优先寻找“配置/Profile、订阅更新、Provider、日志、重新载入”这些功能，而不是盲目修改TUN或DNS。
解析失败与连接失败不要混在一起
订阅解析失败：配置文件无法读取，常见关键词是parse、YAML、mapping、indentation或unexpected character。
节点为空：配置可能已打开，但Provider返回内容为空、被过滤器全部排除，或策略组没有正确引用Provider。
节点连接失败：节点已经显示，失败发生在代理协议、DNS、路由、TUN、系统代理或远端线路。此时继续改订阅格式通常没有帮助。
浏览器打不开但客户端显示已连接：“已连接”只证明客户端局部状态，不能证明目标应用的流量已经按预期经过代理。应结合日志、目标请求和系统代理状态复核。
安全提交日志与最小复现清单
向维护者或技术支持反馈时，只提交能定位问题的最少信息：
- 客户端名称、系统和内核版本；版本号如果无法从客户端或发布页核实，应直接写“未核实”。
- 脱敏后的报错关键词和行号，不要粘贴完整订阅内容。
- HTTP状态、是否重定向、Content-Type和响应前几行的类型判断。
- 问题属于首次导入、后续更新、节点为空还是节点连接失败。
- 是否保留旧Profile，以及新建Profile后是否复现。
订阅链接通常包含令牌或用户标识。不要公开完整URL、UUID、密码、私钥或完整Provider文件；如果怀疑链接泄露，应按提供方当前流程重置或重新生成。
常见问题
Mihomo订阅解析失败，最先应该重新复制链接吗？
可以，但不要只重复复制。先用浏览器或curl检查HTTP状态和响应前几行，确认链接没有被截断，返回的不是登录页、验证码、HTML或JSON错误；确认响应内容后再判断是否需要重新生成订阅。
Mihomo提示YAML解析错误，能直接把订阅粘贴到在线修复工具吗？
不建议。订阅链接和配置可能包含令牌、UUID、密码或节点信息。优先在本地编辑器中检查Tab、缩进、冒号、引号和复制污染；远程订阅源有问题时，应让提供方修复或重新生成。
为什么Mihomo配置能打开，但节点数量是0？
常见原因包括Provider更新失败、返回内容为空、过滤器排除了全部节点、Provider名称引用错误，或把URI/Base64内容放入了不匹配的配置位置。应查看Provider更新日志，并核对type、url、use和filter。
Mihomo订阅导入后还是旧节点，说明解析失败吗？
不一定。可能是新Profile没有被激活、客户端仍使用旧缓存，或更新操作只更新了Provider而没有重新载入当前配置。保留旧Profile，确认更新时间、当前启用项和Provider状态后再判断。
节点已经显示但连不上，还需要继续检查订阅格式吗？
通常不需要。节点显示说明下载和基础解析大概率已经通过，应转查代理协议、DNS、系统代理、TUN、路由以及单节点连接日志。