Clash 订阅自动更新设置:更新间隔、失败提示与手动刷新方法

订阅自动更新：先分清更新的对象

Clash 订阅自动更新，是客户端或内核按计划重新请求订阅地址，再读取服务端返回的配置或节点列表。它不等于更新客户端安装包，也不等于给所有节点测速。设置更新间隔之前，先确认当前使用的是远程订阅，还是从电脑导入的本地 YAML 文件。

• 远程配置订阅：通常由客户端管理，可能包含节点、代理组、规则和 DNS 设置；更新后哪些内容生效，取决于客户端的合并与覆写机制。
• 本地配置文件：只有磁盘上的配置内容，没有远程来源时，开启定时检查也不能凭空获得新节点。
• 节点提供者：mihomo 的 proxy-providers 可以独立拉取节点，更新频率由对应提供者的配置控制。
• 规则提供者：rule-providers 更新的是规则集合，不负责刷新订阅账户中的节点。

主流客户端在哪里设置自动更新

不同客户端不共享一套订阅管理界面，同一客户端的不同版本也可能调整按钮名称。先进入订阅或配置列表，找到实际使用的远程配置卡片，再打开该卡片的编辑菜单。不要只在全局“设置”里查找，也不要把应用版本的自动检查开关当成订阅更新开关。

Clash Verge Rev：从订阅卡片进入编辑

1. 打开左侧「订阅」，确认当前启用的是哪张远程订阅卡片。
2. 打开该卡片的更多菜单，选择「编辑」，查找更新间隔或自动更新相关字段。
3. 先读字段旁的单位。如果显示“分钟”，可以用 360 作为每 6 小时更新一次的起点；不要直接填以秒计算的 21600。
4. 保存后，在同一张卡片上执行一次「更新」，确认远程地址有效，再观察后续自动更新。

如果卡片没有远程地址，先确认是否误选了本地配置。订阅里的全局扩展脚本、覆写配置与远程原文是不同层次；更新后结果不符合预期时，要同时检查这些本地处理，而不是立即反复导入链接。

FlClash：在配置详情中检查更新选项

进入「配置」，打开对应远程配置的编辑或详情入口，检查自动更新开关、更新间隔及订阅地址。具体标签随版本和平台变化，按界面实际显示的时间单位填写。如果当前版本只提供手动刷新，就使用配置项的刷新入口，不要在 YAML 顶层自行添加一个名为 auto-update 的字段。

Clash for Windows：辨认旧版 Profiles 界面

仍在使用旧版 Clash for Windows 时，远程订阅位于 Profiles，订阅卡片的右键菜单中可检查编辑和更新相关选项。该客户端已停止维护，旧教程中的按钮位置不一定适用于当前其他客户端。迁移前应保存订阅来源与必要的本地覆写，再到下载中心选择适合系统的客户端。

更新间隔怎么选：先用 6 小时，再按需要调整

订阅提供方有明确建议时，优先遵循其要求。没有说明时，每 6 小时一次可以作为起点，而不是必须遵守的标准。下面是设置建议，不是客户端默认值，也不是网络实测数据。

把间隔改成 1 分钟通常没有收益。服务端可能没有新内容，却会收到更多请求，甚至返回 429 限流。持续请求失败时，更短的间隔只会制造更多报错记录，不能修复地址失效或 DNS 故障。

分钟、小时、秒不能混填

• 6 小时 = 360 分钟 = 21600 秒。
• 12 小时 = 720 分钟 = 43200 秒。
• 24 小时 = 1440 分钟 = 86400 秒。

不要假设填 0 一定表示禁用：客户端可能将它解释为关闭、使用默认值或无效输入。优先使用明确的开关，并阅读字段提示。修改后重新进入编辑窗口，确认数值确实已保存。

mihomo 的 interval 与客户端定时刷新有何区别

只使用图形客户端导入完整订阅时，通常直接设置客户端的更新间隔即可。自行维护 mihomo 配置，并通过 HTTP 类型的 proxy-providers 拉取节点时，还会遇到内核级的 interval。该字段以秒为单位，与客户端界面里可能使用的分钟不是一回事。

例如，已有 HTTP 节点提供者希望每 6 小时拉取一次，可在该提供者原有配置中调整下面这一行。它是局部字段示例，不是可独立运行的完整配置；保留现有订阅地址、路径及其他必要字段。

