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 小時上下,平時就不用再管了。