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

先確認問題出在哪個環節

Clash 更新訂閱不只是下載檔案。用戶端會先向訂閱網址發出請求，再解析回應內容，接著儲存設定檔或節點清單，最後交由核心載入。任何一步出錯，介面都可能只顯示「更新失敗」。先記下完整錯誤訊息、更新時間和目前設定檔名稱，比反覆按下更新更有助於排查。

訂閱也分成兩種：圖形用戶端管理的遠端完整設定檔，以及 mihomo 設定中由 proxy-providers 管理的節點提供者。前者的更新週期通常由用戶端儲存；後者則使用提供者內的 interval 欄位。兩者使用不同的計時器，修改其中一項不會連帶變更另一項。

連結失效或伺服器拒絕請求：先檢查狀態碼

重新複製連結，不要手動拼接參數

登入訂閱服務的帳戶後台，確認方案、流量與有效期限，再複製適用於 Clash 或 Clash Meta 的訂閱網址。重設訂閱權杖後，舊連結可能立即失效；若用戶端仍保存舊網址，自動更新只會一再失敗。複製時請檢查前後空白、換行，以及通訊軟體是否截斷 & 之後的參數。

403 不一定代表方案已過期，也可能是存取政策、要求標頭限制或防護頁面所致。200 也不保證訂閱正常：登入頁、驗證頁和錯誤提示頁都可能回傳成功狀態。判斷時必須檢查回應本文，不能只看瀏覽器是否能開啟網址。

使用 curl 區分 HTTP 錯誤與連線錯誤

以下指令請在 Bash 中執行，並確認已安裝 curl。網址會透過隱藏輸入讀取，避免直接寫入 shell 歷史記錄。輸出檔案僅供本機檢查，可能含有節點憑證；操作完畢後請刪除。這裡的 20 秒是本次診斷的逾時上限，不是用戶端預設值。

umask 077
read -r -s -p '訂閱網址：' SUB_URL
printf '\n'
curl --noproxy '*' --location \
  --connect-timeout 10 --max-time 20 \
  --output subscription-response.txt \
  --write-out 'HTTP=%{http_code}\nTYPE=%{content_type}\n' \
  "$SUB_URL"

HTTP=000 不是伺服器狀態碼，通常表示未取得有效的 HTTP 回應；請搭配 curl 錯誤訊息判斷是否為 DNS、連線或憑證問題。隱藏輸入也不代表秘密完全受到保護：執行期間，網址仍可能出現在本機程序參數中，請勿在不受信任的共用主機上執行。

• 若回傳 301 或 302，請確認最終導向的目標不是登入頁；上方的 --location 會跟隨重新導向。
• 若回傳 429，請優先遵守 Retry-After 的指示，不要每分鐘嘗試更新來恢復服務。
• 若出現憑證錯誤，請檢查系統時間與憑證鏈，不要長期以略過 TLS 驗證作為解決方式。

網路遭到阻擋，或更新請求未經代理

瀏覽器能開啟訂閱網址，不代表用戶端的更新程式也能連線。瀏覽器可能經由系統代理連線，更新程式卻可能直接連網；反過來說，啟用 TUN 或透明閘道時，標示為「直連」的請求也可能在網路層被接管。因此，以下對照只能判斷 curl 是否明確使用 HTTP 代理，不能只憑指令名稱就認定底層流量完全未經 TUN。

測試並比較本機代理連接埠

先在用戶端確認 HTTP 或 mixed 監聽連接埠。以下範例使用 127.0.0.1:7890，僅適用於本機確實在該連接埠監聽的情況。若設定為 mixed-port: 7897，請將指令中的連接埠改為 7897。

curl --noproxy '' --proxy http://127.0.0.1:7890 \
  --location --connect-timeout 10 --max-time 20 \
  --output subscription-via-proxy.txt \
  --write-out 'HTTP=%{http_code}\nTYPE=%{content_type}\n' \
  "$SUB_URL"

