Clash 訂閱連結怎麼匯入：完整 YAML、節點清單與分享連結的差異

一、先判斷輸入內容，再選擇匯入入口

「複製連結後匯入」只適用於用戶端能夠識別的輸入。訂閱 URL 是取得內容的網址，YAML 是一種設定文字格式，單一節點分享連結則是某個節點的參數載體。這三者不在同一個層級：同一個 HTTPS 網址可能回傳完整設定、節點清單，也可能回傳登入頁面。網址能在瀏覽器中開啟，不代表它就能作為 Clash 設定載入。

用戶端負責介面、訂閱下載與設定管理；Clash 或 Clash Meta（mihomo）等核心負責解析有效設定、建立代理連線、比對規則及處理 DNS。部分用戶端具備格式轉換功能，但不能因此認定所有 Clash 用戶端都能直接匯入任意分享連結。開始前，應在「關於」或核心資訊頁面記下用戶端版本與核心版本，兩者不能互相取代。

手上的內容	典型特徵	應尋找的入口
遠端訂閱 URL	以 `https://` 開頭，可能帶有驗證參數	遠端設定、URL 匯入或建立新訂閱
本機 YAML 檔案	通常為 `.yaml` 或 `.yml`，內容是結構化文字	本機設定、從檔案匯入
節點提供器內容	頂層通常是 `proxies:`，沒有策略群組和規則	由主設定中的 `proxy-providers` 引用
單一節點分享連結	以 `ss://`、`vmess://`、`trojan://` 等開頭	用戶端明確提供的節點匯入或轉換入口

二、匯入訂閱 URL：下載、選取與套用分成三個步驟

先取得符合目前核心的訂閱網址

在訂閱提供方的管理頁面中，選擇與用戶端核心相符的 Clash 或 mihomo 輸出。不要直接複製帳戶中心頁面的網址，也不要把「一鍵匯入」按鈕的用戶端喚起協定當成 HTTPS 訂閱網址。如果提供方區分舊版 Clash 與 mihomo，選擇依據應是實際執行的核心，而不是桌面捷徑的名稱。

檢查複製結果：連結前後不應帶有引號、空格或聊天軟體附加的標點符號。保留原有驗證參數；修改參數可能導致伺服器拒絕存取。
建立遠端設定：進入用戶端的「設定」或「訂閱」頁面，找到 URL 輸入框或建立遠端設定的入口，貼上網址並下載。不同用戶端的按鈕名稱和排列方式可能有所不同。
查看匯入結果：確認設定清單新增了記錄，並檢查更新時間、節點數量及下載錯誤。只出現設定名稱，不能證明內容已正確解析。
選取並套用：將新記錄設為目前設定。部分用戶端匯入後仍會使用舊設定，需要再次點選設定卡片或執行套用操作。
核對執行狀態：查看核心是否正在執行、策略群組是否出現，以及是否存在未知協定或目標不存在的錯誤，之後再進行連線驗證。

以具備 Profiles 頁面和 URL 輸入框的舊版 Clash for Windows 介面為例，路徑通常是 Profiles → URL 輸入框 → Download，之後還要選取對應的設定卡片。這只是舊介面的入口範例，不代表該版本仍在維護，也不適用於所有用戶端；新版用戶端請依照「遠端設定」的功能含義尋找對應入口。

首次匯入不必同時啟用 TUN、修改 DNS 及更換所有規則。先確認設定能夠載入，再確認代理接管方式，才能將故障範圍控制在單一環節。如果下載訂閱本身需要既有代理，應使用可正常運作的舊設定，或依照提供方支援的網路路徑取得；新設定尚未下載時，不能依賴它解決自己的下載問題。

三、本機 YAML：檢查內容完整性與引用關係

本機匯入適合離線設定、備份還原和手動編輯。檔案副檔名只是線索：將網頁重新命名為 config.yaml，不會讓它變成設定檔。使用純文字編輯器開啟檔案，檢查是否出現 <html>、登入提示或介面錯誤訊息。YAML 的縮排使用空格，不要混用 Tab；編輯器應顯示實際副檔名，避免儲存成 config.yaml.txt。

完整設定不是「有 proxies 就夠了」

