入門指南 預計閱讀 12 分鐘

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

逐步排查訂閱抓取失敗的常見原因：連結過期、User-Agent 遭封鎖、DNS 污染與代理迴圈，並提供 FlClash 自動更新間隔與更新代理的建議設定。

先判斷失敗發生在哪一層

Clash 或 FlClash 顯示「訂閱更新失敗」時，問題不一定出在訂閱服務本身。一次更新至少會經過四個環節：用戶端讀取訂閱 URL、系統或 mihomo 解析網域名稱、透過直連或代理建立 HTTPS 連線，以及下載並解析設定內容。任一層中斷，介面都可能只顯示一則簡短錯誤。

排查前先記下三項資訊：失敗發生的確切時間、介面或日誌中的完整錯誤，以及目前的網路環境。家用寬頻可用、行動熱點卻失敗，通常指向網路或 DNS；瀏覽器可以開啟連結，但用戶端回傳 403，通常與請求標頭或存取策略有關；下載成功卻提示設定無效，則應檢查回應內容與 YAML 結構。

利用狀態碼快速定位

  • 401 Unauthorized：訂閱需要有效的認證資訊，權杖可能已失效。
  • 403 Forbidden：伺服器拒絕請求，常見原因是 User-Agent、來源 IP 或存取頻率不符合策略。
  • 404 Not Found：URL 路徑不存在，舊訂閱網址可能已被替換。
  • 429 Too Many Requests：短時間內重新整理次數過多，應暫停手動更新並延長自動更新間隔。
  • 5xx：訂閱伺服器或上游閘道異常，可在不同網路下重新測試後等待恢復。
  • timeout、connection reset：連線在建立或傳輸階段中斷，應繼續檢查 DNS、路由與更新代理。
  • invalid character、yaml: unmarshal errors：已收到回應，但內容不是用戶端能夠讀取的 Clash YAML。

檢查訂閱連結、有效期限與回應內容

訂閱 URL 通常包含很長的存取權杖。複製時漏掉結尾字元、通訊軟體自動截斷連結，或網址混入換行，都會讓伺服器回傳錯誤。建議從服務提供者的控制面板重新複製完整 URL，再到 FlClash 的設定清單編輯對應訂閱，而不是反覆修改舊網址。

瀏覽器能開啟，不代表內容一定正確

在瀏覽器開啟訂閱連結後，應看到 YAML、Base64 文字，或由伺服器依用戶端類型產生的設定。如果頁面顯示登入頁、驗證碼、HTML 錯誤頁或一段 JSON 錯誤，即使用戶端完成下載，也無法將它載入為 Clash 設定。若回應開頭出現 <!doctype html> 或 <html，基本上可以確認取得的是網頁。

在桌面系統中，可以使用命令查看狀態碼與回應標頭。執行時不要將包含權杖的完整輸出公開分享：

curl -L --connect-timeout 10 --max-time 30 \
  -A "clash.meta" \
  -o subscription.yaml \
  -w "HTTP=%{http_code} SIZE=%{size_download} TIME=%{time_total}\n" \
  "https://example.invalid/subscription/token"

正常情況下應得到 HTTP=200，檔案大小不應為 0。包含數十個節點與規則的設定通常至少有數 KB；若只下載到 200～500 位元組，應開啟檔案檢查是否為錯誤說明。命令中的網域僅用於展示格式，實際測試時請使用自己的訂閱網址。

確認設定類型與用戶端相容性

  • FlClash 使用 mihomo 核心時，優先選擇 Clash、Clash Meta 或 mihomo 格式。
  • 只包含 vmess://、ss:// 等分享連結的純文字，不一定能直接作為完整設定載入。
  • 設定引用 rule-providers 時，也要確保規則集 URL 可以存取；主訂閱成功，不代表遠端規則集同步也成功。
  • 若服務端提供「通用訂閱」與「Clash 訂閱」兩個入口，應選擇明確標示 Clash 或 mihomo 的入口。

處理 User-Agent 遭封鎖與請求頻率限制

部分訂閱服務會依 User-Agent 回傳不同格式，或只允許已辨識的用戶端標識。瀏覽器使用 Chrome、Safari 等標識，FlClash 或 mihomo 則可能傳送不同標識，因此會出現「瀏覽器下載正常，用戶端回傳 403」的差異。

比對請求標頭

