Clash 訂閱連結失效或解析失敗：常見原因與逐項自查步驟

先判斷故障發生在哪一層

Clash 客戶端更新訂閱時，通常要依序完成網域名稱解析、建立 TCP 與 TLS 連線、傳送 HTTP 請求、接收回應、辨識訂閱格式、解析 YAML 或節點 URI，最後交由 mihomo 等核心載入。介面上同一句「更新失敗」，可能對應完全不同的環節。直接反覆點選更新，通常只會重複同一個錯誤。

開始排查前，先記錄錯誤原文、發生時間及客戶端目前使用的核心版本。不要只記錄「不能用」。像 timeout、403 Forbidden、yaml: unmarshal errors、unexpected end of file 這類關鍵字，已足以將範圍縮小至網路、存取控制或格式解析。

可見現象	優先檢查	常見含義
貼上連結後立即提示格式錯誤	連結完整性、回應內容	複製不完整，或介面回傳網頁、JSON 錯誤訊息
等待約 10 至 30 秒後逾時	DNS、路由、TLS、本機網路	請求未能穩定抵達訂閱伺服器
顯示更新成功但節點數為 0	訂閱類型、方案狀態、內容格式	回傳內容可讀取，但不是目前入口所需的資料
瀏覽器可開啟，客戶端卻回傳 403	User-Agent、請求標頭、存取頻率	伺服器依客戶端特徵或頻率限制請求
舊設定可用，新訂閱無法載入	YAML 欄位、代理協定、核心版本	新內容含有目前核心不支援的結構

第一步：確認訂閱連結仍然有效

檢查複製結果與 HTTP 狀態

先將連結貼到純文字編輯器，確認開頭是 https:// 或服務方明確提供的 http:// 位址。即時通訊工具可能在問號、等號或連字號附近截斷連結；QR Code 辨識也可能混入空格或換行。若 URL 尾端包含 token=、key= 等參數，少一個字元就可能回傳 401、403 或空內容。

可以在終端機中只查看回應標頭。Windows 11 可開啟「終端機」→「PowerShell」，macOS 可開啟「應用程式」→「工具程式」→「終端機」。以下命令中的位址應在本機替換，執行結果不要公開轉發：

curl -I -L --connect-timeout 10 --max-time 30 "訂閱位址"

-L 用於跟隨 301 或 302 重新導向，連線逾時設為 10 秒，總時限設為 30 秒。常見狀態碼可依下列方向理解：

200：伺服器回傳了內容，但尚不能證明內容就是有效訂閱。
301、302、307、308：存在重新導向；客戶端過舊或無法連線至重新導向目標時可能失敗。
401、403：權杖失效、帳戶狀態異常、請求特徵不符合要求，或存取來源受到限制。
404、410：介面路徑已變更，舊訂閱位址已撤銷。
429：短時間內更新次數過多。停止重試，等待伺服器的限制視窗結束。
500、502、503、504：訂閱伺服器或其上游暫時異常，應間隔一段時間後再次確認。

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

瀏覽器與 Clash 客戶端使用的 DNS、代理路徑、Cookie、User-Agent 及重新導向處理方式可能不同。瀏覽器顯示下載檔案，只能表示目前的瀏覽器環境可以存取。客戶端仍可能因請求標頭不同、代理形成迴圈，或無法解析目標網域而失敗。

還要核對帳戶端狀態。流量用盡、方案到期或訂閱位址被重設後，部分服務不會回傳明確的 401，而是回傳說明文字或 HTML 登入頁。客戶端取得這些內容後，往往顯示「解析失敗」，表面上像 YAML 錯誤，根因卻是訂閱權限已經變更。

第二步：檢查回傳內容是否為 Clash 可辨識的格式

辨識完整設定、代理集合與通用節點清單

