Clash 订阅更新失败排查与自动更新间隔设置

先区分订阅下载与节点连接

订阅更新失败，先看更新请求的报错，不要马上重装客户端。订阅更新是向一个 HTTP 或 HTTPS 地址请求配置；节点连接则是内核按照现有配置建立代理连接。两者的服务器、认证方式和网络路径可能完全不同。旧节点还能使用，并不能证明订阅链接有效；订阅下载成功，也不能保证每个节点都能连通。

另一个常见混淆是“整份配置”和“节点提供器”。客户端的订阅管理页面通常下载完整配置，再交给内核加载；proxy-providers 则由支持该功能的内核下载节点集合。这两层各有更新机制。只改 YAML 里的 interval，不一定会改变客户端对整份订阅的刷新时间。

1. 记录客户端名称、版本和内核类型，例如是否使用 mihomo；不要只写“Clash 最新版”。
2. 手动点击一次更新，记下发生时间及完整错误类型。
3. 确认失败发生在下载、解析还是应用配置阶段。
4. 每次只改变一个条件，成功后再设置自动更新，避免同时改 DNS、端口和订阅地址。

按报错定位网络与链接问题

先找客户端的订阅通知、更新详情或日志页面。同样显示“更新失败”，底层可能是连接超时，也可能是服务器已经返回了拒绝访问。下面的状态码和错误片段，比弹出的笼统提示更有用。

用不同网络做一次对照

同一设备先用当前 Wi-Fi 更新，再用手机热点更新。如果热点成功，问题更可能落在当前网络的 DNS、出口限制或认证门户上。公共 Wi-Fi 尚未完成网页登录时，订阅请求有时会拿到登录页面，而不是 YAML。浏览器能打开服务商首页，也不代表订阅子域名和接口都可达。

如果日志出现 connection refused，还要看被拒绝的是谁。若目标是 127.0.0.1:7890，通常应检查本地代理端口是否监听，而不是先怀疑订阅服务器。7890 只是常见示例，以当前客户端显示的 HTTP 或混合端口为准。

证书错误与订阅过期分别处理

证书报错：先校时，再检查网络

x509: certificate has expired or is not yet valid 既可能是服务端证书过期，也可能是设备时间错误。先打开系统自动日期与时间，核对年份、日期和时区，再重新更新。若提示 certificate signed by unknown authority，则检查系统证书库、企业网络的 HTTPS 检查，以及客户端所用运行环境是否过旧。

不要把“跳过证书验证”当成长期修复。订阅下载涉及账户令牌，关闭校验会削弱对服务器身份的确认。另外，节点配置里的 skip-cert-verify 通常影响对应节点的 TLS 连接，并不能通用地修复客户端自身下载订阅时的证书问题。已经确认服务端证书异常，就应由服务商修复。

链接过期：从账户面板重新获取

账户到期、令牌重置、旧订阅域名停用，都可能让原地址失效。进入服务商面板检查套餐状态，选择适合当前客户端或内核的订阅格式，再复制完整链接。不要复制浏览器登录页地址，也不要漏掉问号后面的参数。聊天软件自动换行、末尾多出空格，也值得检查。

• 更换链接前保留原订阅记录；可以先新增一条配置，验证成功后再移除旧条目。
• 遇到 403 不要直接认定账户到期；请求来源、User-Agent 限制也可能导致拒绝。
• 浏览器依赖登录 Cookie 才能下载的页面，不一定能作为客户端自动更新接口使用。

下载成功但解析失败怎么查

HTTP 状态码为 200 只表示服务器成功返回内容，不表示内容一定是 Clash 配置。如果错误里出现 HTML 标签、DOCTYPE 或登录提示，往往是拿到了网页。若返回的是 Base64 节点列表、ss:// 或 vmess:// 单节点链接，也不能默认把它当作完整 YAML 配置导入。

分清完整配置与 provider 文件

• 完整配置：通常包含 proxies、proxy-groups、rules 等字段，也可能通过 provider 引用外部节点。
• 节点 provider：常见 YAML 格式以 proxies: 承载节点，不负责提供完整的策略组与规则。
• 规则 provider：常见内容以 payload: 承载规则，不能当作节点订阅使用。

旧版 Clash 内核与 mihomo 支持的协议和字段并不完全相同。日志若指出某个代理类型不支持，应核对内核能力或选择兼容输出，而不是只调整缩进。手工编辑 YAML 时使用空格缩进，避免 Tab；同层字段保持对齐。完整配置中的规则若引用了不存在的策略组，也可能导致“下载完成但应用失败”。

