訂閱連結匯入失敗？檢查訂閱失效的原因與步驟

先分辨下載失敗、解析失敗與設定檔驗證失敗

匯入 Clash 訂閱並非單一步驟。用戶端會先向訂閱網址發出請求並取得回應內容，再解析 YAML 或其他支援的訂閱格式，最後交由核心檢查節點、策略組與規則。介面上同樣顯示「匯入失敗」，實際出錯的環節可能完全不同。請先開啟用戶端的「日誌」，記下錯誤時間與第一則明確錯誤訊息，再進行修改。

Clash Verge Rev 等用戶端的介面名稱可能因版本而異。通常可在「訂閱」頁面新增遠端訂閱、輸入 URL 並匯入；若已有訂閱，則從對應項目的選單中選擇「更新」。排查時請一併記下用戶端與核心版本，不要只寫「最新版」。舊版 Clash 核心、Clash Meta（現稱 mihomo）及其他相容實作，支援的設定欄位不盡相同。

步驟一：確認複製的是訂閱網址，而非網頁網址

請在服務商後台選擇明確標示為 Clash、Clash Meta 或 mihomo 的訂閱入口。帳戶登入頁、方案詳情頁和邀請連結都不是訂閱網址。瀏覽器能開啟某個頁面，只代表網頁可連線，不代表核心能將它讀取為設定檔。

1. 重新複製完整 URL。確認開頭是 https://，結尾沒有被通訊軟體截斷，前後也沒有多出空格、換行或中文標點。請優先使用後台提供的複製按鈕。
2. 保留查詢參數原樣。不要任意刪除 token、key 等參數，也不要將整個 URL 再做一次百分比編碼。參數名稱以服務商提供的網址為準。
3. 檢查跳脫字元。從 HTML 原始碼複製時，參數分隔符號可能變成字面上的 &。一般 URL 中，多個查詢參數通常以 & 分隔；請回到原始入口重新複製，不要猜測並批次取代權杖內容。
4. 確認連結是否已重設。重設訂閱權杖後，舊連結可能立即失效。請更新用戶端儲存的 URL，而不是一再按下舊項目的「更新」。

訂閱網址通常等同帳戶憑證。請勿貼到公開的線上 YAML 檢查工具、不明訂閱轉換網站或公開客服案件中。若需聯絡服務商，先說明錯誤類型與發生時間，再透過其私密支援管道提供必要資訊。

步驟二：檢查 HTTP 狀態碼與實際回應內容

判斷「訂閱失效」時，狀態碼和回應內容都要檢查。HTTP 200 仍可能回傳登入頁、風控頁面或 JSON 錯誤訊息；Content-Type: text/plain 也可能包含完全有效的 YAML。不要只根據副檔名、回應標頭或「下載成功」提示下結論。

在本機儲存回應，先不要自動跟隨重新導向

熟悉終端機操作的使用者可在 Bash 執行以下命令。命令會隱藏輸入的訂閱網址，並將回應標頭與內容分別儲存至目前目錄。請先切換到僅自己可存取的工作目錄；檔案仍包含敏感資訊，勿上傳或同步至公開儲存庫。Windows 使用者可使用支援 Bash 的環境，或從用戶端日誌查看同類資訊。

umask 077
read -r -s -p '請輸入訂閱 URL：' SUB_URL
printf '\n'
curl --connect-timeout 10 --max-time 30 \
  --dump-header subscription-headers.txt \
  --output subscription-body.txt \
  --write-out 'HTTP %{http_code}\n' \
  "$SUB_URL"
unset SUB_URL

此處的 10 秒是連線逾時，30 秒是整個請求的時間上限，不代表實測效能或用戶端預設值。命令未加入自動跟隨重新導向的參數：遇到 301、302、307、308 時，請先在本機確認 Location 是否指向服務商認可的網域。重新導向目標也可能含有權杖，請勿直接分享回應標頭。命令列請求的特徵可能與用戶端不同，因此只能用來比對，不代表用戶端一定會收到相同回應。

依狀態碼縮小排查範圍

• 200：接著檢查回應內容。若以 <!DOCTYPE html> 或 <html 開頭，通常是網頁，而非 Clash 設定檔。
• 204 或回應內容為 0 位元組：沒有可解析的內容。請確認連結與伺服器產生狀態，不要試圖補上 YAML 欄位來掩蓋問題。
• 401、403：可能是權杖失效、權限不足、來源限制或風控所致；僅憑狀態碼無法判定帳戶已到期。
• 404、410：確認舊入口是否已遷移或撤銷，再從帳戶後台取得新網址。
• 429：請停止連續重試；如果回應提供 Retry-After，請依照指示等待。
• 500、502、503、504：優先懷疑訂閱產生服務或上游閘道異常。記下發生時間後聯絡服務商。

若回應內容是以 vmess://、ss:// 等開頭的節點清單，或一整段 Base64 文字，代表選到的可能是通用訂閱格式。能否直接匯入取決於用戶端；這類內容不能當成完整的 Clash YAML 設定檔使用。請優先改選服務商提供的目標格式。

步驟三：檢查 YAML 縮排、欄位型別與策略引用

確認回應內容是 YAML 後，再檢查語法。YAML 以空格表示層級，縮排不能混用 Tab。錯誤訊息中的行號通常是解析器發現異常的位置，真正原因可能在前一行，例如引號未閉合、冒號後漏了空格，或複製時少了一段清單。

先檢查語法，再確認設定內容

