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 拆出「僅香港」「僅日本」「排除中轉」等子集合，再各自建一個策略組，比在一個幾百節點的大列表裡翻找方便得多。

常見問題