Clash 订阅更新失败排查:链接过期、格式不符与自动更新间隔设置

先分清：订阅下载失败，还是配置加载失败

Clash 订阅更新通常经过三个环节：客户端请求订阅地址，解析返回内容，再把有效配置交给内核加载。出现“更新失败”时，节点不一定已经失效；旧配置可能仍在内存中正常运行。反过来，页面显示下载成功，也不代表新配置一定能被当前内核接受。

先打开客户端的「日志（Logs）」页面，再到「配置（Profiles）」页面对目标订阅执行一次更新。不同客户端可能把这个页面命名为「订阅」，以实际界面为准。记录这次操作的时间、错误关键词以及订阅的最近更新时间，不要同时删除配置、切换内核和重置网络。

• 请求阶段失败：常见提示包括 timeout、no such host、403 或 429，优先检查地址、网络和服务端响应。
• 解析阶段失败：出现 yaml、unmarshal、invalid config 等关键词，重点检查返回格式和配置内容。
• 加载阶段失败：下载完成后提示不支持某种代理类型，或配置应用失败，需要核对内核兼容性。

链接过期与访问受限：从 HTTP 状态码定位

重新复制订阅地址，而不是服务商网页地址

进入订阅提供方的账户页面，确认服务有效期、流量状态，以及是否执行过“重置订阅链接”。重置后，旧地址中的令牌可能立即失效。复制时选择面向 Clash 或 mihomo 的订阅入口，避免复制登录页、账户首页、二维码图片地址，或带有临时登录状态的下载地址。

完整地址通常包含查询参数。不要随意删除 ? 后的内容，也不要把聊天软件附带的句号、引号或换行一起粘进去。若怀疑旧链接失效，可保留旧订阅条目，另建一个条目测试新地址；确认能加载后再清理旧条目。

浏览器能打开，不代表客户端能更新

浏览器可能携带登录 Cookie、经过人机验证，或走了与客户端不同的代理路径。客户端拉取订阅通常不会继承这些浏览器状态。地址在浏览器里显示正常，只能证明浏览器当前的请求成功，不能代替客户端日志中的结果。

如果提供方对请求头或客户端类型有要求，应使用其文档给出的官方订阅入口。不要通过随机修改 User-Agent 来反复碰运气；这可能改变服务端输出的格式，让原本的访问问题变成格式问题。

格式不兼容：区分完整配置、节点列表与内核支持

订阅不是一种统一文件格式。完整 Clash YAML 通常包含 proxies、proxy-groups 和 rules；代理集合文件通常只有 proxies，供 proxy-providers 引用。另一些地址返回的是分享链接列表或编码后的文本，不能假定所有客户端都能把它们直接作为完整配置加载。

按错误内容逐项检查

1. 正文以 HTML 开头：例如出现 <!DOCTYPE html> 或登录提示，说明拿到的是网页，不是 YAML。回到订阅入口和访问权限排查。
2. 提示 YAML 行号：检查该行附近的缩进、冒号和引号。YAML 缩进使用空格，不用 Tab；不要把富文本编辑器中的全角标点粘进字段名。
3. 提示缺少代理组或引用不存在：检查规则引用的组名、组内节点名是否存在。只下载节点列表，不能自动补齐所有分流规则。
4. 提示未知代理类型或字段：核对实际运行的内核及版本。客户端界面版本和内核版本是两项信息，通常可在「关于」或「内核」设置中查看。

mihomo 延续并扩展了 Clash 配置生态，但旧版 Clash 内核并不支持所有新增协议和选项。如果订阅明确面向 mihomo，应使用与之匹配的客户端和内核。保留完整错误行，在升级前备份配置；不要为了消除报错就删掉不认识的协议字段。

更新请求被自身代理拦截：分别测试直连和代理

一种常见循环是：客户端更新订阅需要经过当前代理，而当前节点已经不可用，新的节点信息又必须通过订阅下载。此时网页和订阅可能一起超时。另一种情况恰好相反：订阅域名在当前网络无法直连，但客户端更新默认使用直连。

先确认请求由谁发出。完整远程配置通常由客户端管理程序下载；proxy-providers 中的远程代理集合则由内核管理。客户端的“通过代理更新”选项，不一定控制内核代理集合的请求。只切换 Rule、Global 或系统代理开关，也不保证更新进程改变路径。

1. 在目标订阅的编辑菜单或客户端设置中查找「通过代理更新」「更新代理」等选项；部分客户端不提供独立开关，应查其更新日志或说明。
2. 如果当前更新走代理，先选一个已确认可用的节点，再执行一次更新。若仍失败，改用直连测试一次。
3. 如果当前更新走直连，且日志显示连接订阅域名超时，可用可用代理测试；也可临时切换手机热点，对比是否为当前网络限制。
4. 测试结束恢复需要的配置，记录哪条路径成功。每次只改一项，避免把网络切换与配置修改混在一起。

端口、DNS 与证书错误不要混为一谈

