Clash 訂閱更新失敗排解：連結失效、逾時與自動更新間隔設定

先確認失敗環節：訂閱下載還是設定檔載入

「訂閱更新失敗」可能發生在三個環節：用戶端未能下載內容；伺服器有回傳內容，但不是可用的設定檔；檔案已儲存，核心載入時卻發現欄位或引用錯誤。這三種情況需要不同的處理方式。節點仍可連線，只能表示本機舊設定仍可用，不能證明訂閱網址依然有效。

先保留目前可用的設定檔，不要立刻刪除訂閱項目。記下用戶端名稱、核心類型、更新時間和完整錯誤訊息。提供記錄前，請遮蔽訂閱 URL 中的路徑金鑰、查詢參數、節點密碼及伺服器位址；訂閱連結通常具有存取憑證的效力。

連結失效：確認網址、帳戶與 HTTP 狀態碼

重新複製訂閱網址，不要複製帳戶頁面網址

1. 登入服務商後台，查看訂閱狀態、到期日和剩餘用量。能登入帳戶，不代表訂閱仍可下載。
2. 選擇明確標示為 Clash 或 Mihomo 的訂閱入口。瀏覽器網址列中的後台頁面網址不能取代訂閱網址。
3. 複製完整連結，保留 ? 後的查詢參數。移除複製時混入的空格、換行和中文標點。
4. 在原訂閱項目的編輯介面替換 URL，儲存後手動更新一次。如果先前重設過訂閱金鑰，也要同步替換其他裝置儲存的舊連結。

401 通常表示身分驗證問題；403 也可能是存取控制、地區限制或防護頁面所致，不能單憑狀態碼判定帳戶已過期。404 可能是路徑錯誤，也可能是服務商刻意隱藏無效憑證。請搭配後台狀態和回應內容判斷。

HTTP 200 也可能回傳錯誤頁面

伺服器回傳 200，只代表 HTTP 請求已成功取得回應。如果內容以 <!DOCTYPE html> 或 <html> 開頭，下載的可能是登入頁、驗證碼頁或維護頁面。此時繼續修改 YAML 縮排並無幫助，應先取得真正的訂閱回應。

不要將含有金鑰的訂閱網址貼到公開檢測網站。需要服務商協助排查時，提供狀態碼、發生時間和已遮蔽敏感資訊的錯誤內容即可；完整連結只應透過可信的私人支援管道傳送。

請求逾時：區分 DNS、TLS 與代理連線路徑

訂閱請求可能由用戶端本身發出，也可能由核心的 proxy-providers 發出，兩者使用的網路路徑不一定相同。開啟系統代理或 TUN 模式後，瀏覽器能連上網站，不代表用戶端的訂閱更新請求也經過相同出口。

依錯誤發生階段逐項檢查

• 網域解析失敗：no such host 出現時，優先檢查訂閱網域拼字、系統 DNS 和目前網路。不要直接將訂閱網域改成 IP，這可能導致 HTTPS 憑證驗證或虛擬主機路由失效。
• 連線逾時：dial tcp 後出現逾時訊息，表示連線階段未能正常完成。改用手機熱點測試，有助於判斷是目前網路受限還是伺服器故障。
• 等待回應逾時：context deadline exceeded 可能發生在不同階段。如果同時出現等待回應標頭的提示，應檢查伺服器負載和出口路徑，而不只是修改 DNS。
• TLS 錯誤：若出現 x509、憑證過期或主機名稱不符，先檢查裝置日期、時間和時區，再聯絡服務商處理憑證問題。不要關閉憑證驗證來掩蓋錯誤。

透過兩次對照更新找出連線路徑問題

如果用戶端提供訂閱更新的直連或代理選項，可先使用直連手動更新，再選擇一個目前可用的代理節點更新。每次只變更一項條件。直連成功、代理失敗時，請檢查所選節點和代理出口；代理成功、直連失敗時，則應檢查本機網路是否能連上訂閱網域。

如果目前設定檔中的所有節點都已失效，而更新又設定為必須經過其中某個節點，就可能形成依賴循環。此時應改用可用的更新路徑，或暫時透過另一個可信網路取得設定檔。不要先刪除唯一一份本機設定檔。

格式不相容：檢查完整設定檔與節點提供者

Clash YAML、Base64 編碼的節點連結和單一節點 URI 並非同一種輸入。若直接將一串 ss://、vmess:// 或 vless:// 連結當成完整 YAML 訂閱匯入，可能會出現解析錯誤。檔案副檔名是 .yaml，也不代表內容格式正確。

