Clash 订阅自动更新间隔怎么设置？更新失败的常见原因

先区分：订阅更新、节点测速与连接状态

Clash 订阅自动更新，是客户端定时请求远程订阅地址，再用返回内容更新本地配置或节点来源。它不等于节点测速，也不等于定时更换出口。服务器没有修改订阅内容时，更新成功后节点数量完全不变，属于正常结果。

设置前先看清订阅由谁管理。Clash Verge Rev 一类桌面客户端通常在界面中维护远程配置；直接运行 mihomo 内核的部署，则可能通过 proxy-providers 拉取节点。两处都能出现“更新间隔”，但它们控制的对象、单位和计时进程并不相同。

• 远程配置更新：下载一份完整配置，可能同时改变节点、策略组、规则与 DNS 设置。
• 节点提供者更新：只刷新某个 proxy-providers 对应的节点集合，不会自动替换主配置中的规则。
• 健康检查：测试节点是否可用。health-check.interval 是检测周期，不是订阅下载周期。

Clash Verge 类客户端的自动更新设置位置

以下以 Clash Verge Rev 常见界面为例。不同发行版本可能把入口放在卡片右键菜单或更多菜单，字段也可能显示为“更新间隔”或“自动更新”。先确认正在编辑的是远程订阅，不是本地 YAML 文件。

1. 进入左侧「订阅」，找到当前使用的订阅卡片，记录卡片上的更新时间。
2. 右键订阅卡片，打开「编辑信息」；使用更多菜单的版本，从同一张卡片的菜单进入编辑窗口。
3. 检查订阅 URL 是否仍为服务商当前提供的地址，找到「更新间隔」，按字段标注的单位填写数值。
4. 若有独立的自动更新开关，开启后保存。以分钟为单位时，12 小时填 720，24 小时填 1440。
5. 返回订阅卡片，执行一次「更新」，确认没有下载或解析错误，再检查更新时间是否改变。

不要把“编辑信息”和“编辑文件”混用：前者通常保存 URL、名称和定时设置，后者修改配置文本。把 interval: 720 随意写进完整配置的顶层，并不能替代客户端自己的订阅定时任务。

为什么设好间隔后仍没有自动更新？

桌面客户端的定时任务通常依赖应用进程持续运行。关闭窗口但保留托盘，与从托盘选择退出，是两种状态。电脑休眠期间也不能按时发起网络请求；恢复后是否立即补更，取决于客户端实现，不能只凭休眠前设定的时间推断。

• 先让客户端保持运行，确认手动更新可以成功。
• 区分“开机自启”和“启动时更新”：开启前者不代表一定执行后者。
• 检查是否编辑了另一张同名订阅卡片，当前启用配置是否就是刚修改的那一项。
• 不要默认 0 代表立即更新；它可能表示关闭定时或采用默认值，应查看当前界面的字段说明。

更新间隔设多少：6、12、24 小时的选择

间隔应根据订阅变更频率决定，而不是根据测速结果决定。节点延迟升高，不一定是订阅过旧；节点已经下线而服务商已发布替代地址时，更新订阅才可能解决问题。

表中是配置建议，不是服务端承诺。没有明确需求时，不建议设成每 1 分钟刷新：一天会产生 1440 次请求，多台设备共用地址还会叠加请求量，可能触发服务端限流。遇到节点集中故障，可以先手动更新一次；连续点击更新并不能缩短服务端恢复时间。

若订阅响应或服务商说明提供了建议周期，应同时检查客户端是否采纳该建议。不要仅依据导入时看到的默认数字判断单位，尤其是从旧客户端迁移配置时。

mihomo 的 proxy-providers：interval 使用秒

自行维护 mihomo 配置时，HTTP 节点提供者的 interval 位于具体提供者之下，单位是秒。下面是结构示例：每 12 小时下载一次节点，每 5 分钟执行一次健康检查。这两个周期相互独立。

proxy-providers:
  remote-nodes:
    type: http
    url: "https://subscription.example.net/nodes.yaml"
    path: ./providers/remote-nodes.yaml
    interval: 43200
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 300

proxy-groups:
  - name: Subscription
    type: select
    use:
      - remote-nodes

示例中的 subscription.example.net 是说明用域名，不能直接获取节点。实际部署需换成自己的节点提供者地址，并确认返回内容适用于提供者格式；完整 Clash 配置与仅含节点的提供者文件，不能在所有场景下直接互换。健康检查地址也应按当前网络可达性选择。

