Clash 订阅管理：更新失败、鉴权与健康检查排查指南

订阅到底是什么，出了问题该看哪里

平时说的"导入订阅"，在配置文件层面对应的其实是 proxy-providers 字段：客户端定期访问一个 URL，把返回的节点列表拉下来、解析成节点，塞进对应的策略组。搞懂这一层原理，遇到"订阅更新失败"时才知道该往哪个方向排查。

proxy-providers:
  my-sub:
    type: http
    url: "https://example.com/sub?token=xxx"
    interval: 3600       # 每 3600 秒自动更新一次
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

大多数图形化客户端会把这一大段配置藏在"导入订阅"的输入框背后，你填的那个链接就是 url 字段，界面上的"更新间隔"对应 interval，本质上没有区别。

订阅更新失败的几种常见原因

• 被识别成"非正常客户端"拒绝访问部分订阅服务会检查请求的 User-Agent，屏蔽非常见客户端的请求。可以在 header 字段里手动指定一个常见的 UA 字符串伪装过去。
• 订阅链接需要鉴权如果订阅地址需要携带 Authorization 头才能访问（常见于自建面板的订阅接口），同样通过 header 字段附加上去，而不是把 token 拼在 URL 里（部分服务两种方式都支持，但优先用 header 更规范）。
• 拉取订阅本身需要走代理如果订阅服务器本身在境外，而你的网络访问境外网站需要先有一个可用节点，就会出现"没有可用节点导致订阅拉不下来，订阅拉不下来又导致没有节点"的死循环。这时可以用 proxy 字段指定一个固定的引导节点专门用来更新订阅。
• 订阅文件体积超出限制size-limit 字段默认不限制，但如果客户端或面板自己设置了更保守的限制，超大的订阅文件会被直接拒绝，可以适当调大或去掉这个限制。

proxy-providers:
  my-sub:
    type: http
    url: "https://example.com/sub"
    proxy: 直连引导节点    # 专门用于更新订阅的固定出口
    header:
      User-Agent:
        - clash-verge/v2.0.0
      Authorization:
        - Bearer your-token-here

用 health-check 揪出失效节点

订阅节点用久了，服务器下线、限速、被墙都是常事，如果不做健康检查，策略组里会混着一堆连不上的"僵尸节点"，自动测速/自动选择时体验很差。health-check 就是解决这个问题的：

在对应的 proxy-providers 条目下加一段 health-check，指定一个稳定的检测地址（推荐 https://www.gstatic.com/generate_204 或 https://cp.cloudflare.com），客户端会按设定的间隔定期给每个节点发一次检测请求。

• enable：是否启用健康检查，建议始终开启。
• interval：检测间隔，单位秒，不需要设得太短，300～600 秒足够。
• lazy：默认 true，表示节点没被实际使用时不检测，省资源；如果想让面板一直显示准确的延迟数据，可以关掉，但会增加一点后台流量。

订阅节点太多太杂？用 filter 精简

有些订阅一次给几百个节点，全部塞进一个策略组既难选又难看。filter / exclude-filter 可以按关键词或正则筛选/排除节点，把同地区、同用途的节点单独拆成几个策略组。

proxy-providers:
  hk-only:
    type: http
    url: "https://example.com/sub"
    filter: "(?i)港|hk|hongkong"
  no-relay:
    type: http
    url: "https://example.com/sub"
    exclude-filter: "(?i)中转|relay"

同一个订阅地址可以配置成多个 proxy-providers 条目，分别用不同的 filter 拆出"仅香港""仅日本""排除中转"等子集合，再各自建一个策略组，比在一个几百节点的大列表里翻找方便得多。

常见问题