Clash 訂閱更新失敗怎麼辦：排查失敗原因與設定自動更新間隔

先判斷失敗發生在哪一層

Clash 客戶端中的「更新失敗」不代表單一故障。一次遠端訂閱更新通常會經過網域解析、TCP 與 TLS 連線、HTTP 請求、內容下載、設定解析、核心驗證與設定切換。介面只顯示一則失敗提示時，應先確認具體卡在哪個步驟，而不是連續點擊更新。

最有價值的判斷依據是客戶端日誌、HTTP 狀態碼與下載內容。先記下失敗時間，再開啟日誌頁面，在同一分鐘內尋找包含訂閱網域、timeout、certificate、401、403、404、parse 或 yaml 的項目。不同階段的處理方向並不相同。

觀察結果	故障階段	優先檢查項目
網域解析失敗、找不到主機	DNS	系統 DNS、TUN DNS、網域拼寫與本機網路
連線逾時或連線遭重設	網路連線	直連可達性、代理路徑、防火牆與 IPv6
HTTP 401、403、404 或 410	伺服器回應	權杖、訂閱有效期限、存取頻率與連結是否完整
下載成功但顯示 YAML 錯誤	設定解析	回傳內容、縮排、欄位相容性與核心版本
顯示更新成功但節點沒有變化	設定切換	目前啟用的設定、快取、重新載入狀態與舊連線

連結過期、請求遭封鎖與伺服器回應異常

確認連結在複製時沒有損壞

訂閱網址可能因換行、結尾空格、聊天軟體截斷或 HTML 轉義而失效。常見情況是網址只複製到第一個 & 之前，或結尾權杖少了幾個字元。應從訂閱服務的管理頁面重新複製完整 URL，再覆蓋客戶端中的舊網址，不要手動拼接權杖。

HTTP 狀態碼可以快速縮小範圍。401 通常表示憑證或權杖已失效；403 可能與存取政策、頻率限制或來源網路有關；404 表示路徑不存在；410 通常用於明確告知資源已失效；429 表示短時間內請求過多。遇到 429 後持續高頻重新整理，通常只會延長限制時間。

在終端機單獨測試 HTTP 請求

桌面系統可以使用 curl，將網路下載與客戶端解析分開測試。先將訂閱網址儲存到目前終端機的環境變數，再執行以下指令。指令會設定 10 秒連線逾時、30 秒總逾時，並跟隨 HTTP 重新導向。

export SUB_URL='完整訂閱網址'
curl -L \
  --connect-timeout 10 \
  --max-time 30 \
  -D response-headers.txt \
  -o profile.yaml \
  "$SUB_URL"

檢查 response-headers.txt 中的最終狀態碼，再查看 profile.yaml 的開頭。標準 Clash 或 Mihomo 設定通常會看到 proxies:、proxy-groups:、rules: 等 YAML 欄位。若內容以 <html 開頭，實際下載到的是登入頁、驗證頁或錯誤頁；若回傳 JSON 錯誤物件，也不能直接作為設定匯入。

有些服務會回傳 Base64 編碼的通用訂閱，而客戶端入口只接受 Clash YAML。此時網路請求雖然成功，解析仍會失敗。應在服務端選擇 Clash、Clash Meta 或 Mihomo 對應格式，而不是只修改檔案副檔名。

檢查系統時間與 TLS 連線

裝置時間偏差會影響 HTTPS 憑證驗證。若日誌出現 certificate has expired、not yet valid 或握手失敗，請先啟用系統自動校時。Windows 可在「設定」→「時間與語言」→「日期與時間」中開啟自動設定時間；macOS 可在「系統設定」→「一般」→「日期與時間」中開啟自動設定。

如果瀏覽器可以開啟訂閱網址，而客戶端始終逾時，還要比較兩者使用的網路路徑。瀏覽器可能正在使用系統代理，但客戶端更新器卻採用直連；也可能正好相反。這種差異是「瀏覽器能開、Clash 更新失敗」的常見原因。

代理迴圈、TUN 模式與 DNS 路徑排查

訂閱更新請求需要一條可用的啟動路徑。如果更新器依賴目前代理，而目前設定中的節點已全部失效，就會形成啟動依賴：必須先更新才能恢復節點，但更新請求又必須經過這些節點。另一種迴圈則是客戶端程序發出的請求被系統代理或 TUN 再次送回自身，日誌可能連續出現相同網域的連線、連線遭拒或逾時。

使用直連測試打破啟動依賴