unset SUB_URL

明確使用代理後請求成功，而前一次請求失敗，表示網路路徑值得優先檢查，但還不能證明圖形用戶端使用相同路徑。回到用戶端啟用訂閱更新相關記錄，手動重新整理一次，查看是否出現對應請求；接著核對該請求使用的代理、策略組與錯誤訊息。部分用戶端使用獨立於核心的下載器，即使連線面板沒有記錄，也不能直接認定請求未送出。

避免訂閱更新形成循環依賴

• 如果只有訂閱中的節點能連上訂閱網域，而這些節點又全數失效，啟用「更新時使用代理」也無法恢復連線。此時需要可用的備援路徑，或請服務商提供可連線的入口。
• 如果記錄顯示訂閱網域符合 DIRECT，而且已確認直連失敗，請先釐清網路需求，再調整規則並檢查實際命中結果。
• 如果錯誤是網域解析失敗，請先核對訂閱主機名稱與 DNS 記錄。不要同時變更 DNS、TUN、規則和連接埠，否則難以判斷是哪項設定生效。
• 若只在特定 Wi-Fi 網路下失敗，可改用行動網路進行一次比較，協助找出網路環境差異；不必一開始就重新安裝用戶端。

格式不相容：下載成功後仍須驗證

訂閱介面可能回傳完整 YAML、僅含節點的 YAML、編碼後的分享連結清單，或其他用戶端專用格式。圖形用戶端是否會自動轉換，取決於實際實作方式。mihomo 的 HTTP 節點提供者與完整設定檔載入器也有不同的輸入格式要求，不能不加區分地將同一份回應放入任意位置。

依據回應內容檢查結構

1. 使用本機文字編輯器開啟回應檔案。如果開頭是 <!doctype html> 或登入頁面文字，問題仍在下載或驗證階段，與 YAML 縮排無關。
2. 完整設定檔通常包含 proxies、proxy-groups、rules 等欄位；原生 YAML 節點提供者通常以 proxies: 描述節點清單。實際欄位組合仍須依用途判斷。
3. 檢查 proxy-groups、rules 引用的名稱是否存在。即使節點下載成功，策略組引用的名稱不存在，設定檔仍可能無法正常使用。
4. 如果服務商提供 Clash 與 Clash Meta 兩種輸出格式，請依目前使用的核心選擇。舊版 Clash 核心不一定支援 mihomo 的新欄位或通訊協定。

若本機已安裝 mihomo，可使用完整設定檔副本檢查語法與設定。以下假設檔案已儲存為目前目錄中的 config.yaml；節點提供者檔案不能直接當成完整設定檔驗證。若設定涉及外部檔案，也要確認工作目錄和相依路徑正確。

mihomo -v
mihomo -t -d . -f ./config.yaml

-v 用來記錄實際核心版本，方便確認欄位支援情況；通過 -t 檢查，也不代表每個節點都能連線。請先保存完整錯誤訊息與核心版本，再進一步排查；不要直接刪除所有不認識的欄位來強行載入。若確實需要轉換格式，請使用可信且受控的方式，避免將完整訂閱權杖提交給來路不明的轉換網站。

在哪裡設定用戶端的自動更新間隔

自動更新屬於用戶端介面功能，不同版本的名稱與位置可能有所調整。先到「關於」頁面記下用戶端版本，再開啟目標訂閱的編輯視窗。不要把「節點延遲測試間隔」當成訂閱下載週期，也別將「更新所有訂閱」誤認為已啟用排程工作。

在 Clash Verge Rev 中，可先於訂閱編輯視窗尋找「更新間隔」和「使用代理」等欄位。若該版本將更新方式放在卡片選單中，請從選單執行相應的代理更新操作。手動使用代理更新成功，不一定表示之後的排程更新也會沿用相同模式；請重新開啟設定，確認變更已儲存。

