Clash 訂閱更新失敗排解：連結過期、格式不符與自動更新間隔設定

先釐清：訂閱下載失敗，還是設定檔載入失敗

Clash 訂閱更新通常會經過三個步驟：用戶端向訂閱網址發出請求、解析回傳內容，再將有效設定交由核心載入。出現「更新失敗」時，節點不一定已失效；舊設定可能仍在記憶體中正常運作。反過來說，頁面顯示下載成功，也不代表目前使用的核心一定能接受新設定。

先開啟用戶端的「日誌（Logs）」頁面，再前往「設定檔（Profiles）」頁面，更新目標訂閱。不同用戶端可能將此頁命名為「訂閱」，請以實際介面為準。記下操作時間、錯誤關鍵字及訂閱最近更新時間；不要同時刪除設定檔、切換核心或重設網路。

• 請求階段失敗：常見訊息包括 timeout、no such host、403 或 429，優先檢查網址、網路及伺服器回應。
• 解析階段失敗：出現 yaml、unmarshal、invalid config 等關鍵字時，請著重檢查回傳格式與設定內容。
• 載入階段失敗：下載完成後提示不支援某種代理類型，或套用設定失敗，就需要確認核心是否相容。

連結過期或存取受限：從 HTTP 狀態碼著手排查

重新複製訂閱網址，而不是服務商的網頁網址

前往訂閱服務商的帳戶頁面，確認服務期限、流量狀態，以及是否曾執行「重設訂閱連結」。重設後，舊網址中的權杖可能立即失效。複製時請選擇適用於 Clash 或 mihomo 的訂閱入口，避免複製登入頁、帳戶首頁、QR Code 圖片網址，或帶有暫時登入狀態的下載網址。

完整網址通常包含查詢參數。不要任意刪除 ? 後面的內容，也不要把通訊軟體附加的句號、引號或換行一併貼上。若懷疑舊連結已失效，可保留舊訂閱項目，另建一個項目測試新網址；確認能載入後再清除舊項目。

瀏覽器能開啟，不代表用戶端也能更新

瀏覽器可能帶有登入 Cookie、已通過人機驗證，或使用與用戶端不同的代理路徑。用戶端擷取訂閱時通常不會沿用這些瀏覽器狀態。網址在瀏覽器中顯示正常，只能證明瀏覽器當下的請求成功，不能取代用戶端日誌中的結果。

如果服務商要求特定請求標頭或用戶端類型，請使用其文件提供的官方訂閱入口。不要隨意修改 User-Agent 反覆嘗試；這可能改變伺服器輸出的格式，讓原本的存取問題變成格式問題。

格式不相容：分辨完整設定檔、節點清單與核心支援度

訂閱並非單一統一的檔案格式。完整的 Clash YAML 通常包含 proxies、proxy-groups 和 rules；代理集合檔案通常只有 proxies，供 proxy-providers 引用。其他網址則可能回傳分享連結清單或編碼文字，不能假設所有用戶端都能直接將它們當作完整設定檔載入。

依錯誤內容逐項檢查

1. 本文以 HTML 開頭：例如出現 <!DOCTYPE html> 或登入提示，代表取得的是網頁，而不是 YAML。請回頭檢查訂閱入口及存取權限。
2. 提示 YAML 行號：檢查該行附近的縮排、冒號與引號。YAML 縮排必須使用空格，不可使用 Tab；也不要將豐富文字編輯器中的全形標點貼到欄位名稱中。
3. 提示缺少代理群組或參照不存在：檢查規則參照的群組名稱，以及群組中的節點名稱是否存在。只下載節點清單，不會自動補齊所有分流規則。
4. 提示未知的代理類型或欄位：確認實際執行的核心及其版本。用戶端介面版本與核心版本是兩項不同資訊，通常可在「關於」或「核心」設定中查看。

mihomo 延續並擴充了 Clash 設定生態系，但舊版 Clash 核心不支援所有新增協定與選項。如果訂閱明確以 mihomo 為目標，請使用相容的用戶端與核心。保留完整錯誤行，升級前先備份設定；不要只為了消除錯誤訊息就刪除不認識的協定欄位。

更新請求被自身代理攔截：分別測試直連與代理

常見的循環狀況是：用戶端更新訂閱時需要透過目前的代理，但目前節點已無法使用，取得新節點資訊又必須先下載訂閱。此時網頁與訂閱可能都會逾時。另一種情況則相反：訂閱網域在目前網路無法直連，但用戶端更新預設使用直連。

先確認請求是由哪個元件發出。完整遠端設定通常由用戶端管理程式下載；proxy-providers 中的遠端代理集合則由核心管理。用戶端的「透過代理更新」選項不一定會控制核心代理集合的請求。只切換 Rule、Global 或系統代理開關，也不保證更新程序會改走其他路徑。

1. 在目標訂閱的編輯選單或用戶端設定中，尋找「透過代理更新」、「更新代理」等選項；部分用戶端沒有獨立開關，請查閱更新紀錄或說明文件。
2. 如果目前的更新方式是透過代理，先選擇一個已確認可用的節點，再更新一次。若仍失敗，改用直連測試一次。
3. 如果目前的更新方式是直連，且日誌顯示連線至訂閱網域逾時，可改用可用代理測試；也可以暫時切換至手機熱點，比較是否受到目前網路限制。
4. 測試結束後，恢復所需設定並記錄哪條路徑成功。每次只變更一項，避免將網路切換與設定修改混在一起。

連接埠、DNS 與憑證錯誤要分開排查