常見訂閱不只一種結構。完整 Clash 設定通常是 YAML，可能包含 proxies、proxy-groups、rules、dns 等頂層欄位。代理集合通常供 proxy-providers 引用，內容可能以 payload 為核心。另一類通用訂閱則是經 Base64 編碼的節點 URI 清單，解碼後可看到 ss://、trojan://、vmess:// 等項目。

這三類內容的用途不同。將僅供 proxy-providers 使用的集合位址直接當作完整設定匯入，客戶端可能提示缺少策略群組與規則；將完整 YAML 填入只接受節點清單的轉換入口，也可能得到節點數為 0。先確認服務方標示的是「Clash 設定」「Mihomo 設定」「代理集合」還是「通用訂閱」。

一個最小化的完整結構通常接近下列形式。實際設定還會包含連接埠、DNS 及更多規則，但縮排關係應保持一致：

mixed-port: 7890
mode: rule

proxies:
  - name: example-node
    type: ss
    server: 192.0.2.10
    port: 443
    cipher: aes-128-gcm
    password: example-password

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - example-node
      - DIRECT

rules:
  - MATCH,PROXY

排除網頁、錯誤 JSON 與截斷檔案

使用下列命令儲存回應本文，再用文字編輯器查看前幾十行。檔名使用本機暫存名稱即可：

curl -L --connect-timeout 10 --max-time 30 \
  -o subscription-response.txt \
  "訂閱位址"

如果開頭出現 <!doctype html>、<html>、登入表單或驗證碼說明，回傳的是網頁。若內容是 {"code":403,"message":"..."} 這類結構，回傳的是介面錯誤 JSON。若檔案結尾突然停在未閉合的引號、清單或 Base64 字串中間，可能是下載中斷或伺服器產生的內容不完整。

YAML 縮排只能表達層級，清單項目前的連字號必須位於正確層級。
Tab 字元可能導致 YAML 掃描失敗，設定縮排應使用空格。
節點名稱中的冒號、井號、花括號等字元可能需要以引號包住。
同一層級出現重複欄位時，不同解析器的處理結果可能不同。
回應標頭中的 Content-Type 可作為線索，但不能單獨判定內容是否有效。

第三步：比較 User-Agent 與請求行為

部分訂閱介面會依 User-Agent 回傳不同格式。例如，對瀏覽器回傳說明頁，對 Clash 或 mihomo 回傳 YAML；也有介面依 User-Agent 選擇相容欄位。瀏覽器測試為 200、客戶端卻取得 403 或 HTML 時，應比較請求特徵，而不是直接修改 YAML。

可以使用 curl 模擬常見的 mihomo 請求識別資訊。先測試預設請求，再測試指定 User-Agent；若兩次結果在狀態碼、檔案大小或本文格式上明顯不同，問題通常出在伺服器的識別邏輯：

curl -L -A "clash.meta" \
  --connect-timeout 10 \
  --max-time 30 \
  -o subscription-mihomo.yaml \
  "訂閱位址"

若指定 clash.meta 後回傳 YAML，而預設請求回傳網頁，應優先使用客戶端提供的訂閱 User-Agent 設定，或向訂閱提供方確認建議值。不同圖形客戶端的選單位置各異，常見入口位於「設定」→「訂閱設定」或個別設定的「編輯」→「請求標頭」。修改前記錄原值，避免將全域請求標頭誤用於其他設定。

同時排查頻率限制與快取

連續點選「更新」會在幾十秒內送出多次請求。伺服器可能依權杖、IP 或 User-Agent 計數，接著回傳 429、403 或暫時性空回應。遇到這種情況，應停止更新 10 至 30 分鐘，再發起一次請求。不要同時讓桌面端、手機端與路由器反覆擷取同一個位址。

客戶端快取也會造成「連結已修復但仍顯示舊錯誤」的錯覺。可以先在設定清單中記下設定名稱與修改內容，再刪除失敗的遠端設定並重新匯入。不要直接覆寫仍在運作的本機設定。若客戶端支援查看設定檔目錄，也可以比較快取檔案的修改時間與大小：修改時間未變表示下載階段失敗，時間已變但無法啟用則更接近解析或核心載入問題。

