Clash 訂閱更新失敗原因與自動更新間隔設定

保留可用設定，再手動更新一次

Clash 訂閱更新失敗，不代表目前使用的節點立刻失效。用戶端通常會繼續使用上次成功下載的設定；若舊節點仍可連線，可以先維持連線，再排查更新問題。別一開始就刪除訂閱、清空設定資料夾或反覆重新安裝，以免連同仍能連線的舊設定一起移除。

前往「設定」或「Profiles」，確認目前啟用的訂閱名稱，並記下最近更新時間。
使用用戶端的匯出或備份功能，保存現有設定。檔案可能包含節點密碼與訂閱權杖，請只保存在可信任的裝置上。
對目標訂閱執行一次「更新」，接著開啟「記錄」，記下完整錯誤訊息、發生時間及 HTTP 狀態碼。
確認失敗的是整份訂閱，還是設定中的某個 proxy-providers。兩者使用的下載器和更新週期可能不同。

根據錯誤訊息找出問題環節

先確認下載時是否收到回應，再檢查回應內容能否解析。用戶端可能會將下方提示轉成中文，判斷時請以記錄中的底層錯誤為準。別只憑單一狀態碼就認定帳戶到期，也要查看訂閱服務後台及回應內容。

記錄或現象	優先檢查項目	接下來怎麼做
`401 / 403`	權杖、存取限制、帳戶狀態	登入服務後台重新複製專用訂閱網址，確認是否需要指定用戶端類型。
`404 / 410`	舊版 API、已撤銷的連結	確認服務商目前提供的入口，不要憑猜測修改 URL 路徑。
`429`	請求過於頻繁	暫停連續重試；若回應標頭中有 `Retry-After`，請依指示等待。
`500 / 502 / 503`	伺服器或閘道器異常	保留舊設定，稍後再試並查看服務公告。
`no such host`	訂閱網域解析	檢查目前使用的 DNS、網域拼字及所在網路。
`timeout / deadline exceeded`	路由、代理出口、回應速度	分別測試直連與透過可用代理更新。
`x509` 或 TLS 錯誤	系統時間、憑證鏈、網路攔截	同步系統時間，並排查認證入口頁及 HTTPS 檢查軟體。
YAML 解析失敗	回應類型與設定相容性	確認下載內容是否為 HTML、節點清單或不相容的設定。

HTTP 200 只代表伺服器有回傳內容，不表示內容就是可用的 Clash 設定。有些認證入口頁會回傳登入網頁，有些 API 則會將錯誤訊息放在 JSON 中，接著用戶端才會回報 YAML 或欄位型別錯誤。

連結過期或權杖失效時的處理方式

重新複製完整 URL，別手動拼接參數

從訂閱服務後台複製「Clash」或「Clash Meta / mihomo」對應的訂閱網址，再取代原設定中的遠端網址。帳戶到期、重設訂閱權杖或訂閱網域遷移，都可能導致舊網址失效。QR Code 只是傳遞 URL 的另一種方式，掃描匯入並不會略過權杖驗證。

檢查連結開頭或結尾是否混入空格、換行或全形標點。從通訊軟體複製的 & 也可能破壞原有參數。
不要把網頁管理介面的網址當成訂閱網址。能在瀏覽器登入的頁面，不一定能讓用戶端下載設定。
若新舊連結的權杖不同，先在一台裝置上測試，再同步到其他裝置；頻繁重設會讓所有舊裝置一併失效。
不要將完整訂閱 URL 貼到公開截圖、線上轉換工具或討論區。排查時保留網域與錯誤類型即可，請遮蔽路徑中的憑證及查詢參數。

403 也可能是伺服器端防護或用戶端識別限制所致。若後台確認帳戶有效，請查看服務商提供的用戶端相容說明，不要一直更換 DNS。DNS 無法修復已遭伺服器拒絕的存取權限。

直連失敗時，如何選擇透過代理更新

