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

先確認失敗發生在哪一層

Clash 客戶端更新訂閱時，會先存取訂閱網址、接收伺服器回傳的內容，再將內容解析為設定檔。最後才會載入代理節點、規則與 DNS 設定。介面上相同的「更新失敗」，可能代表連線逾時、HTTP 狀態異常、回應內容錯誤或 YAML 解析失敗。

排查時不要先刪除目前的設定。應保留仍可使用的設定副本，再查看更新提示與執行記錄。有些客戶端會將下載錯誤顯示在訂閱卡片旁，另一些則只在記錄中保存完整原因。常見入口是「訂閱」→「設定卡片」→「更新」，記錄入口通常是「設定」→「記錄」或「記錄」→「核心記錄」。

介面或記錄提示	通常對應的環節	優先檢查項目
timeout、deadline exceeded	建立連線或等待回應逾時	網路路徑、系統代理、DNS、伺服器負載
404 Not Found	訂閱路徑不存在	網址是否完整、權杖是否失效、方案是否重設
401 或 403	驗證遭拒	權杖、帳戶狀態、請求頻率與來源限制
unexpected end、EOF	回應中斷或檔案不完整	網路波動、閘道限制、伺服器產生工作
yaml、parse、unmarshal	設定解析失敗	回傳內容格式、縮排、欄位類型與客戶端相容性
更新成功但節點數量為 0	內容有效但沒有可載入的代理	訂閱類型、帳戶可用節點、轉換範本

訂閱下載逾時的逐層排查

第一步：判斷訂閱網域是否可連線

逾時不代表節點失效。訂閱下載與代理節點連線是兩條不同的鏈路：前者存取訂閱服務網域，後者連線至設定中的代理伺服器。即使現有節點可以瀏覽網頁，訂閱網域仍可能因 DNS、路由或伺服器故障而無法連線。

記錄失敗時間，連續手動更新兩次，兩次之間間隔 60 秒，以排除短暫波動。
切換一次網路，例如從家用寬頻切換至手機熱點，再重新更新。
分別測試關閉系統代理與維持目前代理這兩種狀態。有些訂閱網域需要直連，另一些網路環境則需要透過現有代理存取。
檢查裝置日期、時間與時區。時間偏差較大時，TLS 連線可能在下載前終止。
查看記錄中的目標網域與錯誤階段。DNS 查詢逾時與 TCP 連線逾時需要分開處理。

如果關閉系統代理後可以更新，應檢查訂閱網域是否被錯誤分配給不可用節點。可以在規則中為該網域設定直連，也可以在更新期間暫時選擇 DIRECT。若只有開啟代理才能更新，則應保留一份穩定設定作為更新通道，不要在新設定驗證完成前覆蓋它。

第二步：區分 DNS 逾時與連線逾時

記錄出現「no such host」「DNS lookup failed」或指向 DNS 的「i/o timeout」時，先檢查 Clash 的 DNS 模組。使用 mihomo 核心時，也要留意 nameserver、proxy-server-nameserver 與 nameserver-policy 的分工。代理伺服器網域無法解析時，訂閱下載與節點連線都可能受到影響。

暫時關閉 TUN 模式後重試，用來判斷流量是否在 TUN、系統代理與本機 DNS 之間形成迴圈。
確認本機監聽連接埠沒有衝突。常見的 mixed-port 為 7890，HTTP 連接埠常見為 7890，SOCKS 連接埠常見為 7891，實際值以目前設定為準。
若系統中同時執行封包分析工具、另一套代理客戶端或 VPN，先完全退出其中一個，再重新啟動 Clash 核心。
修改 DNS 設定後執行一次核心重新啟動，只切換代理群組通常不會重建所有 DNS 狀態。

第三步：適度調整下載等待時間

客戶端提供訂閱逾時設定時，可將 10 秒暫時提高至 30 秒進行驗證。超過 30 秒仍持續失敗時，繼續增加到數分鐘通常無法解決路徑故障。較合理的測試參數是連線等待 10 秒、總下載時間 30 秒，並允許跟隨 HTTP 重新導向。

桌面系統可以使用命令查看回應狀態。先在終端機執行 read -s SUB_URL 並貼上訂閱網址，按下 Enter 後再執行下列命令。這樣可降低權杖直接留在命令歷史記錄中的風險。

curl -L \
  --connect-timeout 10 \
  --max-time 30 \
  -D headers.txt \
  -o profile.yaml \
  "$SUB_URL"

wc -c profile.yaml
head -n 8 headers.txt