connection refused 127.0.0.1:7890 表示某个请求尝试连接本机 7890 端口但未成功，应检查内核是否运行，以及实际 mixed-port 是否仍为 7890。若已改成 7897，相关更新代理设置也要同步，不能继续指向旧端口。

no such host 更接近域名解析问题；x509 或证书有效期错误则应先检查 Windows 的日期、时间与时区，再考虑网络中的 HTTPS 检查或服务端证书异常。不建议关闭证书验证来掩盖问题。遇到连接超时，也不要立即认定是 DNS 故障，应结合日志判断卡在解析、连接还是 TLS 握手。

自动更新间隔：客户端订阅与代理集合分开设置

完整订阅的定时更新在客户端中管理

打开「配置（Profiles）」或「订阅」页面，在目标条目的右键菜单或更多菜单中寻找「编辑」「编辑信息」或更新设置，检查自动更新是否启用，以及间隔单位。菜单名称随客户端变化，不能把某一个客户端的设置路径当作全部 Clash 客户端的通用路径。

• 提供方没有特别要求时，可以从每 12 小时更新一次开始观察。界面单位若为分钟，填写 720；若为小时，填写 12。
• 每天一次对应 1440 分钟或 24 小时。不要只看数字大小而忽略单位。
• 不要把 0 当作“立即更新”。它可能表示关闭、使用默认值或其他行为，应以该客户端说明为准。
• 若客户端支持读取服务端建议间隔，可优先遵循提供方说明；并非所有客户端都会识别或采用该建议。

桌面客户端退出后，其进程内的定时任务通常不会继续执行。Windows 睡眠期间也不能按普通运行状态拉取订阅。仅让内核服务在后台运行，不代表负责完整订阅更新的界面进程仍在工作。需要定时刷新时，应确认客户端保持运行，并检查唤醒或重新启动后的更新时间。

proxy-providers 的 interval 单位是秒

如果使用 mihomo 的远程代理集合，interval 属于内核配置，单位为秒。下面是一个说明字段关系的片段，不是完整订阅；示例域名不提供实际服务，使用时必须填写自己的可信地址。

proxy-providers:
  remote-nodes:
    type: http
    url: "https://example.com/nodes.yaml"
    path: ./providers/remote-nodes.yaml
    interval: 86400

这里 86400 表示 24 小时，43200 表示 12 小时，3600 表示 1 小时。代理集合还需要由代理组通过 use 引用，返回内容也应符合代理集合格式。不要把这个字段直接加到 YAML 顶层，期待它控制客户端的完整订阅刷新。

代理集合中的 health-check.interval 用于节点健康检查，不是下载订阅的频率。把健康检查改为 300 秒，只会影响相应检查任务，并不表示每 5 分钟重新获取节点列表。涉及长期修改时，使用客户端支持的覆写或合并功能，避免下次订阅更新覆盖本地调整。

手动强制刷新：保留旧配置，再验证新内容

手动更新适合验证链接是否恢复，或在提供方明确通知节点变更后立即获取配置。“强制刷新”不是统一菜单名称：有的客户端只有「更新」，有的提供「更新全部」或忽略本地更新周期的操作。它不保证绕过服务端缓存，也不会修复失效令牌。

1. 保存现场：记录当前生效的配置名称、更新时间和可用节点，必要时导出备份到本机受保护目录。
2. 只刷新目标条目：在配置列表中对该订阅执行一次「更新」，避免多个订阅同时失败而难以定位。
3. 检查结果：对照日志时间确认请求完成，观察最近更新时间是否变化，以及是否出现解析或内核加载错误。
4. 确认生效：如果客户端没有自动重载，手动选中更新后的配置并应用，再核对代理组是否存在、规则模式是否符合预期。
5. 实际验证：测试一个应直连的网站和一个应经过代理的目标，在连接记录里核对命中的规则与出口。单看节点数量变化不够。

更新时间变化但节点列表不变，可能只是上游内容没有变化，并不必然是缓存故障。反复给地址附加随机参数也不是通用解决办法：带签名的链接可能因此失效。若新配置加载失败，应保留日志并切回可用配置，而不是连续删除整个配置目录。

仍然失败时，整理这几项信息

向订阅提供方或客户端项目反馈前，准备一份最小诊断记录，通常比“更新不了”更有帮助。错误信息保留原文，但不要公开订阅地址、授权头或节点凭据。

• 运行环境：Windows 版本、客户端名称与完整版本号、实际内核名称与版本号。
• 故障时间：例如本地时间 09:20 执行手动更新，注明时区，便于服务端查日志。
• 错误阶段：请求失败、YAML 解析失败，还是下载成功但应用失败。
• 对照结果：直连是否成功、可用代理是否成功、切换热点后是否仍失败。
• 定时设置：自动更新是否启用，间隔数字及单位，故障时客户端是否退出或电脑是否睡眠。

排查顺序保持一致：先确认链接和账户状态，再确认返回格式，随后比较更新请求的网络路径，最后处理定时任务。这样能把服务端、客户端与内核问题分开，也能避免为一次临时订阅故障重置整套 Windows 网络配置。