可以分別使用常見瀏覽器標識與 mihomo 標識請求同一網址，比較 HTTP 狀態碼、檔案大小與回應類型。若只有某個標識得到 200，表示伺服器存在請求標頭規則。

curl -L -A "clash.meta" -D headers-meta.txt \
  -o profile-meta.yaml "https://example.invalid/subscription/token"

curl -L -A "Mozilla/5.0" -D headers-browser.txt \
  -o profile-browser.yaml "https://example.invalid/subscription/token"

解決方式應優先從訂閱服務的用戶端類型選項著手，重新產生適用於 Clash 的網址。如果 FlClash 目前版本提供訂閱請求標頭設定，可在編輯訂閱設定時填入服務方明確要求的 User-Agent；沒有明確要求時，不建議連續嘗試大量標識。

429 與自動重新整理過於頻繁

手動連續點選更新、多台裝置共用同一訂閱，或將間隔設為 5 分鐘，都可能觸發頻率限制。訂閱內容通常不會每分鐘變更。個人裝置以 24 小時作為預設間隔較穩妥；節點變動頻繁時可設為 6 小時；只有在服務方明確建議時，才縮短至 1 小時。

使用情境 建議間隔 換算秒數
日常個人裝置 24 小時 86400
節點調整較頻繁 6 小時 21600
短期故障觀察 1 小時 3600

遇到 429 後，應至少停止重新整理 15～30 分鐘。繼續點選只會延長限制視窗。多台裝置使用相同網址時，將更新時間錯開，例如電腦設在整點、手機設在半點，可以減少同一時間的並發請求。

排查 DNS 污染、憑證錯誤與網路逾時

訂閱網域解析到錯誤 IP 時，常見表現是連線逾時、連線被重設，或憑證名稱與網域不相符。先比較系統解析結果與可信任 DNS 的結果，再決定是否調整 FlClash 的 DNS 設定。

進行兩組解析測試

nslookup subscription.example.com
nslookup subscription.example.com 1.1.1.1

如果兩次結果明顯不同，不代表其中一個必然錯誤，但值得配合服務方公布的線路進行檢查。也可以切換家用寬頻與手機熱點：同一裝置在熱點下能於 2 秒內更新、在寬頻下持續 30 秒逾時，問題更可能位於寬頻 DNS 或路由，而不是 YAML 本身。

在 FlClash 中可進入「設定」→「參數設定」檢查 DNS 與執行模式。啟用 mihomo DNS 後，應確保上游 DNS 位址可連線，且沒有將訂閱網域錯誤映射到本機位址。使用 DoH 時，啟動階段仍需要解析 DoH 伺服器網域，因此應保留可用的預設解析路徑，或為相關網域提供正確的引導解析。

不要忽略系統時間與憑證鏈

  • 系統時間誤差數小時，可能導致 TLS 憑證被判定為尚未生效或已經過期。
  • 公共網路的認證頁可能攔截首次 HTTPS 連線，應先在瀏覽器完成網路認證。
  • 公司或校園網路可能經過 HTTPS 檢查設備，憑證錯誤應交由網路管理員確認，不宜關閉憑證驗證。
  • 行動裝置開啟省電或背景資料限制後，定時更新可能被系統延後，回到前景手動更新則正常。

如何處理更新代理與代理迴圈

訂閱伺服器在目前網路中無法直連時，需要透過既有代理更新；但新裝置首次匯入時還沒有可用節點，又不能依賴尚未下載的訂閱，這就是典型的啟動依賴。另一種情況是用戶端將訂閱請求送到本機代理埠，而代理程序又等待這份訂閱載入完成，最終形成迴圈或逾時。

先判斷應直連還是走代理

  1. 關閉系統代理，僅測試訂閱網域是否能夠直連並回傳 200。
  2. 若直連失敗，啟動一份已可用的本機設定，再透過本機混合埠測試。
  3. 常見 mixed-port 為 7890，但實際埠號以「設定」→「參數設定」中顯示的值為準。
  4. 更新成功後檢查日誌，確認請求經過預期策略，而不是在 DIRECT 與代理之間反覆重試。
curl -L --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 30 \
  -o subscription.yaml \
  "https://example.invalid/subscription/token"

透過代理能在 3 秒內完成、直連卻始終在 10 秒後連線逾時，表示有必要使用更新代理。反過來，如果代理測試回報 Connection refused，應檢查 FlClash 是否正在執行、mixed-port 是否確實為 7890，以及埠號是否被其他程式占用。