退出碼為 0 只代表下載程序完成，不代表內容一定是 Clash 設定。請繼續檢查 HTTP 狀態、檔案大小與內容類型。正常設定通常至少包含 proxies、proxy-providers、proxy-groups 或 rules 的部分項目。

回傳 404、401 或 403 時如何處理

404：網址路徑或訂閱權杖已變更

404 表示可以連線至伺服器，但目前路徑不存在。最常見原因是複製時遺漏查詢參數、訂閱權杖已重設、舊網址停止提供，或網址中的特殊字元被聊天軟體截斷。不要只比較網域，必須從通訊協定開頭到最後一個字元完整比對。

回到訂閱服務的控制面板，重新複製適用於 Clash 或 Clash Meta 的訂閱網址。
刪除客戶端中的失敗項目後重新貼上，避免舊項目仍引用快取網址。
確認網址前後沒有空格、換行與中文引號。
如果伺服器剛執行權杖重設，舊網址應視為失效，所有裝置都必須更新。
等待 2 至 5 分鐘後再試，部分服務需要重新產生設定或同步邊緣快取。

在瀏覽器開啟網址後顯示下載，不代表客戶端一定會成功。有些服務會依 User-Agent 回傳不同格式，也可能要求特定請求標頭。反過來，瀏覽器顯示網頁也不等於訂閱失效，因為伺服器可能將一般瀏覽器請求導向說明頁面。應以客戶端記錄中的狀態碼與實際回應內容為準。

401 與 403：驗證或存取策略拒絕

401 通常表示權杖無效或缺失，403 則可能表示帳戶狀態、來源位址、存取頻率或伺服器策略不允許目前請求。先登入服務面板確認帳戶與訂閱狀態，再重新產生網址。若短時間內連續點擊更新數十次，伺服器可能觸發流量限制，此時應停止請求 10 至 30 分鐘。

下載成功但內容空白或無法解析

先檢查回傳的是 YAML、Base64 還是 HTML

客戶端收到 HTTP 200 後仍可能更新失敗。伺服器可能回傳登入頁面、錯誤說明、空檔案、通用 Base64 節點清單，或目前客戶端不支援的欄位。若下載檔案只有幾十 bytes，或開頭出現 <!DOCTYPE html>、<html>，表示取得的不是設定檔。

Clash 設定通常採用 YAML。節點可以直接寫在 proxies 下，也可以透過 proxy-providers 引用遠端提供者。只包含其他客戶端格式連結的文字，不能直接當作完整 Clash 設定載入。伺服器面板提供客戶端類型選項時，應選擇與核心相符的 Clash 或 mihomo 格式。

檢查 YAML 縮排與欄位類型

YAML 使用空格表示層級，同一層級不能混用定位字元。常見錯誤包括連接埠被寫成非數字文字、代理群組引用不存在的節點、規則提供者缺少 behavior，以及舊核心無法辨識新欄位。更新客戶端與 mihomo 核心後再次載入，可排除版本過舊造成的相容性問題。

proxy-providers:
  remote-main:
    type: http
    url: "https://sub.example.net/client/REDACTED"
    path: ./providers/remote-main.yaml
    interval: 21600
    health-check:
      enable: true
      interval: 600
      url: "https://www.gstatic.com/generate_204"

上例中的 interval: 21600 表示每 21600 秒更新一次提供者，也就是 6 小時。健康檢查的 interval: 600 表示每 10 分鐘測試一次節點可用性。兩者用途不同：健康檢查不會重新下載訂閱，訂閱更新也不會取代持續進行的節點檢測。

更新成功但節點數量為零

節點為零時，先查看原始回應，確認伺服器是否確實回傳代理項目。帳戶到期、流量用盡、地區篩選結果為空或轉換範本錯誤，都可能產生結構有效但沒有節點的設定。如果設定只包含規則與代理群組，卻沒有 proxies 或可用的 proxy-providers，客戶端無法憑空產生節點。

還要確認代理群組的引用關係。設定中雖已有節點，但代理群組的 use 指向錯誤的 provider 名稱時，介面也可能顯示空群組。名稱區分大小寫，例如 remote-main 與 Remote-Main 應視為不同識別名稱。

自動更新間隔應該設定多久

自動更新不是越頻繁越好。訂閱內容通常不會以分鐘為單位變更，高頻請求會增加伺服器負載，也容易觸發流量限制。對個人裝置而言，6 至 24 小時是較穩定的範圍。暫時等待伺服器修復時，應手動更新一次，而不是將週期改成 60 秒。