先確認用戶端的訂閱下載器使用哪一條網路路徑。瀏覽器透過系統代理成功存取，不代表用戶端在背景下載時也會走相同代理；有些用戶端提供獨立的「透過代理更新」選項，有些則使用自己的網路堆疊。TUN 模式可以接管更多流量，但不保證所有背景更新請求都會經過指定節點。

以兩次可控測試取代連續重試

維持目前可用的節點，手動更新一次並記下是否逾時。
若用戶端提供「透過代理更新」選項，切換後再試一次；若沒有此選項，請查閱該用戶端的說明，不要直接假設系統代理一定有效。
若只有代理路徑成功，就保留此更新方式；若只有直連成功，請檢查所選出口是否受到訂閱服務限制。
若兩種路徑都失敗，再檢查網域解析、伺服器狀態及本機防火牆，避免繼續盲目切換節點。

桌面版也可以使用 curl 交叉測試。以下指令會在本機互動式輸入網址，避免將權杖直接寫入指令歷程。輸出檔案同樣含有敏感資訊，檢查後請刪除。此範例僅適用於具備 Bash 和 curl 的環境。

read -r -s -p '請輸入訂閱 URL：' SUB_URL
printf '\n'
curl --noproxy '*' --connect-timeout 10 --max-time 30 \
  -D subscription.headers -o subscription.body "$SUB_URL"
unset SUB_URL

這裡的 10 秒是連線逾時時間，30 秒是整個請求的時間上限，並非實測延遲。--noproxy '*' 會略過 curl 的代理設定，但無法略過系統路由或已啟用的 TUN。若要測試真正不經 TUN 的路徑，請先記下目前設定，再暫時關閉 TUN 進行測試。

若要用 curl 指定本機代理，請參考用戶端顯示的 HTTP 或混合連接埠。例如實際監聽位址為 127.0.0.1:7890 時，才使用 --proxy http://127.0.0.1:7890。不要將控制介面連接埠當成代理連接埠；不同設定的監聽值可能不同。

憑證錯誤與格式不相容

遇到 TLS 錯誤，先檢查系統時間

若出現 certificate has expired、certificate is not yet valid 或 unknown authority，請先開啟系統的日期與時間設定，並啟用自動校時。接著確認公共 Wi-Fi 是否需要網頁認證，並檢查安全軟體是否會攔截 HTTPS 連線並進行中間解密。

若只有某個訂閱網域持續出現憑證錯誤，而其他 HTTPS 服務正常，請聯絡服務商檢查憑證有效期限及中繼憑證鏈。節點設定中的 skip-cert-verify 不是通用的訂閱下載修復選項，無法解決訂閱伺服器的憑證問題，也不建議為了排查問題而長期關閉憑證驗證。

取得內容後，再判斷格式

完整 Clash YAML：通常包含 proxies、proxy-groups、rules，也可能透過 providers 引用外部資源，應交由相容的用戶端載入。
Base64 節點清單：解碼後可能是多行通訊協定連結，不等於完整的 Clash 設定。建議優先在服務後台選擇相應格式。
Provider YAML：通常只包含 proxies 節點集合，適合放在 proxy-providers 中，不應直接當成完整的分流設定使用。
HTML 或 JSON 錯誤回應：先處理登入、權限或閘道器問題，調整 YAML 縮排沒有幫助。

Clash 是用戶端與核心生態的統稱，Clash Meta 後續以 mihomo 名稱持續維護。舊版核心不一定支援新通訊協定與新欄位。若記錄明確指出不支援的代理類型，請確認實際執行的核心及服務商的相容性要求，不要只看桌面程式名稱。手動修改前請先備份；YAML 縮排請使用空格，不要使用 Tab。

各用戶端的自動更新間隔設定位置

整份遠端設定的定時更新通常由圖形介面用戶端負責，沒有通用的頂層 interval 可以控制所有用戶端的訂閱。請先開啟個別訂閱的編輯面板，再確認欄位標示的單位。下表列出常見操作路徑；不同版本的中文翻譯、按鈕位置與欄位名稱可能不同，請以目前安裝版本的實際介面為準。

