Clash 訂閱自動更新間隔怎麼設定？更新失敗的常見原因

先釐清：訂閱更新、節點測速與連線狀態

Clash 訂閱自動更新，是由客戶端定時向遠端訂閱網址發出請求，再根據回傳內容更新本機設定或節點來源。這和節點測速、定時更換出口都不一樣。若伺服器沒有更新訂閱內容，即使更新成功，節點數量完全沒變也屬正常。

設定前先確認訂閱由哪一方管理。Clash Verge Rev 這類桌面客戶端通常會在介面中管理遠端設定；直接執行 mihomo 核心的部署方式，則可能透過 proxy-providers 擷取節點。兩處都可能有「更新間隔」設定，但控制的對象、單位與計時方式並不相同。

• 遠端設定更新：下載完整設定檔，可能同時變更節點、策略群組、規則與 DNS 設定。
• 節點提供者更新：只更新特定 proxy-providers 對應的節點集合，不會自動替換主設定中的規則。
• 健康檢查：測試節點是否可用。health-check.interval 是檢查週期，不是訂閱下載週期。

Clash Verge 類客戶端的自動更新設定位置

以下以 Clash Verge Rev 常見介面為例。不同版本的入口可能位於卡片右鍵選單或更多選單，欄位名稱也可能是「更新間隔」或「自動更新」。請先確認編輯的是遠端訂閱，而非本機 YAML 檔案。

1. 在左側選擇「訂閱」，找到目前使用的訂閱卡片，並記下卡片上的更新時間。
2. 在訂閱卡片上按右鍵，開啟「編輯資訊」；若版本使用更多選單，請從同一張卡片的選單開啟編輯視窗。
3. 確認訂閱 URL 仍是服務商目前提供的網址，找到「更新間隔」，依欄位標示的單位填入數值。
4. 若有獨立的自動更新開關，請開啟後儲存。若單位是分鐘，12 小時填 720，24 小時填 1440。
5. 返回訂閱卡片，執行一次「更新」，確認沒有下載或解析錯誤，再查看更新時間是否有變更。

不要混淆「編輯資訊」與「編輯檔案」：前者通常用來儲存 URL、名稱和排程設定，後者則是修改設定內容。隨意把 interval: 720 加到完整設定檔的最上層，無法取代客戶端自己的訂閱排程。

設定好間隔後，為什麼還是沒有自動更新？

桌面客戶端的排程通常需要應用程式持續執行。關閉視窗但保留在系統匣，和從系統匣選擇結束，是兩種不同狀態。電腦休眠時也無法按時發出網路請求；恢復後是否會立即補更新，取決於客戶端的實作，不能只根據休眠前設定的時間判斷。

• 先讓客戶端保持執行，並確認手動更新可以成功。
• 請分清「開機時自動啟動」和「啟動時更新」：開啟前者不代表後者一定會執行。
• 確認是否修改了另一張同名訂閱卡片，以及目前啟用的設定是否就是剛才修改的項目。
• 不要直接認定 0 代表立即更新；它可能表示停用排程或使用預設值，請查看目前介面的欄位說明。

更新間隔設多少合適：6、12、24 小時怎麼選

更新間隔應依訂閱內容的變動頻率決定，而不是看測速結果。節點延遲升高，不一定是訂閱過期；只有節點已下線、服務商也已提供替代網址時，更新訂閱才可能解決問題。

表格列出的是設定建議，不是伺服器端的保證。沒有明確需求時，不建議設成每 1 分鐘更新一次：一天會發出 1440 次請求，多部裝置共用同一網址時請求量還會增加，可能觸發伺服器限流。若多個節點同時故障，可以先手動更新一次；連續點擊更新並不會讓伺服器更快恢復。

若訂閱回應或服務商說明有建議週期，也請確認客戶端是否採用該建議。不要只根據匯入時顯示的預設數字判斷單位，尤其是從舊版客戶端遷移設定時。

mihomo 的 proxy-providers：interval 單位是秒

自行管理 mihomo 設定時，HTTP 節點提供者的 interval 設在個別提供者底下，單位為秒。以下範例每 12 小時下載一次節點、每 5 分鐘進行一次健康檢查，兩種週期彼此獨立。

proxy-providers:
  remote-nodes:
    type: http
    url: "https://subscription.example.net/nodes.yaml"
    path: ./providers/remote-nodes.yaml
    interval: 43200
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 300

proxy-groups:
  - name: Subscription
    type: select
    use:
      - remote-nodes

範例中的 subscription.example.net 是說明用網域，無法直接取得節點。實際部署時，請換成自己的節點提供者網址，並確認回傳內容符合提供者格式；完整 Clash 設定與僅包含節點的提供者檔案，並非在所有情況下都能互換。健康檢查網址也應依目前網路是否可連線來選擇。

• interval: 43200：控制提供者遠端內容的更新頻率，不會下載整份主設定。
• health-check.interval: 300：控制節點探測，不會下載新節點。
• path：指定本機快取檔案；執行核心的帳戶必須具備對應目錄的寫入權限。
• use：讓策略群組引用該提供者；只宣告提供者但未加以引用，不代表策略群組會自動列出其中的節點。

