Mihomo订阅更新失败怎么解决？按报错、Provider和网络逐项排查
简答：Mihomo订阅更新失败，先不要删除旧配置：复制一条新的订阅链接，用浏览器或命令检查HTTP状态码和返回内容，再查看Mihomo日志中的Provider错误。401/403优先检查授权与链接，404检查地址，429检查请求频率，Timeout或DNS错误则切换网络并排查解析；如果更新成功但节点不变，还要核对缓存、过滤和服务端内容是否真的变化。
定义：Mihomo订阅更新失败，是客户端拉取远程订阅或Proxy Provider时没有得到可加载的节点配置，和节点已经导入但连接失败不是同一个问题。
先看这张速查表：不要把订阅更新失败当成节点连接失败
本文是第三方使用指南，不代表任何客户端或订阅服务的官方页面。最快的做法是先保留当前能用的配置，然后在客户端的“配置文件”“订阅”“Provider”或“代理集合”页面手动刷新一次，同时打开日志记录完整报错。Mihomo官方配置将远程节点集合定义为proxy-providers，其中可以设置订阅URL、本地保存路径、更新间隔、请求头、代理路径和健康检查；不同图形客户端的菜单名称可能不同，以当前版本界面为准。Mihomo Proxy Providers 配置文档
| 现象 | 先检查 | 判断与处理 | 回滚方式 |
|---|---|---|---|
| 401 Unauthorized | 订阅是否过期、Token是否完整、是否复制了旧链接 | 重新从服务后台复制完整链接；不要手工删参数 | 保留旧配置，确认新链接成功后再替换 |
| 403 Forbidden | 请求来源、访问权限、客户端请求头 | 用原客户端刷新并查看响应头；必要时按服务商要求重新生成链接 | 恢复旧Provider或旧配置文件 |
| 404 Not Found | 域名、路径、字符、重定向后的地址 | 链接可能已撤销或路径错误，重新复制并检查是否混入空格 | 不要删除旧订阅，先测试新链接 |
| 429 Too Many Requests | 短时间重复刷新、多个设备同时拉取 | 暂停连续刷新，等待服务端限制解除，并减少并发更新 | 继续使用旧节点，避免反复点击更新 |
| Timeout、DNS错误、TLS错误 | 订阅域名解析、系统时间、网络和代理路径 | 切换网络后复测；区分订阅域名无法访问与节点连接失败 | 恢复原DNS、TUN和系统代理设置 |
| 更新成功但节点不变 | Provider缓存、过滤、覆写和服务端返回内容 | 查看节点数量、更新时间或返回文件内容，确认服务端是否真的更新 | 恢复原Provider文件和配置备份 |
| 节点为空或全部超时 | 更新结果、YAML格式、健康检查和节点本身 | 先确认Provider是否有节点，再单独测试节点延迟 | 加载更新前的配置文件 |
HTTP状态码的含义应以响应本身为准：RFC 9110将401、403、404分别定义为未通过认证、拒绝访问和找不到资源；5xx表示服务器端发生错误或无法完成请求。RFC 9110 HTTP Semantics
第一步：备份旧配置，再确认到底是哪一层失败
先在客户端找到“配置文件”“Profiles”“配置管理”或类似页面，执行“打开配置目录”“导出配置”或复制当前配置文件。菜单名称会因客户端不同而变化，找不到时以当前版本界面为准。至少保留三项：当前主配置文件、Provider本地文件、订阅名称和更新时间截图。
- 订阅拉取失败：日志出现HTTP状态码、Timeout、DNS、TLS或Provider update failed，说明远程请求或解析阶段没有完成。
- 更新成功但节点为空：日志显示更新成功，但代理集合没有节点，重点检查返回内容是否为有效YAML、Base64文本或错误页面，以及过滤、覆写和格式转换。
- 节点全部超时：Provider已经有节点，但健康检查或连接测试失败，重点检查节点协议、DNS、系统时间、网络和线路，不要继续反复更新订阅。
- 只有某个软件不能用：先区分系统代理、TUN和应用独立代理。订阅更新请求可能走系统网络，也可能通过Provider配置里的
proxy字段走指定代理；Mihomo文档明确支持为Provider设置代理路径。Provider的proxy与请求配置
如果客户端刚从睡眠或休眠中恢复，手动刷新一次再观察日志。Mihomo项目的公开Issue记录过Provider定时更新在系统休眠期间延迟、唤醒后不会立即补刷的复现情况，因此“睡眠后节点仍是旧的”不能直接判断为订阅失效。Mihomo Issue：休眠后Provider未按预期更新
第二步：重新核验订阅链接和返回内容
订阅链接属于敏感凭据，不要把完整URL、Token、UUID、节点密码或带参数的截图发到论坛。重新复制时从服务后台的订阅管理页面选择适用于Clash/Mihomo的格式；如果后台提供多个格式，不要把其他客户端格式直接当作Mihomo YAML。
- 在客户端的“订阅管理”“配置订阅”或“Provider”页面删除输入框中旧地址后，重新粘贴完整链接。
- 检查开头是否包含
http://或https://，末尾参数是否完整，前后是否混入空格、换行或中文标点。 - 不要先删除本地旧Provider；先新增一个临时订阅或复制一份配置进行测试。
- 在浏览器中访问链接只能作为连通性检查，不能证明客户端一定能解析。重点看最终状态码、是否发生重定向、返回内容是否是登录页、WAF错误页或HTML页面。
Windows可以使用PowerShell查看响应头，但请把真实地址替换为仅在本机使用的占位符，并避免把输出中的认证信息分享出去：
curl.exe -I -L --max-redirs 5 "https://example.invalid/subscription"
如果需要确认正文格式，可以在浏览器中下载到本地后用文本编辑器查看，不要直接粘贴到公开平台。有效内容可能是YAML，也可能是经过编码的文本；仅凭“浏览器能打开”无法判断它是否符合当前客户端的导入要求。
第三步：按HTTP状态码、DNS、TLS和代理路径处理
401、403、404：先修复授权和地址
401通常表示服务端要求有效认证；403表示服务端理解请求但拒绝完成；404表示当前资源不存在或服务端不愿披露其存在。处理顺序是：重新复制链接、检查套餐状态和访问权限、确认没有把后台登录地址当成订阅地址，再用另一条网络复测。不要通过修改随机请求头来绕过访问限制；如果服务商要求特定User-Agent，应以其公开说明为准。
429、5xx：减少重复请求，确认是否为服务端响应
429表示请求受到频率或资源限制的可能性较高，短时间连续点击“更新”会让判断更困难。暂停重复刷新，记录状态码和时间，再用单台设备复测。5xx属于服务器错误类响应，客户端侧可以切换网络确认，但不能仅凭5xx断言订阅永久失效。
Timeout、DNS和TLS：分别验证域名、时间与连接路径
如果日志写的是no such host或dns resolve failed，先确认失败对象是订阅域名、节点域名还是目标网站。Windows可在命令提示符运行nslookup 订阅域名；macOS可运行dig 订阅域名。如果系统时间明显不正确，先同步时间后再测试TLS；TLS证书校验失败与协议鉴权失败不是同一个问题，不要直接把“跳过证书验证”作为默认修复。
如果开启了TUN或系统代理，订阅请求可能经过不同的网络路径。排查时只改一个变量：先关闭TUN并保留客户端运行，再刷新订阅；如果仍失败，再关闭系统代理或退出其他代理软件；最后切换Wi-Fi与手机热点对比。每次改动后都记录结果，成功后恢复原设置并验证其他应用是否正常。
第四步：检查Provider、过滤、覆写和节点数量
如果日志显示订阅更新成功，但客户端仍显示旧节点或节点为空，打开客户端的“Provider”“代理集合”“节点提供者”或类似页面，查看以下项目：
- Provider状态：是否显示最近更新时间、节点数量和错误信息。Mihomo API可以通过
GET /providers/proxies查看所有代理集合，也可以通过GET /providers/proxies/Provider名称查看指定集合；更新指定代理集合使用PUT /providers/proxies/Provider名称，实际是否开放API取决于客户端配置。Mihomo API文档 - 本地路径：Provider配置中的
path是本地保存位置。路径不可写、文件夹不存在或客户端权限不足，都可能导致更新后无法保存；不要凭经验修改路径，先在配置目录确认文件是否出现。 - 过滤和覆写：检查名称过滤、正则过滤、节点类型过滤、覆写脚本和代理组引用。暂时关闭一个过滤项后再刷新，避免同时修改多个选项。
- 返回内容：查看本地Provider文件的更新时间和
proxies字段。没有proxies或内容是HTML错误页时，问题在格式或服务端返回，不是测速问题。 - 服务端内容是否变化：用第二台设备或另一种网络只做一次请求，对比更新时间、文件大小或节点数量。若两台设备拿到的内容完全相同，可能是服务端尚未更新、缓存仍有效或订阅本身没有变化。
如果更新成功但节点列表仍旧，Mihomo项目已有公开Issue讨论“内容相同导致订阅信息不变化”的情况；因此应先核对返回内容和本地文件，不要立即删除配置或反复重装客户端。Mihomo Issue：Provider内容相同与更新显示
第五步：查看日志、测试节点，并按结果回滚
在客户端找到“日志”“Logs”“运行日志”或“控制面板日志”，将日志级别临时调整为debug后只执行一次更新。Mihomo文档说明，debug会输出运行期间更多信息；排查完成后应恢复为info或客户端原来的级别，避免长期保留过多日志。Mihomo通用配置与日志级别
- 记录请求阶段：看是否出现Provider名称、请求开始、状态码、解析错误、保存路径和更新时间。
- 记录解析阶段：如果HTTP请求成功但出现YAML parse error、字段错误或节点数量为零，回到返回格式、过滤和覆写检查。
- 记录连接阶段：如果Provider有节点但健康检查失败，使用客户端内置的单节点延迟测试；Mihomo API也支持对指定Provider节点进行健康检查，但API名称和权限需以当前客户端为准。
- 执行回滚：关闭客户端或停止核心后，把备份的主配置和Provider文件恢复到原位置，再启动客户端确认旧配置可用。不要把“更新失败”与“旧配置损坏”混为一谈。
- 决定是否联系服务商：当新链接持续返回401/403/404、跨不同网络都无法访问，或服务端返回5xx且其他设备结果一致时，整理时间、状态码、脱敏日志和客户端版本，向服务商核验订阅权限。不要提交完整订阅URL。
如果只是某个节点全部超时，而Provider能正常更新，优先进行节点和线路排查；如果所有节点同时消失或Provider无法解析，才继续处理订阅、格式和配置问题。
不同设备的操作重点
| 平台 | 先找的页面 | 重点检查 |
|---|---|---|
| Windows | 配置文件、订阅管理、Provider、日志 | 系统代理、TUN权限、Windows DNS、休眠后是否需要手动刷新 |
| macOS | Profiles、Providers、Logs或运行面板 | 系统代理开关、网络服务顺序、系统时间和DNS缓存 |
| Android | 配置、代理集合、日志 | 后台限制、网络切换、TUN权限、电池优化和休眠后刷新 |
| iOS | 配置列表、订阅更新、活动日志 | 系统网络切换、VPN权限、订阅格式和应用后台限制 |
这些是通用定位名称，不代表每个客户端都使用完全相同的菜单。若某个入口不存在，不要照搬其他软件的路径，应先查看当前客户端的帮助文档或配置目录。
排查完成后的判断标准
可以按以下结果收尾：第一，状态码正常、返回内容可解析、Provider节点数量增加，说明订阅更新链路已经恢复；第二，Provider更新成功但节点全部超时，转向节点、DNS、系统时间和线路测试；第三，只有浏览器能打开而客户端失败，重点检查客户端使用的代理路径、TLS、请求头、重定向和解析器；第四，旧配置可用而新订阅持续返回错误，保留旧配置并联系服务商核验链接，不要反复删除和重装。
分享日志前，至少隐藏订阅完整URL、Token、UUID、节点地址中的认证参数、用户名、密码和本地IP。日志中只保留状态码、错误类型、客户端版本、系统平台和脱敏后的时间信息。
常见问题
Mihomo订阅更新失败，但浏览器可以打开链接，为什么？
浏览器能打开只能说明某条网络路径收到了响应，不代表客户端拿到的是可解析的订阅。先用日志确认客户端是否经过系统代理或TUN，再检查最终状态码、重定向、返回内容是否为登录页或HTML错误页，以及Provider是否保存了新的本地文件。
Mihomo更新订阅后节点没有变化，需要删除旧配置吗？
不建议立即删除。先备份主配置和Provider文件，核对服务端返回的更新时间、文件大小或节点数量，再检查过滤、覆写和缓存。如果新内容没有变化，删除旧配置通常不能解决服务端未更新或链接权限问题。
401和403在Mihomo订阅更新中有什么区别？
401优先检查订阅授权、Token、链接是否过期或是否复制错误；403表示服务端拒绝当前请求，除授权外还可能涉及访问策略。两者都应先重新复制完整订阅链接并查看响应头，不要公开完整URL。
订阅更新失败时要不要关闭TUN模式？
可以作为一次隔离测试，但不要把它当成固定修复。先记录当前设置，临时关闭TUN后刷新订阅；如果结果改变，说明请求路径或权限可能受TUN、系统代理或其他代理软件影响。测试完成后恢复设置并验证系统代理。
Mihomo节点为空和节点全部超时是同一个问题吗？
不是。节点为空通常发生在订阅解析、过滤、Provider保存或返回格式阶段；节点全部超时则表示节点已经加载，失败点更接近健康检查、DNS、系统时间、网络或线路。应先看Provider节点数量，再决定下一步。
日志中包含订阅链接，如何安全分享排查信息？
只保留错误类型、HTTP状态码、系统平台、客户端版本和时间，隐藏完整URL、Token、UUID、用户名、密码、节点认证参数及本地网络信息。无法确认已脱敏时，不要上传原始日志。