Mihomo 订阅更新失败怎么办？按错误类型逐步排查
简答：Mihomo 订阅更新失败，先不要急着换节点或重装客户端：重新复制完整订阅URL，在浏览器或另一台设备测试返回内容，再查看Mihomo日志中的状态码、DNS和解析错误。若订阅能打开但节点仍不变，重点检查Provider缓存、客户端实际加载的配置以及订阅内容是否确实发生变化。
定义：Mihomo 订阅更新失败，是客户端无法从Provider的订阅URL成功下载、解析或加载代理配置的情况。
先做这三步：最快判断故障在哪一层
本文是狮子云的第三方使用指南，不代表任何客户端或订阅服务的官方立场。先按“订阅链接—网络请求—配置解析—节点加载”的顺序排查，通常比直接重装更容易保留有效配置。
- 重新复制完整订阅URL：从提供订阅的后台重新复制，不要手动删改参数，也不要把单节点链接、Base64文本或其他客户端专用格式误当成Mihomo订阅。
- 单独测试URL：在浏览器或另一台设备中打开链接，观察是否能返回配置文本、是否跳转到登录页、验证码页或错误页面。浏览器能打开，只能说明当前设备拿到了HTTP响应，不等于Mihomo一定能解析。
- 查看客户端日志：记录错误中的状态码、域名、DNS错误、Timeout或YAML行号。成功判据是Provider更新时间改变、节点数量或节点名称与订阅内容一致，并且客户端不再重复报错。
Mihomo官方配置将远程订阅放在proxy-providers中，常见字段包括type: http、url、本地缓存path和自动更新间隔interval；字段名称应以Mihomo Proxy Providers 文档为准。
按现象和错误信息定位：不要把更新失败当成节点超时
| 现象或日志线索 | 优先判断 | 处理顺序 |
|---|---|---|
| 401、403 | 访问凭据、权限或订阅状态异常 | 重新登录相关后台并复制新URL；检查订阅是否到期或被撤销，以提供方页面当前显示为准。 |
| 404 | 路径不存在或链接已失效 | 不要继续刷新旧链接，重新获取完整订阅地址并检查是否被截断。 |
| 429 | 请求频率受到限制 | 停止连续点击更新，等待一段时间后再试，并避免多个客户端同时自动更新。 |
| 500、502、503、504 | 服务端或中间网关返回错误 | 切换网络后复测；若不同网络都出现同一结果，保留时间和状态码，等待提供方确认。 |
| Timeout、connection refused | 网络、DNS、端口或连接路径问题 | 切换Wi-Fi与手机热点，暂时关闭TUN、系统代理和其他VPN后重试。 |
| DNS resolve failed | 订阅域名或节点域名无法解析 | 先看日志中失败的是订阅域名还是节点域名，只调整对应的DNS层，不要一次修改整份配置。 |
| YAML解析错误或节点为空 | 返回内容不是有效配置，或格式与当前内核不兼容 | 检查返回内容是否为HTML、登录页或错误说明；恢复原始订阅和最小配置后再试。 |
HTTP状态码的标准含义可参考RFC 9110 HTTP Semantics。状态码只能帮助定位请求层，不能单独证明订阅一定失效。
节点不刷新、旧节点仍在：检查Provider和缓存
如果更新提示成功，但节点名称、数量或更新时间完全不变，先判断订阅内容是否真的发生变化。Mihomo官方文档说明，Provider可以保存到本地path，并按interval进行更新；因此客户端显示的旧节点可能来自本地Provider文件，也可能是提供方返回了相同内容。
- 打开客户端的Provider或订阅管理页面，确认当前更新的名称与配置中实际引用的Provider一致。
- 检查更新时间、节点数量和错误日志，不要只看主页面的节点列表。
- 关闭自定义覆写、规则覆写和TUN，使用原始订阅进行一次更新，减少解析层变量。
- 删除并重新添加前，先备份当前配置；确认新订阅能成功加载后，再清理旧Provider缓存。
- 重新导入后复测：Provider时间应更新，节点列表应与返回内容相符；若内容本身没有变化，节点不变并不一定是更新失败。
Mihomo API文档提供了查询Provider信息和手动触发Provider更新的接口说明，但本地控制器地址、端口和鉴权由当前配置决定，未确认前不要直接照抄他人的API地址或密钥设置，具体以Mihomo API文档为准。
网络和DNS排查：浏览器能打开但客户端仍失败
这种情况并不少见，因为浏览器与客户端可能使用不同的代理、DNS、User-Agent、TLS处理方式或重定向策略。先用最小变量方法排查：
- 关闭循环代理：暂时关闭TUN、系统代理和其他代理软件，再让Mihomo直接更新一次。
- 切换网络：从当前Wi-Fi切换到手机热点。如果热点成功、Wi-Fi失败，优先检查路由器DNS、防火墙或网络限制。
- 检查系统时间：设备时间明显错误时，HTTPS证书校验可能失败；先恢复自动同步时间再复测。
- 只改一个变量：先恢复默认DNS，再单独测试；不要同时更改DNS、MTU、TUN和规则，否则无法判断真正原因。
- 核对返回类型：浏览器显示登录页、验证码或JSON错误，并不代表这是可供Mihomo解析的代理配置。
如果切换网络、关闭TUN和恢复默认配置后仍然失败，记录发生时间、状态码、失败域名和脱敏日志，再向提供订阅的一方确认。不要公开完整订阅URL、Token、UUID、节点凭据或未脱敏日志。
回滚与复测：避免排查后彻底丢失原配置
处理订阅问题时建议保留一条可回滚路径：
- 修改前备份当前配置文件和Provider名称，至少保留原订阅配置的副本。
- 优先恢复原始订阅配置，暂时移除自定义覆写、复杂规则和TUN设置。
- 确认Provider能更新且节点列表恢复后，再一次只加回一个自定义项。
- 每次修改后都检查更新时间、节点数量、日志和实际连接结果。
若客户端的设置页或日志页名称与本文不同，请以当前客户端界面为准；本文不假定所有Mihomo图形客户端具有完全相同的菜单路径。Mihomo官方示例也将Provider订阅和健康检查分开配置，订阅更新成功不等于每个节点都能连接，节点延迟测试应单独判断。
常见问题
Mihomo订阅链接在浏览器能打开，为什么客户端还是更新失败？
浏览器能打开只代表收到了HTTP响应，返回内容可能是登录页、验证码、HTML错误页或不兼容格式。应查看Mihomo日志中的状态码和解析错误，并确认返回内容实际是可解析的订阅配置。
更新成功但节点数量和名称没有变化，是不是订阅失效？
不一定。可能是提供方返回了相同内容，也可能客户端仍显示本地Provider缓存。先比较更新时间、Provider名称和返回内容，再决定是否重建Provider。
Mihomo出现401或403时应该怎么处理？
先重新登录提供订阅的后台并复制完整URL，检查订阅权限或状态。401通常与身份凭据有关，403表示服务器拒绝当前请求，但最终原因仍需以提供方返回信息为准。
可以直接删除Provider缓存或重装客户端吗？
不建议把它作为第一步。先备份配置，关闭覆写和TUN，恢复最小配置后测试；只有确认缓存或配置损坏时，才在保留回滚文件的前提下重建Provider。
排查时哪些信息不能发到群里或工单里？
不要公开完整订阅URL、Token、UUID、节点密码、私钥和未脱敏日志。提交问题时只保留错误类型、状态码、时间、客户端名称和脱敏后的域名。