connection refused 127.0.0.1:7890 表示某個請求嘗試連線至本機 7890 連接埠，但未能成功。請檢查核心是否正在執行，以及實際的 mixed-port 是否仍為 7890。若已改為 7897，相關的更新代理設定也必須同步修改，不能繼續指向舊連接埠。

no such host 通常較接近網域名稱解析問題；若出現 x509 或憑證有效期限錯誤，應先檢查 Windows 的日期、時間與時區，再考慮網路中的 HTTPS 檢查或伺服器憑證異常。不建議關閉憑證驗證來掩蓋問題。遇到連線逾時時，也不要立刻認定是 DNS 故障，應依據日誌判斷卡在解析、連線還是 TLS 交握階段。

自動更新間隔：分開設定用戶端訂閱與代理集合

完整訂閱的排程更新由用戶端管理

開啟「設定檔（Profiles）」或「訂閱」頁面，在目標項目的右鍵選單或更多選單中尋找「編輯」、「編輯資訊」或更新設定，確認是否啟用自動更新，以及間隔的單位。選單名稱會因用戶端而異，不能將某個用戶端的設定路徑視為所有 Clash 用戶端的通用方式。

• 若服務商沒有特別要求，可以先設定每 12 小時更新一次並觀察。介面單位若為分鐘，請輸入 720；若為小時，則輸入 12。
• 每天更新一次相當於 1440 分鐘或 24 小時。不要只看數字大小而忽略單位。
• 不要將 0 視為「立即更新」。它可能代表停用、使用預設值或其他行為，請以該用戶端的說明為準。
• 若用戶端支援讀取伺服器建議的間隔，可優先依照服務商的說明設定；並非所有用戶端都會識別或採用這項建議。

桌面用戶端關閉後，其程序內的排程工作通常不會繼續執行。Windows 進入睡眠期間，也無法像一般執行狀態一樣擷取訂閱。即使核心服務在背景執行，也不代表負責更新完整訂閱的介面程序仍在運作。若需要定時更新，請確認用戶端保持執行，並檢查電腦喚醒或重新啟動後的更新時間。

proxy-providers 的 interval 單位為秒

若使用 mihomo 的遠端代理集合，interval 屬於核心設定，單位為秒。以下範例用來說明欄位之間的關係，並非完整訂閱；範例網域不提供實際服務，使用時必須填入自己的可信網址。

proxy-providers:
  remote-nodes:
    type: http
    url: "https://example.com/nodes.yaml"
    path: ./providers/remote-nodes.yaml
    interval: 86400

此處的 86400 代表 24 小時，43200 代表 12 小時，3600 代表 1 小時。代理集合還必須由代理群組透過 use 引用，回傳內容也須符合代理集合格式。不要將此欄位直接加到 YAML 最上層，並期待它能控制用戶端完整訂閱的更新。

代理集合中的 health-check.interval 用於節點健康檢查，並非下載訂閱的頻率。將健康檢查設為 300 秒，只會影響相關檢查工作，不代表每 5 分鐘重新取得節點清單。若要長期修改，請使用用戶端支援的覆寫或合併功能，避免下次更新訂閱時覆蓋本機調整。

手動強制更新：保留舊設定，再驗證新內容

手動更新適合用來確認連結是否恢復，或在服務商明確通知節點變更後立即取得設定。「強制更新」並非統一的選單名稱：有些用戶端只有「更新」，有些則提供「全部更新」或忽略本機更新週期的操作。這不保證能繞過伺服器快取，也無法修復已失效的權杖。

1. 保留目前狀態：記下目前生效的設定名稱、更新時間與可用節點；必要時將備份匯出至本機受保護的資料夾。
2. 只更新目標項目：在設定檔清單中更新該訂閱一次，避免多個訂閱同時失敗而難以找出原因。
3. 檢查結果：比對日誌時間，確認請求已完成；查看最近更新時間是否改變，以及是否出現解析或核心載入錯誤。
4. 確認設定生效：若用戶端未自動重新載入，請手動選取更新後的設定並套用，再確認代理群組是否存在，以及規則模式是否符合預期。
5. 實際測試：測試一個應直連的網站，以及一個應透過代理連線的目標，並在連線記錄中確認套用的規則與出口。只看節點數量變化並不足夠。

更新時間改變但節點清單沒有變動，可能只是上游內容沒有更新，不一定是快取故障。反覆在網址後加上隨機參數也不是通用解法：帶有簽章的連結可能因此失效。若新設定載入失敗，請保留日誌並切回可用設定，不要不斷刪除整個設定資料夾。

仍無法更新時，請整理以下資訊

向訂閱服務商或用戶端專案回報前，先準備一份精簡的診斷紀錄，通常比只說「無法更新」更有幫助。錯誤訊息請保留原文，但不要公開訂閱網址、授權標頭或節點憑證。

• 執行環境：Windows 版本、用戶端名稱與完整版本號、實際核心名稱與版本號。
• 故障時間：例如於當地時間 09:20 手動更新，並註明時區，方便服務端查詢日誌。
• 錯誤階段：請求失敗、YAML 解析失敗，還是下載成功但套用失敗。
• 測試結果：直連是否成功、使用可用代理是否成功，以及切換至手機熱點後是否仍然失敗。
• 排程設定：是否啟用自動更新、間隔數值及單位，以及故障發生時用戶端是否已關閉或電腦是否進入睡眠。

請依固定順序排查：先確認連結與帳戶狀態，再確認回傳格式，接著比較更新請求的網路路徑，最後檢查排程工作。這樣能區分服務端、用戶端與核心問題，也能避免只因一次暫時的訂閱故障就重設整套 Windows 網路設定。