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

先确认失败发生在哪一层

Clash 的订阅更新并不只是一次下载。客户端先请求订阅地址，再解析响应内容，随后保存配置或节点集合，最后交给内核加载。任何一步失败，界面都可能只显示“更新失败”。先记录错误原文、更新时间和当前配置名称，比反复点击更新更有效。

还要区分两种订阅：图形客户端管理的远程完整配置，以及 mihomo 配置中 proxy-providers 管理的节点提供者。前者的更新周期通常由客户端保存；后者使用提供者内部的 interval 字段。两者不是同一个定时器，修改其中一个不会自动改变另一个。

链接失效与服务端拒绝：先查状态码

重新复制链接，不手工拼接参数

进入订阅服务的账户后台，确认套餐、流量和有效期，再复制面向 Clash 或 Clash Meta 的订阅地址。重置订阅令牌后，旧链接可能立即失效；客户端仍保存旧地址时，自动刷新也只会重复失败。复制时检查前后空格、换行，以及聊天软件是否把 & 之后的参数截断。

403 不一定代表套餐过期，也可能来自访问策略、请求头限制或防护页面。200 同样不保证订阅正常：登录页、验证页和错误提示页也可能返回成功状态。判断依据必须包括响应正文，而不是只看浏览器能否打开地址。

用 curl 区分 HTTP 错误与连接错误

下面的命令在 Bash 中运行，需要已安装 curl。地址通过隐藏输入读取，避免直接写入 shell 历史。输出文件仅供本机检查，可能包含节点凭据；操作后删除。这里的 20 秒是本次诊断的超时上限，不是客户端默认值。

umask 077
read -r -s -p '订阅地址：' SUB_URL
printf '\n'
curl --noproxy '*' --location \
  --connect-timeout 10 --max-time 20 \
  --output subscription-response.txt \
  --write-out 'HTTP=%{http_code}\nTYPE=%{content_type}\n' \
  "$SUB_URL"

HTTP=000 不是服务端状态码，通常表示没有获得有效 HTTP 响应，需要结合 curl 的错误提示判断 DNS、连接或证书问题。隐藏输入也不等于完全隔离秘密：运行期间 URL 仍可能出现在本机进程参数中，不应在不可信的共享主机上执行。

• 返回 301 或 302 后，确认最终目标不是登录页；上面的 --location 会跟随重定向。
• 返回 429 时，优先遵守 Retry-After，不要用每分钟更新来尝试恢复。
• 出现证书错误时，检查系统时间与证书链，不要把跳过 TLS 验证作为长期解决方式。

网络被拦截与更新未走代理

浏览器可以访问订阅，不代表客户端的更新器也能访问。浏览器可能经过系统代理，而更新器可能直接联网；反过来，启用了 TUN 或透明网关时，标记为“直连”的请求也可能在网络层被接管。因此，下面的对照只能判断 curl 是否显式使用 HTTP 代理，不能单凭命令名称证明底层流量完全绕过了 TUN。

对照测试本地代理端口

先在客户端确认 HTTP 或 mixed 监听端口。以下使用 127.0.0.1:7890，仅适用于本机确实监听该端口的情况。若配置是 mixed-port: 7897，就把命令中的端口改为 7897。

curl --noproxy '' --proxy http://127.0.0.1:7890 \
  --location --connect-timeout 10 --max-time 20 \
  --output subscription-via-proxy.txt \
  --write-out 'HTTP=%{http_code}\nTYPE=%{content_type}\n' \
  "$SUB_URL"

unset SUB_URL

显式代理成功、前一次请求失败，说明网络路径值得优先检查，但还不能证明图形客户端已使用相同路径。回到客户端开启订阅更新相关日志，手动刷新一次，观察是否出现对应请求；再核对该请求使用的代理、策略组和错误信息。部分客户端的下载器独立于内核，连接面板中未出现记录也不能直接认定请求没有发出。

避免订阅更新的循环依赖

• 只有订阅内节点能访问订阅域名，而这些节点又全部失效时，开启“更新时使用代理”并不能恢复连接。需要可用的备用路径或由服务商提供可访问的入口。
• 如果日志显示订阅域名命中 DIRECT，而直连已确认失败，应在明确网络需求后调整规则，并检查实际命中结果。
• 如果报错是域名解析失败，先核对订阅主机名和 DNS 日志。不要同时更改 DNS、TUN、规则与端口，否则难以判断哪项修改生效。
• 如果仅在某个 Wi-Fi 下失败，用移动网络做一次对照；这可以帮助定位网络环境差异，不必先重装客户端。

格式不兼容：下载成功后仍需验证

订阅接口可能返回完整 YAML、仅包含节点的 YAML、编码后的分享链接列表，或者其他客户端的专用格式。图形客户端是否自动转换，取决于具体实现。mihomo 的 HTTP 节点提供者与完整配置加载器也有不同的输入约定，不能把同一份响应不加区分地塞进任意位置。

按响应内容检查结构