优先从服务商提供的正确格式入口重新下载。确实需要转换时，使用可信的本地工具或自行部署的转换服务，并检查转换后是否仍保留所需的策略组和规则。不要为了排错把含令牌的订阅 URL 公开粘贴出去。

客户端自动更新间隔怎么设

自动刷新应该在手动更新成功以后再启用。初始可设为每 6 小时一次：若界面单位为分钟，填写 360；若单位为秒，填写 21600。这是便于维护的起点，不是所有服务的统一要求。服务商若规定最低刷新间隔，应以其要求为准。

常见客户端入口

不同发行版会调整菜单文字，先看订阅条目的编辑窗口，而不是只找全局网络设置。以下入口用于定位设置，最终以当前版本显示的字段和单位为准。

不要把 0 当作“立即更新”：有些客户端用它表示关闭自动刷新，也有版本通过单独的开关控制。保存后观察“上次更新”时间是否变化；只有界面数值改变，不能证明定时任务已经运行。

电脑关机、客户端退出、手机应用被系统停止时，通常无法按计划刷新。设备休眠后是否补跑任务也取决于客户端实现。Android 若持续错过刷新，可在系统「设置」→「应用」→ 对应客户端 → 电池或后台管理中检查限制；不同厂商的菜单名称会变化，不必为了订阅更新关闭所有系统节能功能。

provider 的 interval 与订阅刷新不同

使用 mihomo 的 HTTP 节点提供器时，proxy-providers 下每个 provider 可有自己的 interval，单位是秒。下面是加入已有 HTTP provider 条目内部的字段片段，不是完整配置；原有的 type、url、path 等设置应保留。

interval: 3600
proxy: DIRECT

这里表示每 3600 秒，也就是 1 小时，尝试更新该 provider，并指定通过直连下载。proxy 字段需确认当前内核支持；在支持该字段的 mihomo 中，也可以填写已经存在且可用的出站或策略组名称。不要把这些字段照搬到不支持它们的旧内核里。

• 客户端刷新完整订阅：由客户端调度，可能替换整份远程配置。
• provider 刷新节点：由内核调度，只更新对应提供器的节点内容。
• health-check.interval：控制健康检查频率，不是下载节点列表的频率。

如果直接修改远程配置文件，下次客户端刷新时可能覆盖这些改动。需要长期保留的修改，应使用客户端提供的覆写、合并或本地配置机制，并在更新后检查实际生效的配置。具体合并行为由客户端决定，不能只看编辑器里的源文件。

经代理更新订阅的正确顺序

订阅域名直连不可达时，可以尝试经代理下载，但前提是已有一条能用的代理路径。完整订阅通常由客户端自己的网络请求下载；provider 则可能由内核下载。系统代理、TUN 模式、订阅条目的代理开关并不是同一个设置，开启其中一个，不保证另外两层的请求都会走代理。

1. 先用旧配置启动内核，选择一个已经验证可用的节点。
2. 进入订阅条目的编辑或更新菜单，寻找「使用代理」或类似选项；只有当前版本提供时才启用。
3. 若客户端要求填写代理地址，使用实际监听的 HTTP 或混合端口，例如 http://127.0.0.1:7890，不要把控制接口端口填进去。
4. 再次更新，查看失败是否从连接超时变为明确的 HTTP 响应；同时检查更新时间和新配置内容。

如果客户端没有单独的订阅代理开关，需查看该版本对系统代理或 TUN 的支持，不要假定请求一定被接管。TUN 能否覆盖这类请求，还受路由、进程排除及 DNS 设置影响。HTTP 代理端口也不是外部控制接口；常见的控制端口 9090 用于管理内核，不能当作订阅下载代理使用。

恢复后检查这五项

最后不要只看“更新成功”的提示。配置下载、内核应用、节点可用是三个不同的结果，分别确认才算排查完成。

1. 时间：订阅的上次更新时间已经变为本次操作时间，而不是仍显示旧记录。
2. 内容：预期的策略组和节点确实存在，当前选中的配置也正确。
3. 日志：没有随后的 YAML 解析失败、策略组引用错误或不支持协议提示。
4. 访问：用一个实际需要代理的目标确认当前出口能正常建立连接。
5. 定时：客户端保持运行并到达下一次计划时间后，检查是否自动刷新；若失败，记录当时的网络与休眠状态。

仍然失败时，向维护者提供客户端版本、内核版本、系统版本、报错时间、脱敏后的错误行，以及“直连失败、代理成功”这类对照结果。订阅令牌和节点密码不需要公开。能把失败阶段说清楚，通常比反复删除配置、重新安装更快找到原因。