Clash 订阅更新失败原因汇总与自动更新间隔设置

先保留可用配置，再手动更新一次

Clash 订阅更新失败，不等于当前节点立即失效。客户端通常会继续使用上一次成功下载的配置；如果旧节点仍然可用，可以先维持连接，再排查更新链路。不要一开始就删除订阅、清空配置目录或反复重装，否则可能把能够联网的旧配置一并移除。

进入「配置」或「Profiles」，确认当前启用的订阅名称，记录最近更新时间。
使用客户端的导出或备份功能保存现有配置。文件可能包含节点密码、订阅令牌，应只保存在可信设备。
对目标订阅执行一次「更新」，随后打开「日志」，记录完整错误、发生时间和 HTTP 状态码。
确认失败对象是整份订阅，还是配置内部的某个 proxy-providers。两者使用的下载器与更新周期可能不同。

按错误信息定位失败环节

先看下载是否拿到响应，再看响应能否解析。下面的提示可能由客户端包装成中文，判断时以日志中的底层错误为准。不要仅凭一个状态码就认定账户到期，还要结合订阅服务后台和响应内容。

日志或现象	优先检查	下一步操作
`401 / 403`	令牌、访问限制、账户状态	登录服务后台重新复制专用订阅地址，检查是否需要指定客户端类型。
`404 / 410`	旧接口、被撤销的链接	核对服务方当前提供的入口，不凭猜测改 URL 路径。
`429`	请求过于频繁	暂停连续重试；有 `Retry-After` 响应头时按其要求等待。
`500 / 502 / 503`	服务端或网关异常	保留旧配置，稍后重试并查看服务通知。
`no such host`	订阅域名解析	检查当前 DNS、域名拼写和所在网络。
`timeout / deadline exceeded`	路由、代理出口、响应速度	分别测试直连和经过可用代理的更新路径。
`x509` 或 TLS 错误	系统时间、证书链、网络拦截	同步时间，排查认证门户及 HTTPS 检查软件。
YAML 解析失败	响应类型和配置兼容性	检查下载内容是否为 HTML、节点列表或不兼容配置。

HTTP 200 只说明服务器返回了内容，不代表内容就是可用的 Clash 配置。有些认证门户会返回登录网页，有些接口会把错误信息放进 JSON，客户端随后才报 YAML 或字段类型错误。

链接过期与令牌失效怎么处理

重新复制完整 URL，不手动拼接参数

从订阅服务后台复制“Clash”或“Clash Meta / mihomo”对应的订阅入口，再替换原配置的远程地址。账户到期、重置订阅令牌、迁移订阅域名，都可能让旧地址失效。二维码只是 URL 的另一种传递方式，扫码导入并不会绕过令牌验证。

检查链接首尾是否混入空格、换行或中文标点。聊天软件复制出来的 & 也可能破坏原参数。
不要把网页控制台地址当成订阅地址。能在浏览器登录的页面，不一定能被客户端作为配置下载。
若新旧链接的令牌不同，先在一台设备验证，再同步到其他设备；频繁重置会让所有旧设备一起失效。
不要把完整订阅 URL 发到公开截图、在线转换工具或问题讨论区。排障时保留域名及错误类型即可，隐藏路径中的凭据和查询参数。

403 也可能来自服务端防护或客户端标识限制。若后台确认账户有效，应查看服务方提供的客户端兼容说明，而不是不断更换 DNS。DNS 无法修复已被服务器拒绝的访问权限。

直连失败与代理更新的选择

先确认客户端的订阅下载器走哪条网络路径。浏览器通过系统代理访问成功，不代表客户端后台下载也经过相同代理；某些客户端有独立的“通过代理更新”选项，另一些会使用自身网络栈。TUN 模式能接管更多流量，但不能保证所有后台更新请求都走指定节点。

用两次受控测试替代连续重试

保持当前可用节点，手动更新一次，记录是否超时。
若客户端提供「通过代理更新」，切换该选项后再试一次；没有此项时，查阅该客户端说明，不直接假设系统代理一定有效。
若仅代理路径成功，保留该更新方式；若仅直连成功，检查所选出口是否被订阅服务限制。
两条路径都失败时，再检查域名解析、服务端状态和本地防火墙，避免继续盲目切换节点。

桌面端也可用 curl 做对照。以下命令会在本机交互输入地址，避免把令牌直接写进命令历史。输出文件同样含敏感信息，检查完成后应删除。示例只适用于有 Bash 与 curl 的环境。

read -r -s -p '输入订阅 URL：' SUB_URL
printf '\n'
curl --noproxy '*' --connect-timeout 10 --max-time 30 \
  -D subscription.headers -o subscription.body "$SUB_URL"
unset SUB_URL

这里的 10 秒是连接超时，30 秒是整次请求的时间上限，不是实测延迟。--noproxy '*' 绕过 curl 的代理设置，但不能绕过系统路由或已开启的 TUN。需要对照真正的非 TUN 路径时，应先记录现有设置，再临时关闭 TUN 测试。

若用 curl 指定本地代理，应读取客户端显示的 HTTP 或混合端口。例如实际监听为 127.0.0.1:7890 时才使用 --proxy http://127.0.0.1:7890。不要把控制接口端口当作代理端口；不同配置的监听值可能不同。

证书错误与格式不兼容