interval: 21600

同一提供者下的 health-check.interval 则是健康检查间隔，不是订阅拉取间隔。规则提供者也可以有自己的 interval，但它更新的是规则文件。看到同名字段时，先看它位于哪一层，再决定修改哪个值。

订阅更新失败：按提示区分地址、网络和格式

遇到“更新失败”，先记录具体错误、失败时间和当前网络。保留原订阅卡片，避免在排查过程中删除仍能使用的旧配置。一次明确的手动更新，比连续点击十次更容易看清问题。

401、403、404：先检查订阅来源

• 401：通常与身份验证或令牌有关，检查账户状态与链接是否被重置。
• 403：可能是访问限制、防护策略或账户权限问题，不能仅凭状态码认定已经欠费。
• 404：检查链接是否截断、路径是否变化，以及是否误用了服务方的网页登录地址。

从服务方账户页面重新复制订阅链接，检查首尾空格与换行。订阅地址经常包含账户令牌，不要公开发到群聊、问题截图或在线转换网站。确实泄露后，应在服务方后台重置地址，再更新客户端保存的来源。

timeout、DNS、TLS：先检查获取订阅的网络

timeout 表示请求没有在规定时间内完成；no such host 通常指向域名解析；证书相关的 TLS 错误则需要核对系统日期、时间和网络环境。酒店或校园网络尚未完成网页认证时，也可能把请求重定向到登录页。

1. 确认普通网页能正常打开，并完成当前网络要求的登录认证。
2. 检查系统时间，临时关闭其他代理或 VPN 工具，排除相互接管。
3. 若客户端提供“通过代理更新”或类似选项，分别确认当前请求使用的路径，再测试一次；不同客户端的订阅请求不一定遵循相同设置。
4. 切换到手机热点复测。如果热点成功而原网络失败，应优先排查原网络的 DNS、认证或访问限制。

不要为了消除 TLS 报错就长期跳过证书验证。若当前节点已经失效，而更新请求又必须经过该节点，会形成无法自救的依赖；此时应尝试可用节点、允许的直连路径或其他网络，而不是只缩短定时间隔。

YAML、解析错误：检查实际返回的内容

HTTP 请求成功不代表得到的是有效配置。服务端可能返回套餐到期提示、登录页面或格式不兼容的数据。查看客户端日志中的解析信息，确认链接提供的是 Clash 或 mihomo 可用的配置类型；必要时联系服务方，不要随意修改订阅生成文件的缩进来掩盖根因。

如果日志出现 429，停止连续刷新，按服务端提示等待；没有明确等待时间时，先延长间隔再重试。若多台设备共用同一订阅，它们的请求也可能共同计入服务方的限制。

手动刷新之后，怎样确认新配置已经生效

1. 更新正确的卡片。在订阅列表找到当前使用的配置，点击它的更新或刷新按钮，等待结果返回。
2. 检查更新时间。确认显示的是本次成功时间，而不是上次尝试时间；有日志时同时查看成功记录。
3. 核对实际变化。对照服务方通知检查节点名称或数量。节点没有变化不一定意味着失败，也可能是远程内容未变。
4. 确认当前启用项。更新未启用的订阅不会自动保证流量切换过去。有些客户端会自动重载活动配置，有些需要重新选择或应用。
5. 测试当前代理组。检查选中的节点，再进行一次延迟测试和实际访问；不要仅凭节点列表出现新条目判断连接正常。

续费后额度仍显示旧值，也不一定说明节点列表未更新。流量与到期时间可能来自服务端返回的订阅信息，是否展示、何时刷新都取决于客户端及服务方支持。以账户后台状态和更新日志交叉判断。

自动更新没有按时执行：检查后台运行与休眠

更新间隔通常不是全天候运行的服务器任务。电脑关机、客户端退出或手机应用被系统限制后台运行时，不能假设它仍会准点请求。设备唤醒后是否立即补跑，也取决于客户端的调度实现。

• 电脑端：确认客户端进程仍在运行，并区分“关闭窗口”和“退出程序”。需要开机自动运行时，再开启相应启动设置。
• Android：检查电池优化与后台运行权限。VPN 服务仍在运行，不必然代表订阅更新任务也能按预期执行。
• 长期休眠设备：恢复使用时先手动刷新一次，不要把睡眠期间没有更新直接判断为订阅失效。