Clash 訂閱更新失敗排除與自動更新間隔設定

先分清訂閱下載與節點連線

訂閱更新失敗時，先查看更新請求的錯誤訊息，不要急著重新安裝用戶端。更新訂閱是向 HTTP 或 HTTPS 網址請求設定檔；節點連線則是核心依照現有設定建立代理連線。兩者使用的伺服器、驗證方式和網路路徑可能完全不同。舊節點仍可使用，不代表訂閱連結有效；訂閱下載成功，也不保證每個節點都能連線。

另一個常見混淆是「完整設定檔」和「節點提供器」。用戶端的訂閱管理頁面通常會下載完整設定檔，再交由核心載入；proxy-providers 則由支援此功能的核心下載節點清單。這兩者各有不同的更新機制。只修改 YAML 裡的 interval，不一定會改變用戶端更新完整訂閱的時間。

1. 記下用戶端名稱、版本和核心類型，例如是否使用 mihomo；不要只寫「Clash 最新版」。
2. 手動按一次更新，記下發生時間及完整錯誤類型。
3. 確認失敗發生在下載、解析還是套用設定的階段。
4. 每次只變更一個條件；確認成功後再設定自動更新，避免同時修改 DNS、連接埠和訂閱網址。

依錯誤訊息排查網路與連結問題

先查看用戶端的訂閱通知、更新詳情或紀錄頁面。同樣顯示「更新失敗」，底層原因可能是連線逾時，也可能是伺服器已回傳拒絕存取。以下狀態碼和錯誤片段，比一概而論的彈出訊息更有參考價值。

換個網路交叉測試

在同一台裝置上先用目前的 Wi-Fi 更新，再改用手機熱點更新。如果熱點更新成功，問題可能出在目前網路的 DNS、對外連線限制或認證入口。公共 Wi-Fi 尚未完成網頁登入時，訂閱請求有時會收到登入頁面，而不是 YAML。瀏覽器能開啟服務商首頁，也不代表訂閱子網域和 API 都能連線。

如果紀錄出現 connection refused，也要確認拒絕連線的是哪個端點。若目標是 127.0.0.1:7890，通常應檢查本機代理連接埠是否正在監聽，而不是先懷疑訂閱伺服器。7890 只是常見範例，請以目前用戶端顯示的 HTTP 或混合連接埠為準。

分別處理憑證錯誤與訂閱過期

憑證錯誤：先校正時間，再檢查網路

x509: certificate has expired or is not yet valid 可能是伺服器憑證過期，也可能是裝置時間不正確。先開啟系統自動設定日期和時間，確認年份、日期與時區，再重新更新。若提示 certificate signed by unknown authority，請檢查系統憑證庫、企業網路的 HTTPS 檢查，以及用戶端所使用的執行環境是否過舊。

不要把「略過憑證驗證」當成長期解法。下載訂閱會用到帳戶權杖，關閉驗證會降低對伺服器身分的確認程度。此外，節點設定中的 skip-cert-verify 通常只影響該節點的 TLS 連線，無法通用地解決用戶端下載訂閱時的憑證問題。若已確認伺服器憑證異常，應由服務商修復。

連結過期：前往帳戶控制台重新取得

帳戶到期、權杖重設或舊訂閱網域停用，都可能使原網址失效。請前往服務商控制台確認方案狀態，選擇適用於目前用戶端或核心的訂閱格式，再複製完整連結。不要複製瀏覽器登入頁的網址，也不要漏掉問號後的參數。也請檢查通訊軟體是否自動換行，或連結末尾是否多了空格。

• 更換連結前請保留原訂閱記錄；可先新增一筆設定，確認更新成功後再移除舊項目。
• 遇到 403 時，不要直接認定帳戶已到期；請求來源或 User-Agent 限制也可能導致存取遭拒。
• 必須依靠登入 Cookie 才能下載的瀏覽器頁面，不一定能當作用戶端自動更新的 API。

下載成功但解析失敗，該如何排查

HTTP 狀態碼為 200 只表示伺服器成功回傳內容，不代表內容一定是 Clash 設定檔。如果錯誤訊息出現 HTML 標籤、DOCTYPE 或登入提示，通常表示收到的是網頁。若回傳的是 Base64 節點清單、ss:// 或 vmess:// 單一節點連結，也不能直接當成完整 YAML 設定檔匯入。

分清完整設定檔與 provider 檔案

• 完整設定檔：通常包含 proxies、proxy-groups、rules 等欄位，也可能透過 provider 引用外部節點。
• 節點 provider：常見 YAML 格式以 proxies: 存放節點，不包含完整的策略群組與規則。
• 規則 provider：常見內容以 payload: 存放規則，不能當作節點訂閱使用。

舊版 Clash 核心與 mihomo 支援的協定和欄位並不完全相同。如果紀錄指出不支援某種代理類型，請確認核心支援狀況或改用相容格式，而不是只調整縮排。手動編輯 YAML 時請用空格縮排，避免使用 Tab；同一層級的欄位應保持對齊。完整設定檔中的規則若引用不存在的策略群組，也可能造成「下載完成但套用失敗」。