記錄目前設定與模式，暫時關閉 TUN 模式。
關閉系統代理，確認瀏覽器或終端機可以直接存取一般網站。
在客戶端中對目標訂閱執行一次手動更新。
更新成功後重新啟用系統代理或 TUN，並還原原有規則模式。

如果訂閱網域必須透過代理才能存取，就需要保留一條已知可用的啟動線路。可以先切換到仍可連線的本機設定，再更新遠端設定。不要刪除最後一份可用設定後才測試遠端訂閱。

核對本機連接埠與系統代理

常見桌面設定會將 HTTP 或 mixed 監聽連接埠設為 7890，舊式分離設定可能使用 HTTP 7890 與 SOCKS 7891，外部控制連接埠常見為 9090。這些數值可以修改，因此應以目前客戶端「設定」或「連接埠」頁面顯示的實際值為準。

若系統代理指向 127.0.0.1:7890，但核心沒有執行，或 mixed-port 已改用其他數值，所有經過系統代理的更新請求都會失敗。請先確認核心狀態為執行中，再檢查連接埠是否正在監聽。連接埠衝突日誌通常包含 address already in use。

確認訂閱網域的 DNS 結果

啟用 TUN 與 fake-ip 後，應用程式看到的位址可能來自 fake-ip 位址池，這是正常的轉送機制；但客戶端本身的更新器仍需完成真實網域解析。若日誌顯示 DNS 逾時，可暫時關閉 TUN 後再次測試，以區分系統 DNS 與 Mihomo DNS 路徑。

還應檢查 IPv6。部分網路可以回傳 AAAA 記錄，卻沒有穩定的 IPv6 出口，表現為先等待約 10 至 30 秒後才逾時。可在系統層級暫時停用該網路介面的 IPv6，或調整客戶端 DNS 與連線策略後再次測試。只有在測試結果明確指向 IPv6 時，才建議長期修改，避免同時掩蓋其他故障。

下載成功但解析失敗的處理順序

當日誌已出現 HTTP 200，問題重點應從網路轉向內容。先檢查下載檔案是否為預期設定，再檢查 YAML 語法，最後確認欄位是否受目前核心支援。將三個階段混在一起處理，容易反覆修改 DNS 與代理設定，卻始終沒有處理解析錯誤。

先驗證 YAML 基本結構

YAML 對縮排十分敏感，Tab 字元、清單層級錯誤、未閉合引號都可能導致設定拒絕載入。使用 Mihomo 命令列時，可以在不啟動代理監聽的情況下測試設定：

mihomo -t -f profile.yaml

測試通過通常會顯示設定驗證成功的訊息；失敗時會指出欄位或行號。若設定由遠端訂閱自動產生，不建議直接在本機修補每次都會被覆蓋的檔案，應回到訂閱格式設定或轉換規則中處理。

區分完整設定與代理提供者

完整遠端設定通常包含連接埠、DNS、代理群組與規則，可直接作為客戶端設定啟用。proxy-providers 則是在主設定中引用獨立的節點集合，兩者的更新機制不同。將只含節點清單的 provider 檔案直接當作完整設定匯入，可能缺少 proxy-groups 和 rules；反過來，將完整設定填入 provider 網址，也會因結構不符而失敗。

在 Mihomo 設定中，provider 的 interval 單位是秒。例如下面的 21600 代表每 6 小時檢查一次。它只控制該 provider，不等同於圖形客戶端為整份遠端設定設定的更新間隔。

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

欄位相容性需要配合核心版本

訂閱服務可能新增 Mihomo 欄位，而客戶端仍使用較舊核心；也可能輸出舊版 Clash 欄位，與目前的嚴格驗證規則不一致。請先在客戶端的「關於」或「核心」頁面確認實際 Mihomo 版本，再查看解析日誌指出的欄位。更新圖形介面不一定會同步更新核心，完成後應再次確認核心版本號。

如果舊設定可以載入，而新設定從某天起全部報錯，應優先比較服務端產生的格式是否發生變化。若只有一個節點導致整份設定失敗，可根據日誌找出該節點使用的協定與欄位，再請訂閱服務重新產生相容格式。

各客戶端的自動更新間隔怎麼設定

不同客戶端對「自動更新」的命名略有差異。以下路徑依照 Clash Verge Rev 2.3.x、Clash Meta for Android 2.11.x 與 FlClash 0.8.x 的常見介面整理；小版本調整後，按鈕位置可能改變，但設定對象都應是遠端設定本身，而不是節點健康檢查。