修改主設定後，必須重新載入 mihomo 設定，新週期才會生效。若主設定是由客戶端透過訂閱更新產生，直接修改下載的檔案可能會在下次更新時被覆蓋，請使用客戶端支援的覆寫或合併機制保留自訂內容。

更新失敗的常見原因：依錯誤類型逐項檢查

1. 連線逾時或網域解析失敗：先檢查訂閱網址的網路連線路徑

網頁能開啟，只能證明瀏覽器目前使用的網路路徑可連線。訂閱請求可能由客戶端在背景發出，不一定會使用瀏覽器擴充功能或相同的系統代理。請先記下記錄中的訂閱網域與錯誤，再區分 DNS 解析失敗、TCP 連線逾時和 TLS 交握失敗。

可以在本機查看網址回傳的 HTTP 狀態碼與內容類型，但不要將完整訂閱 URL 上傳到公開檢測網站。若瀏覽器回傳登入頁或驗證頁，即使狀態碼是 200，客戶端也無法將 HTML 當成 Clash 設定解析。

2. 目前代理無法使用：更新請求依賴故障節點

部分客戶端提供「透過代理更新」等下載方式。如果訂閱網域依規則分配到目前無法使用的節點，更新請求就會依賴該故障節點，形成自我依賴的問題。建議先切換至已知可用的節點，再手動更新；若訂閱網址支援直連，也可在客戶端允許的範圍內改用直連更新。

不要因此立刻關閉所有代理設定。若訂閱網站只能透過代理連線，強制直連反而會讓問題一再發生。TUN 模式也不保證訂閱請求一定會經過代理，實際路徑仍取決於路由、規則和應用程式本身的請求方式。

3. 本機代理連接埠異常：確認監聽連接埠與設定一致

假設客戶端的混合連接埠設為 7890，外部工具卻仍連線至舊連接埠 7897，就可能發生連線遭拒。這些數字僅供排查參考，實際值應以目前客戶端設定為準，不要將任何連接埠視為所有客戶端的固定預設值。

• 確認是否同時執行兩個代理客戶端，導致預期使用的連接埠被其他程序占用。
• 查看記錄中是否出現 address already in use 或 connection refused。
• 變更連接埠後，也要同步檢查系統代理、瀏覽器代理擴充功能，以及終端機中的 HTTP_PROXY、HTTPS_PROXY 環境變數。

連接埠衝突不一定會阻止訂閱下載；只有更新請求需要使用這個本機代理連接埠時，才會因這條路徑失敗。若記錄已顯示伺服器回傳 403，應繼續檢查網址權限，而不是反覆更換連接埠。

4. 401、403、404 或 429：檢查權限、網址與限流

401 通常與驗證有關，403 可能來自權限限制或網站防護，404 可能表示路徑已失效，429 則表示請求過於頻繁。這些狀態碼都無法單獨證明方案已到期，還需參考服務商帳戶頁面與回應內容判斷。

請在服務商帳戶中重新複製適用於 Clash 或 mihomo 的訂閱網址，並確認訂閱是否已重設、帳戶是否到期、流量是否用完。若回傳 429，請先停止連續重試；若有 Retry-After 提示，請依提示等待，並調長各部裝置的自動更新間隔。

5. 下載成功但解析失敗：檢查回傳格式與核心支援

「解析失敗」和「網路逾時」是不同問題。請確認回傳內容是否為 YAML、是否誤複製網頁分享網址，或是否取得其他客戶端專用的訂閱格式。新協定或新欄位也可能需要較新版的 mihomo 核心；圖形介面能開啟，不代表核心能辨識所有節點類型。

尚未備份前，不要刪除仍可使用的舊設定。請先保留目前設定，再核對下載內容與錯誤行號；檢查 YAML 時，縮排請使用空格並保持同一層級一致，含有特殊字元的 URL 則應加上引號。

修改後的驗證流程與訂閱網址保護

設定完成後，至少驗證一次「手動下載成功」及一次「排程已觸發」。前者可確認網址與目前網路正常，後者才能證明自動更新設定確實生效。不要只看節點數量，因為伺服器可能回傳完全相同的內容。

1. 記下目前的訂閱名稱、更新時間與設定週期，例如 720 分鐘。
2. 手動更新，確認記錄中沒有下載失敗、解析失敗或設定載入失敗。
3. 讓客戶端保持執行，等過一個完整更新週期，再核對更新時間與相關記錄。
4. 若下載成功但節點沒有變更，請確認目前啟用的設定及提供者引用，再檢查伺服器是否確實發布了新內容。
5. 驗證完成後，請保留正常的更新週期，不要讓多部裝置長期使用臨時測試的短間隔。

排查順序可依序進行：確認更新對象與單位 → 手動更新 → 查看錯誤類型 → 檢查請求路徑 → 驗證排程是否觸發。若要確認系統代理、規則模式或 TUN 設定，請參閱故障排除；初次匯入訂閱，請從設定教學開始。