使用情境	建議間隔	秒數
節點變動頻繁的日常裝置	6 小時	21600
一般桌上型電腦與手機	12 小時	43200
長期穩定的家用裝置	24 小時	86400
臨時排障	關閉自動重試，依需求手動更新	不適用

圖形客戶端中的設定位置

不同客戶端對「設定」與「訂閱」的命名並不一致。常見操作路徑是「訂閱」→「選擇設定」→「編輯」→「更新間隔」，或「設定」→「訂閱卡片選單」→「自動更新」。有些客戶端以小時填寫，輸入 6 代表 6 小時；另一些以分鐘填寫，6 小時應輸入 360。儲存前務必查看輸入框後方的單位。

Clash Verge Rev 這類 mihomo 圖形客戶端通常會將遠端設定集中在「訂閱」頁面。修改更新間隔後，先儲存訂閱設定，再手動更新一次並觀察更新時間。舊版 Clash for Windows 的選單名稱與新客戶端不同，應在 Profiles 頁面檢查遠端設定項目及其更新選項。若介面沒有間隔設定，不要直接假設背景會自動更新。

mihomo 設定中的兩個 interval

手寫設定時，最容易混淆的是提供者更新週期與健康檢查週期。proxy-providers 項目下的頂層 interval 控制遠端檔案重新下載；巢狀於 health-check 下的 interval 控制連通性測試。前者適合 21600 至 86400 秒，後者通常為 300 至 900 秒。

健康檢查過於頻繁會產生額外連線。擁有大量節點時，每 30 秒檢測一次可能造成瞬間並發與電量消耗。行動裝置可將健康檢查設為 600 秒或更長，並只對實際使用的 provider 開啟。訂閱更新失敗時，調整健康檢查間隔無法解決下載問題。

TUN 模式、系統代理與訂閱更新的關係

開啟 TUN 後，客戶端可以接管更多系統流量，但訂閱請求仍可能由圖形介面程序或核心發起。不同客戶端的實作方式不同，請求不一定遵循目前的代理群組。出現「瀏覽器可以開啟，客戶端更新逾時」時，應重點檢查介面程序是否使用系統代理、訂閱網域是否命中規則，以及 TUN 路由是否形成迴圈。

關閉 TUN，保留系統代理，測試一次更新。
關閉系統代理，只保留 TUN，測試一次更新。
兩者都關閉，讓訂閱請求直連，測試一次更新。
恢復原本設定後重新啟動核心，確認記錄中沒有連接埠佔用或路由安裝失敗。

上述測試每次只變更一個變數。若同時修改 DNS、代理模式、TUN 與訂閱網址，即使更新恢復，也無法判斷真正原因。測試期間可以維持規則模式，並為訂閱網域單獨設定 DIRECT 或指定穩定的代理群組。

一套可重複執行的排查順序

保留舊設定：先匯出仍可使用的設定，不要直接覆蓋。
讀取完整錯誤：記錄狀態碼、目標網域、發生時間與記錄關鍵字。
檢查網址：重新複製訂閱 URL，排除空格、截斷與過期權杖。
切換網路：分別使用目前網路與手機熱點測試。
切換請求路徑：依序測試直連、系統代理與 TUN 狀態。
查看回應：確認 HTTP 狀態、檔案大小以及是否為 YAML 內容。
驗證設定：檢查 proxies、proxy-providers、代理群組引用與 YAML 縮排。
核對核心：更新至客戶端支援的 mihomo 核心版本後重新載入。
設定合理週期：日常使用設為 6、12 或 24 小時，避免以分鐘為單位更新。
最後聯絡伺服器：提供失敗時間、狀態碼與已去識別化的記錄，不要傳送完整訂閱權杖。

更新恢復後還要檢查什麼

訂閱顯示更新成功後，先確認更新時間、節點數量與代理群組是否符合預期，再切換至新設定。選擇一個節點執行延遲測試，接著造訪常用網站驗證規則分流。若節點存在但所有連線都失敗，問題已從「訂閱下載」轉為「節點連線」，應查看連線記錄，而不是繼續重複更新訂閱。

最後將自動更新週期恢復至合理值。排障期間設定的短週期應及時取消，避免背景持續發出請求。桌面客戶端可觀察 24 小時內是否依計畫更新一次；行動系統可能限制背景工作，因此自動更新時間會受省電策略與系統排程影響，必要時開啟客戶端後手動更新。

完整的判斷鏈路是：網址有效、網路可達、回應內容正確、設定能夠解析、代理群組引用有效、節點可以連線。沿著這六步逐層確認，比反覆刪除客戶端或連續點擊更新更容易定位問題。