Clash 訂閱連結失效怎麼辦：解析失敗與更新錯誤的自查步驟

先判斷故障發生在哪一層

Clash 用戶端更新訂閱時，實際上必須連續完成幾個步驟：連線至訂閱網址、跟隨重新導向、下載回應內容、辨識設定檔格式、解析 YAML，最後將代理節點與策略組寫入本機設定。介面上短短一句「更新失敗」，可能對應其中任何一個步驟。先定位問題層級，比反覆點選更新更有效。

排查前先記錄三項資訊：錯誤出現的確切時間、用戶端顯示的完整錯誤訊息，以及目前的網路環境。若條件允許，再更換一次網路，例如從家用寬頻切換至手機熱點。不要一開始就同時修改 DNS、系統代理、TUN 和訂閱網址，否則即使恢復，也很難判斷是哪個步驟發揮作用。

常見現象與對應方向

介面現象	優先檢查	常見原因
HTTP 401 或 403	訂閱權限、請求標頭	權杖失效、User-Agent 不符合伺服器要求
HTTP 404 或 410	訂閱網址	連結已撤銷、方案重設後舊網址失效
HTTP 429	更新頻率	短時間內請求過多，觸發伺服器限流
連線逾時	網路、DNS、代理回環	網域無法連線、更新請求經過失效代理
YAML 解析失敗	回應本文、格式	下載到網頁、JSON 錯誤訊息或縮排錯誤的設定檔
更新成功但節點數為 0	訂閱內容、篩選條件	回傳空設定、格式不相容、用戶端篩選掉所有節點

檢查訂閱網址、狀態碼與回應內容

訂閱連結通常會帶有一段存取權杖。權杖可能因重設訂閱、修改帳戶、服務到期或後台安全策略而變更。複製連結時也很容易多出空格、換行或通訊軟體附加的標點符號。應從服務提供方的控制面板重新複製完整網址，再貼到純文字編輯器中核對。

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

瀏覽器會自動處理 Cookie、頁面登入與部分跳轉，Clash 用戶端通常只會帶上一般 HTTP 請求標頭。若開啟連結後看到登入頁、驗證碼頁、方案說明或一段 HTML，用戶端取得的也可能是這些頁面，而不是代理設定。正確回應通常是 YAML 文字、Base64 編碼文字，或用戶端支援的訂閱格式。

在 macOS、Linux 或已安裝 curl 的 Windows 環境中，可以先查看回應標頭。以下使用的是範例網域，請勿將真實訂閱權杖發到公開聊天記錄或截圖中。

curl -I -L --max-redirs 5 "https://sub.example.net/api/client/abc123"

-I 只會請求回應標頭，-L 允許跟隨重新導向，--max-redirs 5 將跳轉次數限制為 5 次。重點觀察最終狀態碼、content-type，以及是否存在循環跳轉。訂閱服務常見的正常狀態碼是 200；301、302、307 或 308 可能代表正常轉移，但最終仍應回到 200。

狀態碼應如何處理

401 Unauthorized：權杖無效，或連結需要額外的身分資訊。重新產生訂閱網址，不要持續嘗試舊連結。
403 Forbidden：伺服器拒絕目前的請求。可能限制了用戶端類型、來源地區或請求頻率，應檢查 User-Agent 與帳戶狀態。
404 Not Found：路徑不存在。常見原因是複製不完整、連結遭截斷，或後台已更換介面。
410 Gone：資源已被明確撤銷，通常應重新產生連結。
429 Too Many Requests：請求過於頻繁。暫停 10 至 30 分鐘後，再手動更新一次，不要設定每分鐘自動重新整理。
500、502、503、504：伺服器或上游閘道異常。切換網路只能用來確認問題，通常仍需等待服務恢復。

如需查看少量回應本文，可以限制下載大小，避免將完整節點資訊列入終端機歷史記錄。更穩妥的做法是下載到只有自己能存取的暫存檔，再檢查檔案開頭。

curl -L --max-time 20 \
  -A "Clash.Meta" \
  "https://sub.example.net/api/client/abc123" \
  -o subscription-check.txt

head -n 12 subscription-check.txt

如果開頭出現 <!doctype html>、<html>、驗證碼文字或 JSON 錯誤物件，表示下載到的不是 Clash 設定。若本文只有一行很長的字母、數字、加號、斜線與等號，可能是 Base64 訂閱，需要由相容的用戶端或轉換流程處理。

處理 User-Agent 與格式不相容問題