用戶端	常見操作路徑	注意事項
Clash Verge Rev	「設定」→目標遠端設定的右鍵選單或更多選單→「編輯資訊」→「更新間隔」	修改的是該設定項目的更新週期；請確認介面標示的單位並儲存。
Clash for Windows	「Profiles」→對遠端設定按右鍵→「Settings」→「Update Interval」	此專案已停止維護；舊版介面與相容性各有差異，請先保留設定，再考慮遷移。
Clash for Android	「設定」→開啟目標遠端設定的編輯介面→「自動更新」或更新間隔欄位	此舊專案已停止維護；背景更新也會受到系統電池限制及應用程式背景權限影響。
其他 mihomo 圖形介面用戶端	「設定／訂閱」→目標項目的「編輯」或「設定」	若只有手動更新按鈕，別假設用戶端支援定時更新，請確認該版本是否具備此功能。

如何選擇更新週期

一般節點訂閱可先設定為每 6 小時更新一次，也就是依欄位單位填入 360 分鐘或 21600 秒。這只是建議的起始值，並非所有服務都適用。若服務商明確規定最低更新間隔，請依其規定設定；節點數較少且長期穩定的訂閱，則可調整為每 12 或 24 小時更新一次。

不要把間隔設為 1 分鐘來「修復」更新失敗。權限、憑證和格式錯誤不會因為頻繁請求而自行消失，反而可能觸發 429。0 的意義也不盡相同：有些用戶端代表停用自動更新，有些則可能恢復預設值，請查看欄位說明。

mihomo Provider 更新是另一個層級

若整份設定已成功下載，但節點集合仍未更新，請檢查 proxy-providers。mihomo 的 HTTP provider 支援以秒為單位設定 interval，由核心下載外部節點檔案；這與圖形介面用戶端更新整份訂閱是兩回事。

以下僅示範適合加入現有設定的本機 provider 片段；檔案必須事先存在，且包含有效的節點集合。此設定不會執行遠端更新，不能只加上 interval 就變成 HTTP 訂閱：

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml

現有的 HTTP provider 應保留實際的 url 及其他必要欄位，並在該 provider 中設定 interval: 21600，代表每 6 小時更新一次節點檔案。不要把這行寫入 rules，也不要放在設定最外層，期待它能自動更新整份訂閱。

proxy-providers.名稱.interval：控制該 HTTP 節點集合的下載週期，單位為秒。
health-check.interval：控制 provider 節點的健康檢查週期，不會下載新節點。
rule-providers.名稱.interval：用於更新相應的 HTTP 規則集合，不負責更新節點清單。

下次更新遠端訂閱時，可能會覆蓋手動修改的 provider 設定。若要長期保留，請使用用戶端支援的覆寫、合併或擴充設定功能，並檢查最終生效的設定。只在編輯器中成功儲存，並不足以證明執行中的核心已套用新值。

更新恢復後的確認步驟

檢查下載結果：確認最近更新時間已變更，且記錄中沒有新的 HTTP、TLS 或解析錯誤。
檢查設定啟用狀態：確認目前選取的是剛更新的設定，而不是同名的本機副本。
檢查策略群組：查看節點是否有變化；若原先選取的節點已移除，請重新選擇可用的出口。
檢查實際連線：開啟需要代理的目標服務，在連線記錄中確認規則與出口。訂閱更新成功，不代表流量已依預期分流。
檢查下一個週期：記下目前時間與更新間隔，等下一個週期後查看時間戳，確認排程確實有執行。

最後請保留一條可用的復原途徑：備份目前設定、記下訂閱入口，並確認手動更新的位置。若問題仍未解決，請向服務商或用戶端維護者提供已遮蔽敏感資訊的記錄、用戶端與核心版本、錯誤發生時間，以及直連和代理測試結果。請勿提交完整訂閱網址或含有憑證的設定檔。