Clash 订阅更新失败的常见原因与自动更新设置方法

先确认症状:更新失败的三种典型表现

订阅更新失败不是单一故障,而是一组症状的统称。动手排查之前,先看清自己遇到的是哪一种:

• 点击「更新」后转圈几秒,弹出超时或 Error 提示,订阅条目的时间戳停在原处不动。
• 提示更新成功,节点列表却毫无变化,时间戳仍停留在几天之前——多半是读到了本地缓存,或新配置没有写入成功。
• 订阅条目直接标红、节点数归零,日志里出现 context deadline exceeded、403 Forbidden、401 Unauthorized 等字样。

打开客户端的日志面板,把报错原文完整记下来再往下查。「更新失败」四个字没有信息量,报错原文才有。

网络原因:更新请求默认不走代理

这是订阅更新失败里占比最高的一类原因,也是最容易被忽略的一类。

订阅更新本质上是一次普通的 HTTPS 请求:客户端向订阅地址发起连接,把节点列表拉回来。多数客户端默认让这次请求直连,不经过任何代理。于是出现一个看似矛盾的现象——节点明明能用,订阅却更新不了。原因很直接:节点流量走代理隧道,而更新请求在隧道外面裸奔。订阅域名一旦在本地网络不可达,或机房到本地的线路质量差,直连请求就会超时。

对应的处理办法有三条,按顺序试:

1. 开启 TUN 模式或系统代理,再手动点一次更新。TUN 接管整机流量后,更新请求也会被带进隧道,绕开直连阻断。TUN 的具体开启与排错见配置进阶页。
2. 打开客户端订阅设置里的「通过代理更新」选项。Clash Verge Rev 在订阅条目的编辑菜单中提供该开关;FlClash 与 Clash Meta for Android 的订阅编辑里也有同类设置。开启后即使直连不通,更新也能完成。
3. 手写 mihomo 配置的用户,在 proxy-providers 中给订阅源指定 proxy 字段,下载流量即走指定代理组:

proxy-providers:
  airport:
    type: http
    url: "https://example.com/api/sub?token=xxxx"
    interval: 43200
    proxy: 节点选择
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

不写 proxy 字段时默认 DIRECT 直连,这正是多数人更新失败的根源。

链接原因:失效、重置与格式错配

网络层面没问题,就查链接本身。订阅链接失效有四种典型情况:

• 套餐到期或流量耗尽:机场会直接切断订阅响应,返回 403 或空内容。登录机场官网确认套餐状态,这一步能排除掉一半「客户端坏了」的误判。
• 订阅被重置:在机场后台点过「重置订阅」后,旧 token 立即作废,客户端里的旧地址会永久更新失败。复制新链接重新导入即可。
• 机场更换域名:老域名不可达或被弃用后,旧链接可能跳转异常或直接失联,以官网公告的最新订阅地址为准。
• UA 格式错配:不少机场按请求的 User-Agent 返回不同格式。浏览器打开订阅看到一长串 base64,不代表 Clash 能用——Clash 系客户端需要 YAML。客户端 UA 被误判时会拿到通用格式,解析直接报错。

mihomo 用户可在 proxy-providers 里用 header 字段显式指定 UA,强制按 Clash 格式返回:

proxy-providers:
  airport:
    type: http
    url: "https://example.com/api/sub?token=xxxx"
    interval: 43200
    header:
      User-Agent:
        - "clash.meta"

另外,经过第三方订阅转换站的链接,转换站宕机或域名不可达同样会导致更新失败。排错阶段建议绕开转换站,先用机场原始订阅链接验证一遍。

环境原因:系统时间、写入权限与安全软件

链接和网络都正常,问题就落在本机环境上。按命中率从高到低排:

• 系统时间偏差过大:TLS 证书校验依赖系统时间,差出几分钟就会握手失败,日志里通常带 certificate 字样。校准时间并开启自动同步后重试。
• 网络被中间拦截:公司内网、校园网做 TLS 审查时,客户端不信任中间证书,更新必然失败。切换到手机热点验证一次即可定位。
• 配置目录无写入权限:订阅内容下载成功却写不进本地文件,表现为「更新了但没变化」。Windows 上把客户端装进 Program Files 又以普通权限运行的,最容易踩中;检查配置目录权限与磁盘剩余空间。
• 安全软件拦截:部分杀毒软件会拦下客户端的出站请求,将客户端主程序加入白名单再试。
• 客户端版本过旧:Clash 原始内核已停止维护,对新格式订阅的兼容性越来越差。换用 mihomo 内核的现役客户端,解析类问题通常直接消失。

自动更新:间隔怎么设才合理

自动更新的原理很简单:客户端按设定间隔重复那次 HTTPS 请求。间隔的选择是两头权衡——太短,频繁请求订阅接口,既消耗机场接口配额,又可能触发机场对高频访问的风控,把订阅临时封掉;太长,节点增减、入口地址变更等关键信息拿不到,用着用着就断线。

经验区间是 6 到 24 小时一次。各客户端的设置位置与单位如下:

两个容易混淆的点。其一,mihomo 配置里 interval 的单位是秒,不是分钟,想设 12 小时就填 43200;其二,proxy-providers 里 health-check 的 interval 是节点延迟检测频率,与订阅下载频率互不相干,改的时候别动错行。

最后保留手动更新的习惯:机场公告更换入口或调整节点时,不要干等下一轮自动更新,进客户端手动点一次,立即生效。

更新之后:四步核对清单

1. 核对订阅条目的时间戳,确认已刷新到当前时间。
2. 核对节点数量与分组结构,与机场官网公告是否一致。
3. 对正在使用的节点做一次延迟测试——订阅更新后旧节点可能已下线,挂着失效节点会表现为「有代理但没网」。
4. 浏览器访问一个境外站点确认链路通畅;不通则回到节点列表重新测速挑选。

订阅问题的排查顺序可以固定下来:先看报错原文,再查网络直连,再查链接状态,最后查本机环境。九成以上的更新失败都能在这四步里定位。剩下的交给自动更新,间隔设在 12 小时上下,平时就不用再管了。