Clash for Windows 與 Clash for Android 都已停止維護，介面項目會依各版本有所不同。如果目前介面沒有代理更新開關，請勿照抄其他用戶端的選單路徑。應查看記錄確認更新請求實際使用的路徑，或改用仍受維護且支援現有設定的用戶端。

依照介面顯示的單位輸入週期

一般可先設定為 6 或 12 小時，再依服務商限制調整。若介面標示單位為「分鐘」，6 小時請輸入 360，12 小時輸入 720；若標示為「小時」，則分別輸入 6 和 12。不要只看輸入框中的數字來判斷單位。儲存後手動更新一次，並確認「上次更新」時間是否變更。

行動裝置還會受到背景執行、電池最佳化與系統休眠限制。排程更新通常無法保證在螢幕鎖定後精確到秒執行；桌面用戶端完全結束後，通常也不會繼續執行自己的排程工作。如果只有重新開啟應用程式後才會更新，應先排查應用程式的生命週期，而不是繼續縮短更新週期。

mihomo 的 interval 與代理更新欄位

對 HTTP 類型的 proxy-providers 而言，interval 的單位是秒。例如 21600 代表 6 小時，43200 代表 12 小時，86400 代表 24 小時。這是節點提供者的下載週期，不是遠端完整設定檔的自動更新設定。

在支援相關欄位的 mihomo 版本中，可透過提供者的 proxy 指定下載時使用的出口代理或策略組。以下僅示範可合併至現有 HTTP 提供者的欄位，並非完整設定檔；請保留原有的 url、path 與提供者名稱。PROXY 必須是設定檔中已存在且目前可用的出口名稱。

interval: 21600
proxy: PROXY
health-check:
  enable: true
  url: https://www.gstatic.com/generate_204
  interval: 600

此處的 health-check.interval: 600 表示每 600 秒執行一次健康檢查，不代表每 10 分鐘下載訂閱。健康檢查網址應依網路可連通性和使用需求選擇；範例中的網址是連線測試目標，不是訂閱網址。

從命令列執行 mihomo，不會因為在設定檔頂層新增 interval，就定時重新下載整份設定檔。若確實需要更新完整設定檔，應交由受控的外部工作負責下載、驗證、備份與重新載入；失敗時保留原檔。不要直接以網路回應覆寫正在使用的設定檔。

更新後看不出變化？依序確認這六項

1. 確認更新的目標。檢查卡片名稱和訂閱網址來源，避免更新了備用訂閱，實際使用的卻是另一份設定檔。
2. 確認時間與內容。更新時間變更只代表用戶端記錄了更新操作；伺服器也可能回傳相同內容。節點數量沒有變化，不能單獨作為更新失敗的證據。
3. 確認新設定檔已載入。有些用戶端會將「下載」與「啟用」分開處理，請選取該設定檔或檢查重新載入記錄。
4. 確認節點清單來源。如果策略組只引用本機固定節點，遠端提供者更新後，該組不一定會出現新節點。請檢查 use 與提供者名稱。
5. 確認篩選條件。地區篩選、正規表示式或排除規則可能會隱藏新節點，請先核對提供者回傳的原始節點數量。
6. 確認排程工作仍在執行。重新啟動用戶端後，檢查更新間隔是否保留，並在下次執行後查看更新時間記錄。

完成排查後，請刪除診斷時儲存的回應檔案，避免檔案留在同步目錄或共用資料夾中。若仍需向維護者回報，提供用戶端版本、核心版本、錯誤時間、HTTP 狀態碼及已遮蔽敏感資訊的錯誤訊息即可；請勿公開附上訂閱權杖、節點密碼或完整回應內容。

rm -f subscription-response.txt subscription-via-proxy.txt

建議依序處理：確認連結有效 → 比較請求路徑 → 檢查回應格式 → 驗證設定檔載入 → 設定合適的更新週期。自動更新只能減少手動操作，無法修復失效權杖、錯誤格式或無法連線的下載路徑。