一個能夠執行預期代理分流工作的設定，通常需要節點或節點提供器、策略群組、規則，以及適當的監聽設定。具體欄位是否必填，取決於核心預設值與用戶端的產生機制，但規則目標必須能夠解析：規則指向 Proxy，就應存在同名的策略群組或節點，不能只靠介面顯示名稱來推斷。

# 設定示意：只驗證結構，不包含遠端代理節點
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Proxy

本機檔案匯入後，不應預設它仍保留原訂閱的自動更新關係。用戶端可能會將檔案複製到自己的設定目錄，也可能直接引用原始路徑；編輯桌面上的來源檔案，不一定會影響正在執行的副本。應從目前設定記錄的編輯或檢視功能確認實際內容，再進行修改並重新載入。操作前先儲存一份附日期的備份，例如 config-backup-2026-06-16.yaml。

如果檔案使用 proxy-providers 或 rule-providers，本機 YAML 只是入口，啟動時仍可能需要下載外部資源。複製主檔案不等於複製了所有相依項目。請檢查提供器路徑、遠端網址與快取是否可用，尤其從另一台裝置移轉設定時，不要照搬原裝置的絕對路徑。

四、只有節點清單或分享連結時該怎麼處理

節點清單需要由主設定組織起來

頂層只有 proxies: 的 YAML 通常用作節點提供器。它描述可用節點，卻未必定義應用程式使用的本機連接埠、策略群組和分流規則。將它作為主設定匯入時，有些用戶端會補齊必要結構，有些只顯示節點或直接報錯；不能把某個用戶端的自動補全行為當成通用格式規範。

在支援提供器的核心中，通常由主設定在 proxy-providers 中定義一個命名資源，再由策略群組透過 use 引用它。提供器名稱必須一致，遠端資源也必須是核心支援的節點格式。不能只將一般訂閱 URL 填入此欄位，就假設核心會解碼任意 Base64 節點訂閱。相關欄位可對照設定大全的節點說明進行核對。

分享連結要同時考慮解析能力與協定支援

單一節點 URI：ss:// 等連結攜帶單一節點的參數，不包含完整分流規則。只有用戶端明確支援此類型匯入時，才能直接使用。
多行 URI 或 Base64 文字：它們可能是通用節點訂閱，但不是完整的 Clash YAML。需要由提供方輸出相容格式，或使用可信任的工具轉換。
協定與傳輸參數：轉換後仍須核對協定、連接埠、TLS、SNI、傳輸路徑等。舊版 Clash 核心不等同於 mihomo，不能假設兩者支援相同的協定與欄位。

出現「未知協定」時，先查詢目前核心的支援範圍；出現連線握手錯誤時，再對照原始參數。不要藉由刪除無法識別的欄位來強行消除錯誤：該欄位可能正是伺服器要求的傳輸或驗證參數。需要更換用戶端時，先在選型指南核對平台與核心的關係，再移轉設定。

五、訂閱更新失敗：依回應、解析、連線分層排查

「更新失敗」至少包含三類問題：請求沒有取得內容、取得的內容無法解析、解析成功但節點無法連線。節點延遲測試失敗不等於訂閱更新失敗；同樣地，HTTP 請求成功也不等於設定正確。應先查看設定更新時間和下載記錄，再查看核心錯誤，最後測試實際連線。

具體訊號	優先檢查	下一步操作
HTTP 401 或 403	權杖失效、帳戶權限、存取限制	重新取得訂閱網址，檢查帳戶狀態；403 也可能來自存取防護
HTTP 404	網址路徑變更、複製不完整	對照提供方目前產生的網址，不要手動猜測路徑
HTTP 429	重新整理過於頻繁	停止連續重試，依照回應提示或提供方規則等待
HTTP 200，但解析報錯	回傳網頁、錯誤 JSON 或不相容的節點格式	在本機檢查回應開頭與錯誤行，確認相容格式
DNS 失敗或連線逾時	訂閱網域解析與下載所經過的連線路徑	檢查本機網路、現有代理及訂閱更新的代理設定
TLS 憑證錯誤	系統時間、憑證鏈、驗證入口或網路攔截	校準時間並確認網路狀態，不要把關閉憑證驗證當作一般修復方式