下載成功但載入失敗：檢查核心支援項目

Clash 與 Clash Meta（現稱 mihomo）支援的欄位和協定範圍並不完全相同。如果記錄提示未知的代理類型，應確認訂閱輸出格式是否符合目前核心，而不是將所有問題都歸因於連結失效。優先請服務商提供適用於目前核心的格式；若確實需要更換用戶端，先確認該用戶端使用的核心類型。

如果記錄指出 YAML 行號，請檢查該行及前後行的縮排、引號和清單符號。如果提示策略組或規則引用的名稱不存在，請確認 proxy-groups、rules 和節點名稱是否一致。遠端訂閱每次更新都可能覆寫手動修改；長期調整應放在用戶端支援的覆寫或合併設定中。

需要轉換格式時，優先使用服務商提供的目標格式。使用第三方線上轉換工具通常需要提供原始訂閱連結，代表對方可能取得訂閱內容和存取憑證，不宜隨意提交。

自動更新間隔：用戶端設定與 interval 欄位

自動更新分為兩個層級：用戶端定時下載整份訂閱；核心定時重新整理設定中的節點提供者。前者通常儲存在用戶端自己的訂閱中繼資料，後者則對應 proxy-providers 下的 interval。兩者不能互相取代。

在用戶端的訂閱編輯介面設定

以下以 Clash Verge Rev 常見介面為例：進入「訂閱」→ 在目標訂閱卡片上按右鍵 → 選擇「編輯」，找到「更新間隔」欄位。不同版本的選單文字可能不同，請以實際編輯介面為準。該介面通常以分鐘為單位，填寫前務必查看輸入欄位的單位提示，不要直接填入核心使用的秒數。

1. 先確認手動更新成功，再設定自動更新。可先設為 360 分鐘，也就是 6 小時，並遵守服務商的頻率限制。
2. 儲存編輯結果，確認用戶端是否需要另外啟用自動更新選項。不要把延遲測試間隔誤當成訂閱更新間隔。
3. 讓用戶端保持執行，觀察下一次更新記錄。關閉應用程式、裝置進入睡眠或系統限制背景執行，都可能使排程延後。

mihomo 節點提供者的 interval 單位為秒

以下是節點提供者範例，並非完整設定檔。範例網域僅用來說明結構，無法下載實際節點；套用時請使用自己的有效網址，並讓策略組透過 use 引用提供者。

proxy-providers:
  remote-nodes:
    type: http
    url: "https://subscription.example.com/nodes.yaml"
    path: ./providers/remote-nodes.yaml
    interval: 21600

此處的 21600 代表 21600 秒，也就是 6 小時。path 指向本機快取檔案，請確保執行核心的使用者對該目錄有寫入權限。如果 URL 回傳的是完整設定檔，而非相容的節點提供者內容，調整更新間隔也無法解決格式錯誤。

不要將 url-test 策略組的 interval，或提供者健康檢查間隔，當成訂閱更新間隔。這些欄位用來檢查節點可用性或測試延遲，不負責下載整份訂閱。如果記錄出現 429，應依服務商要求延長更新週期，不要持續每 60 秒請求一次。

更新後驗證：確認檔案、節點與規則都已生效

1. 查看更新結果：確認目標訂閱的更新時間已變更，且記錄沒有繼續顯示下載或解析失敗。只跳出「已送出請求」不代表更新完成。
2. 查看目前設定檔：確認目前使用的就是剛更新的訂閱。更新未啟用的設定檔，不一定會改變目前連線使用的節點清單。
3. 查看節點和策略組：確認節點數量、名稱及策略組引用是否正確。節點測試通過但仍無法連線時，也要檢查規則比對結果和出站選擇。
4. 查看後續排程：記錄下一次自動更新是否如期執行。手動更新成功、排程更新失敗時，優先檢查應用程式執行狀態、排程設定和當時的網路狀況，而不是重新產生連結。

如果仍然失敗，請將已遮蔽敏感資訊的記錄提供給服務商或用戶端維護者：包括用戶端名稱、核心類型、錯誤時間、HTTP 狀態碼或完整錯誤訊息，以及直連和代理兩種路徑的測試結果。請分別說明網路請求失敗、設定檔格式錯誤和排程未觸發的情況。

需要確認欄位時，請參閱設定參考；首次匯入訂閱可依照快速上手操作。更換用戶端前請先備份設定，避免訂閱失效問題和遷移問題混在一起。