1. 在本地文本编辑器打开响应文件。若开头是 <!doctype html> 或登录界面文本，问题仍在下载或认证阶段，不是 YAML 缩进。
2. 完整配置通常包含 proxies、proxy-groups、rules 等字段；原生 YAML 节点提供者通常以 proxies: 描述节点列表。具体字段组合仍以实际用途为准。
3. 检查 proxy-groups、rules 引用的名称是否存在。节点下载成功但策略组引用缺失，也会导致配置无法正常使用。
4. 如果服务商提供 Clash 与 Clash Meta 两种输出，按当前内核选择。旧 Clash 内核不一定支持 mihomo 的新字段或协议。

本机已安装 mihomo 时，可对完整配置副本执行语法与配置检查。下面假定文件已保存为当前目录下的 config.yaml；节点提供者文件不能直接当作完整配置验证。配置涉及外部文件时，还要保证工作目录与依赖路径正确。

mihomo -v
mihomo -t -d . -f ./config.yaml

-v 用于记录实际内核版本，便于核对字段支持情况；-t 检查通过也不代表每个节点都能连接。保存错误原文与内核版本后再定位，不要通过删除所有不认识的字段来强行加载。若必须进行格式转换，应使用可信且受控的方式，避免向不明转换站提交完整订阅令牌。

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

自动更新设置属于客户端界面功能，不同版本可能调整名称与位置。先在“关于”页面记录客户端版本，再打开目标订阅的编辑窗口。不要把“节点延迟测试间隔”当成订阅下载周期，也不要把“更新全部订阅”误认为启用了定时任务。

Clash Verge Rev 可先在订阅编辑窗口查找“更新间隔”和“使用代理”一类字段。若该版本把更新方式放在卡片菜单中，应从菜单执行相应的代理更新操作；一次手动代理更新成功，并不必然表示以后定时更新也沿用该模式，需要重新打开设置确认保存结果。

Clash for Windows 与 Clash for Android 已属停止维护的历史客户端，界面项目会随存量版本不同而变化。如果当前界面没有代理更新开关，不要照抄其他客户端的菜单路径。应结合日志确认更新请求的实际路径，或迁移到仍维护且支持现有配置的客户端。

按界面单位输入周期

一般可先选 6 小时或 12 小时，再按服务商限制调整。界面标注“分钟”时，6 小时填 360，12 小时填 720；标注“小时”时分别填 6 和 12。不要仅凭输入框里的数字判断单位。保存后手动更新一次，并核对“上次更新”是否变化。

移动端还受后台执行、电池优化和系统休眠限制。定时更新通常不能保证在锁屏后精确到秒触发；桌面客户端完全退出后也通常不会继续执行自身定时任务。若只在重新打开应用后更新，应先排查应用生命周期，而不是继续缩短周期。

mihomo 的 interval 与代理更新字段

对 HTTP 类型的 proxy-providers，interval 的单位是秒。例如 21600 为 6 小时，43200 为 12 小时，86400 为 24 小时。这是节点提供者下载周期，不是完整远程配置的自动刷新设置。

在支持相应字段的 mihomo 版本中，提供者的 proxy 可以指定下载使用的出站代理或策略组。下面仅展示可合并到已有 HTTP 提供者中的字段，不是完整配置；保留原有 url、path 与提供者名称。PROXY 必须是配置中已经存在且当前可用的出站名称。

interval: 21600
proxy: PROXY
health-check:
  enable: true
  url: https://www.gstatic.com/generate_204
  interval: 600

这里的 health-check.interval: 600 表示每 600 秒进行健康检查，并不表示每 10 分钟下载订阅。健康检查 URL 应根据网络可达性与使用需求选择；示例中的地址是连接检测目标，不是订阅地址。

命令行运行 mihomo 并不会因为在配置顶层添加 interval 就定时重新下载整个配置。若确实需要刷新完整配置，应由受控的外部任务负责下载、验证、备份和重新加载，失败时保留原文件；不要直接把网络响应覆盖到正在使用的配置上。

更新后没有变化：按这六项复查

1. 确认更新对象。检查卡片名称和订阅地址来源，避免更新了备用订阅，却仍在使用另一份配置。
2. 确认时间与内容。更新时间变化只说明客户端记录了更新操作；服务端也可能返回相同内容。节点数量没有变化不能单独证明失败。
3. 确认新配置已加载。有些客户端将“下载”和“激活”分开，需要选中配置或检查重载日志。
4. 确认节点列表来源。策略组若只引用本地固定节点，远程提供者更新后，该组未必出现新节点。检查 use 与提供者名称。
5. 确认筛选条件。地区筛选、正则过滤或排除规则可能隐藏新节点，先核对提供者原始节点数量。
6. 确认自动任务仍在运行。重启客户端后检查更新间隔是否保留，并在下一次运行后查看时间记录。

最后清理诊断时保存的响应文件，避免它们留在同步目录或共享文件夹中。若仍需向维护者反馈，提供客户端版本、内核版本、错误时间、HTTP 状态码和已脱敏的错误原文即可；订阅令牌、节点密码与完整响应不应作为公开附件。

rm -f subscription-response.txt subscription-via-proxy.txt

推荐的处理顺序是：确认链接有效 → 对照请求路径 → 检查响应格式 → 验证配置加载 → 设置合理更新周期。自动刷新只能减少手动操作，不能修复失效令牌、错误格式或不可达的下载路径。