瀏覽器下載正常而用戶端失敗時，還要檢查重新導向、登入 Cookie、請求標頭及提供方的用戶端識別策略。瀏覽器可能因為已登入而取得檔案，用戶端則取得登入頁面；反過來，伺服器也可能依 User-Agent 回傳不同內容。解決方法是取得面向目標用戶端的訂閱入口，而不是將瀏覽器登入工作階段複製到無關的軟體中。

遇到 yaml: line 12 這類提示時，檢查第 12 行及其上一行的縮排、引號和冒號。錯誤行通常是解析器發現異常的位置，不一定是最初寫錯的位置。如果遠端內容本身有問題，應優先聯絡提供方或改用其支援的輸出格式；本機暫時修好後，下一次更新仍可能重新取得原本的錯誤內容。

六、更新覆蓋本機修改：分開處理訂閱與覆寫

遠端訂閱通常是可重新下載的來源檔案。直接在其中加入規則、修改連接埠或重新命名策略群組，下次更新時就可能被覆蓋。這是內容更新方式造成的結果，不一定是儲存失敗。用戶端的執行設定還可能由「訂閱內容＋全域設定＋覆寫」合併產生，因此編輯某一層後，必須確認最終生效值。

保留訂閱原檔：將遠端網址和自動更新保留在遠端設定記錄中，不要把唯一副本改成難以還原的手動版本。
分開儲存修改：如果用戶端提供覆寫、合併或腳本功能，請用它儲存自訂規則與設定；具體執行順序以該用戶端的實作為準。
檢查陣列行為：rules 和 proxy-groups 可能會被取代、插入前方或追加至後方，不能假設所有合併機制都相同。
重新檢查規則順序：規則通常會依順序比對，自訂規則放在 MATCH 之後往往不會生效；規則引用的策略群組也要在更新後繼續存在。
進行一次手動更新：比較更新前後的有效設定，確認訂閱重新整理成功，同時自訂設定仍然存在，再啟用定期更新。

七、匯入後的最小驗證清單

判斷匯入成功應涵蓋設定、核心和實際請求三個層次。先不要用「把所有節點都測一遍」取代基本檢查：延遲探測使用的目標可能無法連線，但瀏覽器仍能透過該節點存取其他網站；也可能探測成功，但應用程式實際上沒有使用代理。

設定層：目前選取的是新設定，更新時間符合本次操作，目標策略群組存在，群組內選取了預期節點而不是 DIRECT。
核心層：沒有解析失敗、連接埠佔用或未知協定錯誤；查看實際監聽連接埠，不要只照抄教學中的 7890。
接管層：桌面系統代理主要影響遵循系統代理設定的應用程式；TUN 涉及虛擬網卡、路由和權限，行動裝置通常還需要 VPN 授權。這些功能都無法修復錯誤的訂閱格式。
請求層：存取一個已知可用的網站，在連線或記錄頁面觀察請求是否進入核心、命中了哪條規則，以及最後使用哪個策略。

使用明確代理請求隔離系統代理問題

如果桌面裝置已安裝 curl，且核心確實在本機 7890 連接埠提供 HTTP 或混合代理，可以執行下方的診斷指令。Windows 可使用 curl.exe，避免部分 PowerShell 環境中同名別名造成的參數差異。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

這裡的 10 秒是連線逾時上限，20 秒是整個請求的時間上限，不是實際測得的延遲。收到 HTTP 回應表示這次明確代理請求已完成回應流程，但不代表使用了遠端節點，因為規則仍可能選擇直連。如果提示無法連線至 127.0.0.1:7890，先檢查監聽連接埠和核心執行狀態；如果明確代理請求成功、一般瀏覽器失敗，再檢查瀏覽器代理設定或其他接管衝突。

最後儲存已去除敏感資訊的錯誤訊息、用戶端與核心版本、輸入類型及重現步驟。繼續調整前，可對照快速入門的連線驗證，確保每次只變更一個變數。這樣可以明確判斷問題發生在訂閱取得、設定解析還是代理鏈路，而不是在反覆匯入和重新安裝的過程中遺失線索。