• 縮排：同一層級的縮排要一致，每層通常使用 2 個空格。清單項目前的 - 也必須位於正確層級。
• 特殊字元：名稱或密碼含有「冒號加空格」、# 等字元時，必須正確加上引號。以單引號括住的字串若含單引號，需依 YAML 規則將單引號寫成兩個。
• 欄位型別：proxies 通常是節點清單，proxy-groups 是策略組清單，rules 是規則清單。能解析為 YAML，不代表欄位型別符合核心的要求。
• 引用名稱：規則與策略組引用的節點名稱、群組名稱都必須存在且一致。請勿只修改節點名稱，卻保留舊的引用名稱。

以下是用於隔離解析問題的最小直連設定。請另存為獨立測試檔案，不要覆蓋正式訂閱。此設定不含代理節點，所有流量都會直連；測試通過只代表核心接受這段基本設定，不代表訂閱或代理線路已恢復。

mixed-port: 7890
mode: rule
log-level: info
proxies: []
proxy-groups:
  - name: DIRECT-TEST
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,DIRECT-TEST

此處的 7890 是混合連接埠範例，並非所有用戶端的固定預設值。連接埠衝突通常會影響核心執行或監聽，不會讓遠端回應內容變成 HTML。若只測試設定，也不必先切換系統代理、啟用 TUN 或修改 DNS。

使用實際核心進行測試

如果本機已有 mihomo 執行檔，可使用以下命令檢查已儲存的設定。請使用用戶端實際採用的核心版本；改用較新的核心測試通過，並不能證明舊核心也相容。

mihomo -v
mihomo -t -f ./profile.yaml

-t 用於測試設定，-f 用於指定檔案。完整設定若引用遠端 provider，初始化或檢查時仍可能讀取相關資源；請在可信設定與受控環境中操作。測試日誌也可能包含節點名稱、資源網址，不宜直接公開。

步驟四：確認核心格式、provider 與用戶端覆寫

同樣是 YAML，仍有「完整設定」與「節點 provider 檔案」之別。供 proxy-providers 使用的檔案通常只包含 proxies 節點清單，並非完整的執行設定；必須由主設定中的 provider 引用。反之，將包含策略組與規則的完整訂閱填入只接受節點清單的入口，也可能導致匯入失敗。

1. 確認目標核心。若服務商分別提供 Clash 與 Clash Meta/mihomo 入口，請選擇與本機實際使用的核心相符的版本。遇到不支援的代理類型或欄位時，先確認核心的支援範圍，不要直接刪除安全或協定參數。
2. 檢查後續下載。主設定匯入成功後，proxy-providers、rule-providers 可能仍須下載資源。請查看日誌中的失敗網址類型，分辨是主訂閱失敗還是資源更新失敗。
3. 確認引用關係。使用 provider 的策略組必須透過 use 等受支援欄位引用相應名稱。篩選條件若排除所有節點，也會造成群組內沒有可選節點。
4. 隔離覆寫邏輯。新增測試項目時，先暫停套用個人合併設定、指令碼或擴充功能覆寫。若原始訂閱正常、最終設定卻失敗，再逐項恢復覆寫，找出遭到改動的欄位。

步驟五：檢查網路路徑與帳戶狀態

若日誌顯示連線逾時、DNS 解析失敗或 TLS 憑證異常，應回到請求階段排查。瀏覽器可能使用擴充功能代理、快取或已登入的工作階段；用戶端更新訂閱時則可能走另一條網路路徑。兩者結果不同，不能直接據此判定連結真假。

• 比較直連與既有可用代理。若用戶端提供訂閱下載代理選項，可分別測試並記錄結果。避免讓訂閱更新依賴目前已失效的節點；若沒有可用線路，可透過手機熱點與目前網路交叉測試。
• 確認系統時間。日期或時區明顯錯誤會影響憑證驗證。請先同步時間，不要關閉 TLS 憑證驗證來避開錯誤。
• 檢查 DNS 與網路登入狀態。飯店、校園或公共 Wi-Fi 的驗證頁面可能會攔截請求。請先完成網路驗證再重試；不要只因看到 HTML 就立刻更改訂閱格式。
• 查看服務商後台。確認方案有效期限、流量狀態、訂閱重設紀錄與維護公告。流量用完後是否回傳錯誤或仍保留節點，由服務商決定，不能一概而論。

若同一連結在多個網路環境下都回傳相同的 403 或固定錯誤內容，而後台也顯示授權異常，聯絡服務商通常比重新安裝用戶端更有效。若只有目前裝置失敗，請優先比對本機時間、代理設定、用戶端請求選項與核心版本。

修復後再次確認：匯入成功不代表節點可用

修復後，先手動更新一次，確認日誌不再出現下載或解析錯誤。接著檢查節點數量、策略組成員與 provider 更新時間，再選擇節點測試實際連線。延遲測試成功只代表該測試請求成功，不能取代日常目標網站的連線驗證。

1. 保留一份已驗證的設定備份，並記下還原時使用的用戶端與核心版本。
2. 確認目前啟用的是剛修復的訂閱，而非仍在執行的舊設定。
3. 恢復原有的自動更新排程，避免短時間內重複請求而觸發流量限制。
4. 清除本機暫存的回應檔案；若完整訂閱網址曾遭公開洩漏，請至服務商後台重設權杖，再同步更新所有裝置。

需要回報問題時，提供「發生時間、用戶端版本、核心版本、HTTP 狀態碼、已遮蔽敏感資訊的第一則錯誤訊息，以及是否能在不同網路重現」即可。請勿在公開討論中貼出完整訂閱 URL、原始節點密碼或整份回應內容。依照「網址 → 回應 → 語法 → 核心 → 網路與帳戶」的順序檢查，通常能找出問題所在，再決定要更新連結、修復設定，或等待伺服器恢復。