部分訂閱介面會根據 User-Agent 回傳不同格式。例如同一個網址，對瀏覽器回傳網頁，對 Clash 回傳 YAML，對其他用戶端則回傳另一種編碼。用戶端升級、遷移至 mihomo 核心或更換圖形介面後，請求標頭可能發生變化，因此會出現「舊用戶端能更新，新用戶端卻報錯」的情況。

先使用服務方提供的用戶端類型

若訂閱控制面板提供 Clash、Clash Meta、Mihomo 等匯出選項，應優先重新產生相應類型的連結。不同匯出項目可能不只會修改 User-Agent，也會變更策略組、節點欄位與規則結構。只在用戶端中手動修改名稱，不一定等同於重新選擇訂閱格式。

部分用戶端可以在訂閱編輯頁設定 User-Agent。選單名稱因軟體而異，常見路徑是「訂閱」→「編輯」→「進階設定」→「User-Agent」，或「設定」→「參數設定」→「訂閱請求標頭」。可依序嘗試服務方明確支援的值，例如：

Clash
Clash.Meta
mihomo

不要一次填入多個值，也不要自行加入瀏覽器 Cookie。修改後先儲存，再手動更新一次。若伺服器回傳 403，而切換至服務方指定的 User-Agent 後恢復 200，基本上可以確認是請求標頭辨識問題。

Clash 設定需要完整結構

標準的完整設定通常包含代理、策略組與規則等部分。最小結構可能如下：

mixed-port: 7890
mode: rule

proxies:
  - name: Example
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Example
      - DIRECT

rules:
  - MATCH,PROXY

如果下載內容只有幾個 ss://、vmess:// 或其他分享連結，這屬於通用節點訂閱，不一定能被只接受 Clash YAML 的匯入入口直接讀取。反過來，包含 proxy-providers 的完整設定也不能直接當成單一 provider 檔案使用。匯入前要確認入口需要的是「完整設定」、「節點訂閱」還是「代理集合」。

YAML 解析錯誤的幾個細節

YAML 縮排應使用空格，Tab 可能導致解析失敗。
冒號後通常需要空格，例如 mode: rule。
節點名稱包含冒號、井號或特殊符號時，服務端應正確加上引號。
proxy-groups 引用的節點名稱必須與 proxies 中的名稱一致。
舊版 Clash 不認識的 mihomo 擴充欄位，可能觸發欄位驗證錯誤；升級用戶端或選擇相容的匯出格式會更合適。

排查網路遭封鎖、DNS 與代理回環問題

當狀態顯示連線逾時、TLS 交握失敗或網域解析失敗時，問題通常發生在下載設定之前。此時繼續調整 YAML 沒有意義，應先確認訂閱網域能否解析並建立 HTTPS 連線。

使用兩個網路進行交叉測試

在目前 Wi-Fi 下關閉 Clash 的系統代理與 TUN，直接更新一次。
切換至手機熱點後，再更新一次。
如果手機熱點正常、原本的網路失敗，應重點檢查原網路的 DNS、閘道過濾與 IPv6 路徑。
如果兩個網路都回傳相同的 403 或 404，問題更可能出在連結或伺服器，而不是本機網路。

檢查網域解析時，可以使用系統內建工具。若一般網域可以解析，只有訂閱網域失敗，可暫時將 DNS 調整為目前網路環境中穩定可用的解析伺服器後再試。修改前先記錄原值，測試完成後再決定是否保留。

nslookup sub.example.net

curl -v --connect-timeout 10 \
  "https://sub.example.net/api/client/abc123" \
  -o subscription-check.txt

curl -v 會顯示解析到的 IP、TCP 連線與 TLS 過程，但也可能輸出請求路徑，因此不要公開轉發記錄。若停在網域解析階段，請檢查 DNS；若停在連線階段，請檢查網路路徑；若 TLS 回報憑證網域不相符或已過期，應停止更新並等待伺服器修復，不應在用戶端長期關閉憑證驗證。

避免訂閱更新經過失效代理

部分用戶端允許訂閱下載「使用代理」。當目前節點已失效，而更新請求又被強制送入該節點，就會形成一個小死結：想更新節點，更新請求卻依賴舊節點。可在訂閱設定中關閉「透過代理更新」，或暫時退出系統代理後直接連線更新。

本機常見的監聽連接埠包括 HTTP 連接埠 7890、SOCKS 連接埠 7891、混合連接埠 7890，以及外部控制連接埠 9090，但這些連接埠都可以由使用者修改。若終端機環境設定了 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，即使用戶端介面已關閉系統代理，curl 仍可能繼續經過本機連接埠。