優先從服務商提供的正確格式入口重新下載。若確實需要轉換，請使用可信任的本機工具或自行架設的轉換服務，並檢查轉換後是否保留所需的策略群組和規則。排查問題時，切勿公開貼上包含權杖的訂閱 URL。

如何設定用戶端自動更新間隔

請先確認手動更新成功，再啟用自動更新。初次可設為每 6 小時更新一次：若介面單位是分鐘，輸入 360；若單位是秒，輸入 21600。這是方便維護的起始設定，並非所有服務都適用。若服務商規定最低更新間隔，請依照其要求設定。

常見用戶端的設定位置

不同發行版本的選單名稱可能不同，請先查看訂閱項目的編輯視窗，不要只在全域網路設定中尋找。以下路徑可協助找到設定；實際欄位和單位請以目前版本顯示為準。

不要把 0 當成「立即更新」：有些用戶端以此代表關閉自動更新，也有些版本透過獨立開關控制。儲存後請查看「上次更新」時間是否變更；只有介面數值改變，並不能證明排程已執行。

電腦關機、用戶端退出或手機應用程式遭系統停止時，通常無法依排程更新。裝置休眠後是否會補跑任務，也取決於用戶端的實作方式。Android 若持續錯過更新，可前往系統「設定」→「應用程式」→ 對應用戶端 → 電池或背景管理，檢查是否有限制。不同廠牌的選單名稱不盡相同，不必為了更新訂閱而關閉所有系統省電功能。

provider 的 interval 與訂閱更新不同

使用 mihomo 的 HTTP 節點提供器時，proxy-providers 下的每個 provider 都可以設定自己的 interval，單位為秒。以下欄位片段應加入既有 HTTP provider 項目內部，並非完整設定檔；請保留原有的 type、url、path 等設定。

interval: 3600
proxy: DIRECT

這表示每隔 3600 秒（也就是 1 小時）嘗試更新該 provider，並指定透過直連下載。請確認目前核心支援 proxy 欄位；支援此欄位的 mihomo 也可填入已存在且可用的出站或策略群組名稱。不要將這些欄位直接套用到不支援它們的舊版核心。

• 用戶端更新完整訂閱：由用戶端排程，可能會取代整份遠端設定。
• provider 更新節點：由核心排程，只更新對應提供器的節點內容。
• health-check.interval：控制健康檢查頻率，不是下載節點清單的頻率。

如果直接修改遠端設定檔，下次用戶端更新時可能會覆蓋這些變更。若要長期保留修改，請使用用戶端提供的覆寫、合併或本機設定機制，並在更新後確認實際生效的設定。實際合併方式由用戶端決定，不能只檢查編輯器中的原始檔案。

透過代理更新訂閱的正確步驟

訂閱網域無法直接連線時，可嘗試透過代理下載，但前提是已經有可用的代理路徑。完整訂閱通常由用戶端自行發出網路請求下載；provider 則可能由核心下載。系統代理、TUN 模式和訂閱項目的代理開關並非同一項設定，啟用其中一項，不代表另外兩層的請求也會經過代理。

1. 先用舊設定啟動核心，選取已確認可用的節點。
2. 開啟訂閱項目的編輯或更新選單，尋找「使用代理」或類似選項；只有目前版本提供此選項時才啟用。
3. 若用戶端要求輸入代理網址，請填入實際正在監聽的 HTTP 或混合連接埠，例如 http://127.0.0.1:7890，不要填入控制介面連接埠。
4. 再次更新，確認錯誤是否從連線逾時變成明確的 HTTP 回應；同時檢查更新時間和新設定內容。

如果用戶端沒有獨立的訂閱代理開關，請查看該版本對系統代理或 TUN 的支援情況，不要假設請求一定會經過代理。TUN 能否攔截這類請求，也會受到路由、排除程序和 DNS 設定影響。HTTP 代理連接埠也不是外部控制介面；常見的控制連接埠 9090 用來管理核心，不能作為下載訂閱的代理。

恢復後確認以下五項

最後不要只看「更新成功」的提示。設定下載、核心套用設定和節點可用是三種不同結果，逐一確認才算排查完成。

1. 時間：訂閱的上次更新時間已變成本次操作時間，而不是仍顯示舊紀錄。
2. 內容：預期的策略群組和節點確實存在，而且目前選取的設定檔正確。
3. 紀錄：後續沒有 YAML 解析失敗、策略群組引用錯誤或不支援協定的提示。
4. 連線：使用一個實際需要代理的目標，確認目前的出口能正常建立連線。
5. 排程：讓用戶端保持執行，等到下一次預定時間後檢查是否自動更新；若更新失敗，記下當時的網路和休眠狀態。

若仍無法更新，請提供用戶端版本、核心版本、系統版本、錯誤發生時間、已遮蔽敏感資訊的錯誤行，以及「直連失敗、代理成功」等交叉測試結果。請勿公開訂閱權杖或節點密碼。清楚指出失敗階段，通常比反覆刪除設定或重新安裝更容易找出原因。