TLS 报错先查系统时间

出现 certificate has expired、certificate is not yet valid 或 unknown authority 时，先打开系统的日期与时间设置，启用自动校时。随后确认公共 Wi-Fi 是否需要网页认证，并检查安全软件是否对 HTTPS 连接做了中间解密。

如果只有某个订阅域名持续报证书错误，而其他 HTTPS 服务正常，应让服务方检查证书有效期和中间证书链。节点配置中的 skip-cert-verify 不是订阅下载的通用修复开关，不能用它解决订阅服务器证书问题，也不建议为排障长期关闭证书验证。

拿到内容后再判断格式

完整 Clash YAML：通常包含 proxies、proxy-groups、rules，也可能通过 providers 引用外部资源，应交给兼容客户端加载。
Base64 节点列表：可能解码为多行协议链接，不等于完整 Clash 配置。应优先从服务后台选择对应格式。
Provider YAML：常见为只含 proxies 的节点集合，适合放入 proxy-providers，不应默认当作完整分流配置使用。
HTML 或 JSON 错误响应：先解决登录、权限或网关问题，调整 YAML 缩进没有作用。

Clash 是客户端与内核生态的统称，Clash Meta 后续以 mihomo 名称维护。旧内核不一定支持新协议与新字段。日志若明确提示不支持的代理类型，应核对实际运行的内核及服务方兼容要求，而不是只看桌面程序名称。手动修改前先备份；YAML 缩进使用空格，不使用 Tab。

各客户端自动更新间隔在哪里设置

整份远程配置的定时刷新通常由图形客户端负责，不存在一个能控制所有客户端订阅的通用顶层 interval。先打开对应订阅的编辑面板，再看字段标注的单位。下表是常见入口；不同发行版的中文翻译、按钮位置和字段名称可能调整，以当前安装版本实际界面为准。

客户端	常见操作路径	注意事项
Clash Verge Rev	「配置」→目标远程配置的右键菜单或更多菜单→「编辑信息」→「更新间隔」	修改的是该配置条目的刷新周期；按界面标注确认单位并保存。
Clash for Windows	「Profiles」→右键远程配置→「Settings」→「Update Interval」	项目已停止维护；旧版界面与兼容能力有差异，保留配置后再考虑迁移。
Clash for Android	「配置」→目标远程配置的编辑入口→「自动更新」或更新间隔字段	旧项目已停止维护；后台刷新还受系统电池限制及应用后台权限影响。
其他 mihomo 图形客户端	「配置 / 订阅」→目标条目的「编辑」或「设置」	若只有手动更新按钮，不应假定它支持定时刷新，需核对该版本功能。

怎样选更新周期

普通节点订阅可以先设为每 6 小时一次，即按字段单位填写 360 分钟或 21600 秒。这是起始建议，不是所有服务的要求。服务方明确规定最低间隔时，以其规定为准；只有少量节点且长期稳定的订阅，可以改为每 12 或 24 小时。

不要将间隔设成 1 分钟来“修复”更新失败。权限、证书和格式错误不会因高频请求自动消失，反而可能触发 429。间隔为 0 的含义也并不统一，有的客户端表示停用自动更新，有的可能恢复默认值，应查看字段提示。

mihomo 的 Provider 更新是另一层

如果整份配置已经下载成功，但节点集合仍未变化，应检查 proxy-providers。mihomo 的 HTTP provider 支持以秒为单位的 interval，由内核获取外部节点文件；这与图形客户端刷新整份订阅互不等同。

下面只演示适合放入现有配置的本地 provider 片段，文件需要预先存在，并且包含合法的节点集合。它不执行远程更新，不能通过添加一个 interval 就变成 HTTP 订阅：

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml

对于现有的 HTTP provider，应保留其真实 url 和其他必要字段，在该 provider 内设置 interval: 21600，表示每 6 小时更新节点文件。不要把这行写进 rules，也不要写到配置最外层后期待整份订阅自动刷新。

proxy-providers.名称.interval：控制该 HTTP 节点集合的下载周期，单位为秒。
health-check.interval：控制 provider 节点的健康检查周期，不会下载新节点。
rule-providers.名称.interval：用于相应 HTTP 规则集合的更新，不负责刷新节点列表。

远程订阅下次刷新可能覆盖手动编辑的 provider 设置。需要长期保留时，应使用客户端支持的覆写、合并或扩展配置功能，并查看最终生效配置。只在编辑器里保存成功，还不足以证明运行中的内核已经应用新值。

更新恢复后的验收步骤

检查下载结果：确认最近更新时间改变，日志中没有新的 HTTP、TLS 或解析错误。
检查配置启用状态：确认当前选中的是刚更新的配置，而不是同名的本地副本。
检查策略组：查看节点是否变化，原先选中的节点被移除时，重新选择可用出口。
检查实际连接：打开需要代理的目标服务，在连接记录中核对规则与出口。订阅成功不代表流量已经按预期分流。
检查下一周期：记录当前时间和更新间隔，下一周期后查看时间戳，确认定时任务确实运行。

最后保留一条可用的恢复路径：备份当前配置、记录订阅入口、了解手动更新位置。若仍然失败，向服务方或客户端维护者提交脱敏日志、客户端与内核版本、错误发生时间、直连及代理测试结果。不要提交完整订阅地址或包含凭据的配置文件。