避免將更新流量送入不可用的策略

訂閱更新代理應選擇目前已確認可用的節點或策略群組，不要選擇必須依賴待更新訂閱才能產生的臨時策略。首次匯入時，可先使用直連網路、手機熱點或一份本機可用設定完成啟動。更新後再恢復常用規則模式。

TUN 模式會接管更多系統流量，但不會自動解決訂閱伺服器無法連線的問題。若同時啟用 TUN 路由、DNS 劫持與系統代理，應重點檢查訂閱請求最終進入哪個入口。排障時可暫時關閉 TUN，只保留一條明確的 HTTP 或 mixed 代理路徑；確認訂閱更新正常後，再逐項恢復 TUN 與 DNS 設定。

FlClash 自動更新間隔的建議設定

在 FlClash 中開啟設定管理頁，選擇對應的遠端訂閱並進入編輯項目；全域網路參數可從「設定」→「參數設定」核對。不同版本的按鈕文字可能略有差異，但需要確認的欄位始終包括訂閱 URL、自動更新開關、更新間隔，以及是否透過代理更新。

日常裝置的穩定組合

  • 自動更新：開啟。
  • 更新間隔：24 小時；經常調整節點時設為 6 小時。
  • 更新代理：訂閱網域可直連時維持直連；直連穩定失敗時，選擇已可用的代理策略。
  • 啟動時更新：不必與短間隔同時使用，避免每次重新啟動都發起重複請求。
  • 失敗重試：間隔至少 5～15 分鐘，不進行連續的秒級重試。

若使用 mihomo 的 proxy-providers 管理遠端節點，更新間隔應以秒為單位寫入 interval。以下範例設定為 6 小時，並將節點健康檢查設為每 10 分鐘一次。健康檢查只會測試現有節點，不等同於重新下載訂閱。

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

proxy-providers 的遠端檔案應回傳代理節點集合；完整 Clash 設定訂閱通常則由用戶端設定管理功能匯入。兩者結構不同，不能只將完整設定 URL 填入 provider，就假定一定相容。出現解析錯誤時，應核對服務端是否提供 provider 專用格式。

如何確認自動更新確實執行

  1. 記下設定頁顯示的最後更新時間。
  2. 手動更新一次，確認時間、流量資訊或節點清單出現合理變化。
  3. 等待一個完整週期後再次檢查，不要以用戶端啟動時間代替更新時間。
  4. 查看日誌中是否出現 HTTP 狀態碼、provider 更新成功或解析失敗的記錄。
  5. 更新完成後切換兩個節點進行延遲測試，確認新設定已載入執行中的核心。

如果檔案下載成功但執行中的設定沒有變化，可能是新設定未通過驗證、用戶端仍在使用另一份本機設定，或 provider 檔案更新後尚未重新載入。此時應先確認目前啟用的設定名稱，再檢查日誌中的載入路徑。

依錯誤現象完成最後複核

現象 優先檢查 處理方向
401 或 404 訂閱權杖與 URL 從服務控制面板重新產生網址
403 User-Agent、來源 IP 選擇 Clash 格式並核對請求策略
429 更新頻率與裝置數量 暫停重新整理並改為 6～24 小時間隔
連線逾時 DNS、路由、更新代理 比較直連、熱點與 mixed-port
憑證錯誤 系統時間、認證網路 校準時間並完成網路認證
YAML 解析失敗 回應內容與訂閱格式 確認回傳的不是 HTML 或登入頁
更新成功但節點未變 啟用的設定與載入路徑 確認目前設定並重新載入

完整排查流程可以濃縮為六步：重新複製訂閱 URL；檢查 HTTP 狀態碼與下載內容；比對 User-Agent；切換網路並核對 DNS；分別測試直連與本機代理；最後設定合理的自動更新間隔。這個順序能涵蓋大多數 Clash、mihomo 與 FlClash 訂閱更新故障，也能避免將格式問題誤判為核心問題。

完成修復後，建議保留一份可啟動的本機設定，並記錄目前的 mixed-port、DNS 模式與更新時間。下次發生故障時，先用本機設定建立穩定網路，再更新遠端訂閱，通常比反覆刪除並重新安裝用戶端更快。

FlClash 下載入口 查看各平台用戶端