第四步：核對 mihomo 核心與設定欄位的相容性

訂閱成功下載後，仍須經過核心解析。Clash Premium、舊版 Clash、Clash Meta 與目前的 mihomo 對協定欄位及功能的支援範圍並不完全相同。訂閱服務升級範本後，可能加入舊核心不認識的代理類型、傳輸參數、DNS 欄位或規則提供器選項，因此同一個位址在新客戶端可用，在長期未更新的客戶端中卻報錯。

從日誌定位具體欄位

開啟客戶端的「設定」→「日誌」，將層級暫時設為 info 或 debug，重新執行一次訂閱更新或設定切換。完成後再恢復原本的日誌層級。重點尋找以下資訊：

unsupported proxy type：目前核心不支援訂閱中的代理類型。
field ... not found 或反序列化錯誤：欄位名稱、值的類型或版本相容性有問題。
proxy ... not found：策略群組引用了不存在的節點或其他策略群組。
rule provider ... error：主設定已載入，但外部規則集合下載或解析失敗。
bind: address already in use：設定可能已成功解析，失敗點是 7890 等連接埠已被占用。

核心相容性問題應先透過客戶端內建的核心更新入口處理，常見位置為「設定」→「核心」→「檢查更新」。更新後完全退出客戶端再重新啟動，確認日誌中顯示的實際核心版本已經變更。僅更新圖形介面但仍使用舊核心，錯誤不會消失。

區分訂閱解析與規則提供器失敗

完整設定可能繼續引用遠端 proxy-providers 與 rule-providers。主訂閱下載成功，不代表這些子資源都能存取。若節點清單存在，但切換設定時提示規則集合失敗，應檢查日誌中的具體 URL、HTTP 狀態與快取路徑，而不是重新產生主訂閱。

例如主設定可透過直連存取，但規則集合位址需要代理；客戶端啟動時代理尚未建立，就可能形成啟動依賴。可以先暫時停用相關遠端規則，確認主設定能否運作，再調整規則集合的下載路徑或更新策略。修改 YAML 後先檢查縮排，再使用客戶端的設定檢查功能載入。

第五步：檢查本地網路、DNS 與代理迴圈

先關閉系統代理後測試

訂閱更新一般由客戶端自行發起，但不同客戶端可能選擇直連、沿用系統代理，或透過目前的代理策略存取。如果目前節點已經失效，而訂閱網域又被送入該節點，就會出現「必須更新訂閱才能恢復節點，但更新訂閱又依賴失效節點」的迴圈。

記錄目前設定與策略群組選擇。
關閉「設定」→「系統代理」。
如果啟用了 TUN 模式，同時關閉「設定」→「TUN 模式」。
退出其他占用 7890、7891 或 7892 連接埠的代理程式。
在直連網路下重新測試訂閱位址。
更新完成後，再依序恢復系統代理與 TUN。

如果關閉系統代理與 TUN 後立即恢復，根因通常是路由規則、目前策略或代理回環，而不是訂閱格式。此時應檢查訂閱網域是否被錯誤送入代理策略，可為該網域新增明確的直連規則，並確保規則位於寬泛的代理規則之前。

rules:
  - DOMAIN,subscription.example.com,DIRECT
  - MATCH,PROXY

上方的網域僅用於展示結構，實際設定應填入訂閱服務的真實主機名稱。若訂閱經過多次重新導向，還要檢查最終重新導向網域；只放行入口網域，仍可能在第二次跳轉時失敗。

檢查 DNS、系統時間與 TLS

在終端機執行 nslookup 訂閱網域，確認能回傳位址。若瀏覽器使用安全 DNS，而系統解析失敗，客戶端可能無法沿用瀏覽器的解析結果。可以暫時切換到另一條網路，例如手機熱點，再測試一次。更換網路後恢復，表示問題更可能出在目前的 DNS、路由器過濾或網路出口。