env | grep -i proxy

curl --noproxy "*" -I -L \
  "https://sub.example.net/api/client/abc123"

如果一般 curl 失敗，而加上 --noproxy "*" 後成功，表示問題出在代理鏈路，而非訂閱連結本身。Windows PowerShell 使用者還應檢查目前工作階段的代理環境變數，以及「設定」→「網路和 Internet」→「代理」中是否仍保留手動代理。

清理本機快取並重建訂閱記錄

連結和網路都正常，但用戶端仍顯示舊節點、空清單或固定時間的錯誤，可能是本機快取沒有成功替換。常見原因包括設定檔正被占用、磁碟權限異常、用戶端崩潰後留下未完整寫入的檔案，或訂閱記錄保留了舊的請求標頭。

採用可回復的處理順序

匯出目前可用的設定，並記下自訂規則、覆寫設定與策略組選擇。
完全退出用戶端，確認選單列、系統匣與背景處理程序都已結束。
重新啟動用戶端，以一般方式手動更新一次。
仍然失敗時，新建一筆訂閱記錄，不要覆蓋舊記錄，並貼上重新產生的網址。
新記錄更新成功後，再移轉自訂覆寫並刪除舊記錄。

不建議直接刪除整個應用程式資料目錄。許多圖形用戶端會將訂閱快取、執行設定、記錄檔、覆寫指令碼與介面設定放在同一個位置，全部清空會增加復原成本。較穩妥的方式是使用用戶端提供的「設定」→「訂閱」→「刪除快取」或「重建設定」功能；若沒有該選項，再依照相應用戶端文件定位單一訂閱快取檔案。

更新成功但仍然沒有節點

先確認介面顯示的更新時間確實已變更，再檢查訂閱本文是否包含節點。若原始回應有節點，而用戶端顯示 0 個，請繼續檢查以下設定：

節點名稱篩選器是否設定了過於嚴格的包含條件。
排除正規表示式是否誤將所有節點排除，例如過於寬泛的 .*。
訂閱覆寫是否刪除了 proxies 或替換了策略組。
用戶端是否只載入了 provider，但主設定沒有引用該 provider。
設定切換是否仍停留在舊檔案，而不是剛更新的新設定。

mihomo 的 provider 設定仍需要由策略組引用。例如已定義 proxy-providers，但任何策略組都沒有寫入相應的 use，節點就不會出現在該策略組中。

proxy-providers:
  airport:
    type: http
    url: "https://sub.example.net/provider.yaml"
    interval: 3600
    path: ./providers/airport.yaml

proxy-groups:
  - name: PROXY
    type: select
    use:
      - airport
    proxies:
      - DIRECT

interval: 3600 表示每 3600 秒檢查一次。實際更新間隔應配合服務端限制設定，通常沒有必要每隔幾分鐘重新整理。更新過於頻繁不會讓節點更快，也更容易遇到 429 限流。

依序完成一次完整自查

如果錯誤訊息不明確，可以按照以下固定流程操作。每完成一個步驟只修改一個變數，並記錄結果。這樣即使最後需要聯絡服務提供方，也能提供足夠清楚的證據。

儲存舊設定：匯出仍可正常工作的設定與自訂規則。
重新複製網址：從帳戶控制面板產生適用於 Clash 或 mihomo 的訂閱。
查看 HTTP 狀態：確認最終回應是 200，而不是登入頁、錯誤頁或循環重新導向。
核對回應格式：區分完整 YAML、provider 檔案、Base64 文字與網頁內容。
調整 User-Agent：使用服務方明確支援的 Clash、Clash.Meta 或 mihomo 標識。
繞過舊代理：關閉「透過代理更新」，檢查 7890、7891 等本機連接埠與環境變數。
更換網路測試：使用手機熱點區分本機網路故障與伺服器故障。
新建訂閱記錄：避免舊快取、舊請求標頭或舊覆寫繼續影響結果。
檢查篩選與引用：確認節點沒有被正規表示式篩除，provider 已被策略組引用。
控制更新頻率：遇到 429 後暫停請求，自動更新建議設定為每小時一次。

需要向服務提供方回報時，建議附上發生時間、最終 HTTP 狀態碼、用戶端名稱與版本、使用的 User-Agent，以及是否能在其他網路重現。訂閱網址只保留網域與介面類型，權杖部分應予遮蔽。清楚的資訊通常比一句「Clash 更新不了」更容易獲得有效處理。