客戶端	設定路徑	常用間隔
Clash Verge Rev 2.3.x	「訂閱」→目標設定卡片→「編輯」→「自動更新間隔」	720 或 1440 分鐘
Clash Meta for Android 2.11.x	「設定」→目標遠端設定右側選單→「編輯」→「自動更新」	12 或 24 小時
FlClash 0.8.x	「設定」→目標遠端設定→「編輯」→「自動更新間隔」	720 或 1440 分鐘
Mihomo proxy-provider	主設定→`proxy-providers`→目標 provider→`interval`	21600 或 43200 秒

日常使用建議設定為 12 至 24 小時

節點與規則變更不頻繁時，每 1440 分鐘更新一次已足以應付日常需求，也能減少伺服器請求。服務商每天多次調整節點時，可改為每 720 分鐘更新一次。只有明確需要快速同步時，才建議使用 360 分鐘；設定為 5 分鐘或 10 分鐘通常沒有必要，還可能觸發 HTTP 429。

行動裝置還會受到系統背景策略影響。Android 的省電限制可能暫停背景工作，iOS 也不保證客戶端在退出後能依分鐘準時執行。因此「設定為 12 小時」表示客戶端獲得執行機會時會依該週期檢查，不代表系統一定會在準確時間喚醒應用程式。重要更新應在前景開啟客戶端後手動執行一次。

不要混淆訂閱更新與健康檢查

訂閱更新負責下載節點、策略群組與規則內容；健康檢查則會向測試 URL 發送請求，判斷現有節點是否可用。將健康檢查設為 600 秒，不會每 10 分鐘下載一次訂閱。反過來，訂閱每天更新一次，也不妨礙節點每 10 分鐘進行一次可用性檢測。

對於包含 100 個節點的 provider，過短的健康檢查週期會產生大量並行請求。可以從 600 秒或 900 秒開始，再依裝置耗電量與節點數量調整。延遲測試 URL 應回傳輕量回應，且必須能代表實際出口的連線能力。

手動強制更新的正確步驟

強制更新的目標是取得一份新設定並確認已載入，而不是只看到進度圖示轉動。以下順序可以同時避免並行請求、快取誤判與舊連線干擾。

開啟客戶端日誌，記錄目前設定名稱、更新時間與核心狀態。
停止正在進行的重複更新，只點擊目標設定的更新按鈕一次。
等待請求完成，確認日誌中的最終 HTTP 狀態與解析結果。
檢查設定卡片的更新時間是否改變，以及節點數量或策略群組是否符合預期。
明確選取新設定，並執行「重新載入設定」或重新啟動核心。
重新選取策略群組節點，關閉需要驗證的應用程式連線後再重新開啟。
造訪連線測試頁面或查看連線日誌，確認新連線符合預期規則並使用預期出口。

如果更新成功但節點清單沒有變化，請先比較服務端內容是否真的改變。HTTP 快取可能回傳 304 Not Modified，表示客戶端持有的版本仍被視為有效，並不是網路失敗。若服務端已變更但客戶端持續使用舊內容，可刪除該遠端設定後重新匯入；操作前應保存本機覆寫內容、策略群組選擇與自訂規則。

切換設定不會自動遷移所有現有的 TCP 或 UDP 工作階段。瀏覽器長連線、下載工作與即時通訊連線可能繼續使用原本的出口。驗證時應關閉對應應用程式的連線，必要時重新啟動應用程式，而不是只重新整理同一條長連線。

仍然失敗時應保留哪些診斷資訊

經過上述排查仍無法更新時，應整理一份最小診斷紀錄：客戶端名稱與版本、Mihomo 核心版本、作業系統版本、失敗時間、HTTP 狀態碼、錯誤日誌前後各 10 行、是否開啟 TUN、系統代理位址、監聽連接埠，以及直連與代理兩種路徑的測試結果。

訂閱網址只保留網域，權杖與查詢參數應予遮蓋。也要檢查設定檔是否包含驗證資訊。若問題只在特定網路出現，可補充家用寬頻、行動數據或公司網路的對照結果；若切換網路後立即恢復，排查重點應放在 DNS、IPv6、存取政策與本機閘道，而不是反覆重新安裝客戶端。

完整的診斷順序可以概括為：先看日誌確認階段，再測試 URL 可達性，接著檢查回傳內容與 YAML，最後處理核心相容性、自動更新間隔與設定重新載入。這個順序能將「訂閱失效」「下載失敗」「解析失敗」與「設定未切換」區分為不同問題，減少不必要的修改。