TLS 憑證驗證也依賴正確的系統時間。裝置日期相差一天、時區錯誤或長期未同步時間，都可能觸發 certificate has expired、not yet valid 等錯誤。Windows 11 可進入「設定」→「時間與語言」→「日期與時間」→「立即同步」；macOS 可進入「系統設定」→「一般」→「日期與時間」，啟用自動設定。

防火牆或安全軟體也可能只限制客戶端程序，而不影響瀏覽器。可檢查系統防火牆的允許清單，確認目前的 Clash 圖形客戶端與 mihomo 核心程序都能建立出站連線。不要為了測試而長期關閉防火牆；較合適的方法是查看封鎖記錄，並為對應程式建立範圍明確的出站規則。

依固定順序完成一次完整自查

為避免多個變數同時變動，可以依下列順序執行。每完成一步只測試一次，並記錄狀態碼、檔案大小或日誌變化。如此便能確認是哪一項調整產生效果。

保存現場：記錄錯誤原文、發生時間、客戶端版本、核心版本及目前網路。
檢查 URL：確認連結未被截斷、帳戶有效，且權杖未被重設。
檢查 HTTP：使用 10 秒連線逾時、30 秒總時限測試狀態碼與重新導向。
查看本文：排除 HTML 登入頁、JSON 錯誤、空檔案及下載截斷。
確認類型：區分完整 YAML、代理集合與通用節點清單。
比較請求標頭：測試預設 User-Agent 與 clash.meta 的回應差異。
檢查相容性：更新客戶端核心，從日誌中定位不支援的欄位或協定。
隔離網路變數：暫時關閉系統代理與 TUN，改用直連或手機熱點測試。
重新匯入：保留舊設定備份，刪除失敗快取後重新新增遠端設定。
驗證結果：確認節點數量、策略群組、規則集合及更新時間都符合預期。

測試結果	可以得出的結論	下一步
所有網路都回傳 401 或 403	較接近連結權限或伺服器限制	確認帳戶狀態、重設訂閱位址或聯絡提供方
手機熱點可用，原本的網路逾時	原本網路的 DNS、路由或出口存在問題	檢查路由器、系統 DNS 與防火牆記錄
curl 取得 YAML，客戶端仍然失敗	較接近請求標頭、快取或核心相容性問題	查看客戶端日誌並更新核心
主設定成功，規則集合失敗	主訂閱本身有效	單獨排查 rule-providers 位址與策略
關閉 TUN 後更新成功	存在路由迴圈或啟動依賴	調整訂閱網域規則與更新路徑

恢復後還要驗證設定是否真正可用

訂閱頁面顯示「更新成功」只是第一層驗證。還應確認設定更新時間已重新整理、節點清單不是空的、策略群組引用正常，並執行一次延遲測試。延遲測試回傳具體數值，例如 85 ms 或 230 ms，表示測試 URL 能透過對應節點建立連線；持續顯示逾時，則應繼續排查節點或本地網路。

接著開啟連線面板，存取一個一般 HTTPS 頁面，觀察是否出現新連線，以及該連線命中了哪條規則、使用了哪個策略群組與節點。在規則模式下，訂閱網站可以直連，其他目標依規則分流；全域模式則會將大部分流量交給目前的全域策略。驗證時應確認目前模式與預期一致。

如果系統代理使用預設混合連接埠 7890，還可檢查作業系統代理位址是否為 127.0.0.1:7890，並確認日誌中沒有連接埠占用錯誤。TUN 使用者則應檢查 TUN 狀態、預設路由與 DNS 是否已恢復，不要只依賴瀏覽器快取頁面判斷連線成功。

穩定後可將遠端設定的自動更新間隔設為合理值，例如 6 小時、12 小時或 24 小時。以分鐘為單位輪詢通常沒有必要，還可能觸發伺服器的頻率限制。客戶端升級、核心切換或訂閱範本變更後，再手動更新一次並檢查設定即可。