• interval: 43200：控制提供者远程内容更新，不控制整份主配置的下载。
• health-check.interval: 300：控制节点探测，不会下载新节点。
• path：指定本地缓存文件；运行内核的账户需要具备相应目录的写入权限。
• use：让策略组引用该提供者；只声明提供者而不引用，不等于策略组会自动出现其节点。

修改主配置后，需要让 mihomo 重新加载配置才能应用新周期。若主配置本身由客户端订阅更新生成，直接修改下载文件可能在下次更新时被覆盖，应使用客户端支持的覆写或合并机制保存本地定制。

更新失败的常见原因：按错误类型检查

1. 超时或域名解析失败：先检查订阅地址的网络路径

网页能打开，只能说明浏览器当前的网络路径可用。订阅请求可能由客户端后台发出，不一定使用浏览器扩展或相同的系统代理。先记录日志中的订阅域名与错误，再区分 DNS 解析失败、TCP 连接超时和 TLS 握手失败。

可以在本机查看该地址返回的 HTTP 状态与内容类型，但不要把完整订阅 URL 上传到公共检测网站。若浏览器返回登录页或验证页，即使状态为 200，客户端也无法把 HTML 当作 Clash 配置解析。

2. 当前代理不可用：更新请求依赖了故障节点

部分客户端提供“通过代理更新”等下载方式。如果订阅域名被规则分配到当前失效节点，更新会依赖这个失效节点完成，形成自举问题。优先切换到已知可用节点后手动更新；若订阅地址支持直连，也可在客户端支持的范围内改用直连更新。

不要为此立即关闭所有代理设置。订阅站点若只能通过代理访问，强制直连反而会让问题固定重现。TUN 模式也不保证订阅请求一定走代理，最终路径仍取决于路由、规则和应用自身的请求实现。

3. 本地代理端口异常：确认监听值与配置一致

假设客户端的混合端口设为 7890，外部工具却仍连接旧端口 7897，就可能出现连接被拒绝。这里的数字只是排查示例，实际值应从当前客户端设置读取，不能把任何一个端口当作所有客户端的固定默认值。

• 检查是否同时运行了两个代理客户端，导致预期端口被另一进程占用。
• 检查日志是否出现 address already in use 或 connection refused。
• 修改端口后，同步检查系统代理、浏览器代理扩展，以及终端的 HTTP_PROXY、HTTPS_PROXY 环境变量。

端口冲突并不必然阻止订阅下载；只有更新请求依赖这个本地代理端口时，才会沿这条路径失败。若日志已显示服务端返回 403，应继续检查地址权限，而不是反复更改端口。

4. 401、403、404 或 429：检查权限、链接与限流

401 通常与认证有关，403 可能来自权限限制或站点防护，404 可能意味着路径已失效，429 表示请求过于频繁。这些状态不能单独证明套餐到期，需要结合服务商账户页面和响应内容判断。

在服务商账户内重新复制适用于 Clash 或 mihomo 的订阅地址，核对订阅是否被重置、账户是否到期、流量是否用尽。若返回 429，先停止连续重试；存在 Retry-After 提示时按其等待，并调长各设备的自动更新间隔。

5. 下载成功但解析失败：检查返回格式与内核支持

“解析失败”与“网络超时”不是一类问题。检查返回内容是否为 YAML，是否误复制了网页分享地址，是否获取了其他客户端的订阅格式。新协议或新字段还可能要求更新的 mihomo 内核，图形界面能打开不代表内核能识别所有节点类型。

不要在尚未备份时删除仍可用的旧配置。先保留当前配置，再核对下载内容和错误行号；排查 YAML 时注意缩进使用空格，同一层级保持一致，含特殊字符的 URL 应使用引号包裹。

修改后的验证流程与订阅地址保护

设置完成后，至少验证一次“手动下载成功”和一次“定时任务触发”。前者证明地址及当前网络可用，后者才证明自动更新配置正在生效。不要仅凭节点数量判断，因为服务器可能返回完全相同的内容。

1. 记录当前订阅名称、更新时间和已设周期，例如 720 分钟。
2. 手动更新，确认日志没有下载失败、解析失败或配置加载失败。
3. 保持客户端运行，跨过一个完整更新周期，再核对更新时间与相应日志。
4. 如果下载成功但实际节点未改变，确认当前启用的配置与提供者引用，再检查服务端是否确实发布了新内容。
5. 验证完成后保留正常周期，不要把临时测试用的短间隔长期留在多台设备上。

排查顺序可以固定为：确认更新对象与单位 → 手动更新 → 查看错误类别 → 检查请求路径 → 验证定时触发。需要核对系统代理、规则模式或 TUN 配置时，可继续查看故障排查；初次导入订阅则从配置教程开始。