Clash 訂閱連結格式解析：YAML 設定、Base64 節點字串與轉換方式

先確認回傳內容，再選擇匯入方式

Clash 訂閱連結是取得設定檔的網址，YAML 或 Base64 則是網址回傳的內容格式。瀏覽器能開啟，不代表可以直接匯入 Clash 蘋果版。建議優先使用服務商明確標示的 Clash 或 mihomo 訂閱；只有通用節點訂閱時，再考慮轉換。Apple 晶片 Mac 使用 arm64 用戶端，不會改變訂閱格式的要求；iPhone 與 iPad 則還要確認 App 支援哪些通訊協定與設定欄位。

判斷時請檢查回應本文，不要只看連結是否有 .yaml 副檔名。同一個網址可能依查詢參數或請求的 User-Agent 回傳不同內容；瀏覽器取得的頁面也可能只是登入頁，而不是用戶端實際取得的設定檔。

YAML 設定：節點、策略組與規則的用途

YAML 是結構化文字，不是逐行列出節點就算完成設定。Clash 系列核心通常以 proxies 描述代理節點，以 proxy-groups 組織可選的出口，再透過 rules 決定連線流向。外部節點集合透過 proxy-providers 載入；外部規則集合則以 rule-providers 宣告，再由規則引用。

易讀的最小設定範例

以下設定僅示範設定層級，所有連線最後都會直連，不包含遠端代理節點。7890 是本例自行指定的混合代理連接埠，並非所有用戶端的預設值；allow-lan: false 搭配迴路位址監聽，可限制區域網路裝置使用此入口。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: 手動選擇
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,手動選擇
  - MATCH,DIRECT

• proxies：儲存節點類型、伺服器位址、連接埠，以及驗證、TLS 等資訊。欄位是否可用取決於核心。
• proxy-groups：設定選擇策略。規則指定的群組名稱必須存在；重新命名節點或群組後，也要同步修改引用。
• rules：通常依序由上而下比對，符合第一條規則後就採用對應策略；最後的 MATCH 用於處理未符合其他規則的流量。
• dns 與 tun：分別控制網域解析與虛擬網路介面的行為，不是每份訂閱都必須包含，也不應為了「完整」而盲目新增。

YAML 縮排請使用空格，不要使用定位字元。節點名稱含 #、冒號後接空格等特殊內容時，請使用正確的字串引號。設定能由 YAML 解析器讀取，只代表語法上可解析；代理類型、欄位值與策略引用仍須由核心進一步檢查。

Base64 訂閱：編碼不等於設定，也不等於加密

常見的通用訂閱會先將多個節點 URI 以換行串接，再把整段文字編碼為 Base64。解碼後可能是 Shadowsocks、VMess、Trojan 等節點描述。不同來源的格式不盡相同：有些直接回傳 URI 清單，有些使用 URL-safe Base64，也有些省略結尾填充字元，因此不能只憑「看起來像一長串英數字」判斷。

在 macOS 本機檢查已儲存的內容

1. 將要檢查的原始回應儲存為本機文字檔，命名為 nodes.b64。請勿將登入頁面存成訂閱本文。
2. 在「Finder」中開啟檔案所在的資料夾，再於「終端機」切換至該資料夾。確認資料夾不在共享目錄中。
3. 若內容為標準 Base64，請執行以下指令將結果寫入另一個檔案，避免覆寫原始回應。

base64 -D < nodes.b64 > nodes.txt

這是 macOS 內建 base64 的解碼參數。若指令執行失敗，輸出檔可能只有部分內容，不應繼續用來匯入。請先確認來源檔是否已是純文字 URI，或使用 URL-safe 字元及省略填充字元；若需相容處理，請使用明確支援該變體的本機工具，不要任意刪除字元。

即使成功解碼，也不能據此認定節點有效。Base64 不具備保密能力，解碼後的 nodes.txt 可能包含密碼、UUID 與伺服器資訊。檢查後請妥善處理原始檔與解碼檔，避免透過雲端硬碟分享或附加至客服案件而外流。

訂閱轉換流程與常用參數

轉換工具的常見流程如下：取得來源訂閱、解析節點、篩選及重新命名、對應目標通訊協定欄位、套用範本，最後輸出設定。它不是核心升級工具，無法讓舊核心憑空支援新通訊協定，也無法從節點清單還原服務商未提供的規則。

先選擇目標核心，再選輸出格式

1. 確認用戶端核心。前往 App 的「關於」或核心資訊頁面，記下核心名稱與版本。介面版本和核心版本是兩項不同資訊；只知道 App 支援 macOS 或 iOS 並不足夠。
2. 優先使用原生訂閱。如果服務商同時提供 Clash 與 mihomo 專用入口，請選擇符合目標核心的入口，減少中途轉換。
3. 確實需要轉換時，選擇可信任的環境。優先在本機或自行管理的伺服器上執行。第三方轉換服務通常能讀取來源訂閱與節點驗證資訊；HTTPS 只能保護傳輸過程。
4. 確認輸出內容範圍。分清楚「完整設定」與「僅代理清單」，再決定使用設定匯入入口或代理提供者入口。
5. 保留原設定並進行測試。先新增設定，不要直接覆寫目前使用的檔案。確認節點數量、策略組、最後一條規則與連線記錄後，再切換使用。

以常見的 subconverter 介面用法為例

以下說明常見參數的用途，並非所有轉換服務的統一標準。實際可用的值請以所用服務執行個體的文件與版本為準，尤其不要假設每個執行個體都支援名為 mihomo 的輸出目標。

若來源網址含有 &，直接接在轉換請求的 url= 後面，後續內容可能被誤認為轉換工具本身的參數。請交由可信任的工具正確編碼參數，避免手動串接或重複編碼。轉換網址本身也可能含有原始權杖，同樣應視為敏感資訊處理。

轉換後規則遺失：依序檢查輸出、範本與覆寫順序

「節點能連線，但所有網站都走同一個出口」不一定代表規則遭到刪除。可能只有節點清單、設定未啟用、目前處於全域模式，或原有規則已被範本取代。分項檢查以下內容，比反覆更換節點有效。

第一步：檢查轉換結果

• 搜尋頂層的 rules: 與 proxy-groups:。如果只有 proxies:，請先確認是否啟用了僅輸出清單。
• 如果規則中使用 RULE-SET，請確認對應的 rule-providers 名稱存在，且遠端資源已成功下載。
• 檢查規則指定的策略名稱是否與策略組完全相同，包括空格、大小寫及重新命名後的字元。
• 檢查預設規則的位置。若過早出現 MATCH,DIRECT，後續規則就沒有比對機會。

第二步：檢查轉換範本是否取代了上游規則

完整 YAML 經過轉換後，輸出的規則不一定與輸入內容一致。有些轉換流程只擷取節點，再依自己的範本重建設定。請分別儲存轉換前後的文字，比對 rules、proxy-groups、dns 與提供者宣告；如果上游已提供適用的完整設定，直接匯入通常更能保留原有設定邏輯。

第三步：檢查用戶端實際執行的設定

確認剛匯入的設定已選取，且執行模式為規則模式，而非全域或直連模式。接著檢查用戶端的覆寫、合併、指令碼或增強設定功能：這些本機設定可能在訂閱下載後再次改寫內容。只修改快取中的訂閱檔，下次更新時可能會被覆蓋；若要長期保留本機調整，應使用用戶端明確支援的持久化覆寫機制。

最後開啟連線記錄，選一個網域查看命中的規則與最終出口。網站顯示的地區、節點延遲數字或頁面能否開啟，都無法單獨證明規則已生效。如果記錄顯示規則比對正確，但連線仍異常，再繼續檢查 DNS、節點連線狀態與目標服務的限制。

Mac、iPhone 與 iPad 匯入後檢查清單

Apple 裝置可以使用相同的訂閱來源，但不代表每個用戶端都支援同一份設定的所有欄位。尤其是 mihomo 的擴充通訊協定、規則與 DNS 選項，不能只憑檔案副檔名是 YAML 就認定相容。

1. 確認匯入類型。完整設定請使用遠端設定入口；代理集合則使用 App 支援的節點或代理提供者入口。選單名稱會因用戶端而異，請勿將規則集 URL 當成節點訂閱。
2. 確認設定來源。檢查複製的訂閱網址是否完整，沒有多出中文標點，也沒有過期的存取權杖。遇到 HTTP 401 或 403 時，請先處理授權問題，不要急著修改 YAML。
3. 確認監聽連接埠。本例使用 127.0.0.1:7890；實際 App 可能使用其他連接埠。開啟系統代理前，請檢查用戶端顯示的監聽位址，避免讓瀏覽器連到未監聽的連接埠。
4. 分別確認流量接管與分流。macOS 系統代理主要影響遵循代理設定的 App；TUN 則透過虛擬介面接收路由至該介面的流量。iOS 通常透過系統 VPN 設定接管流量。訂閱轉換本身不會授予這些權限。
5. 測試一次遠端更新。首次匯入成功後，手動更新一次，確認本機覆寫仍然存在、節點篩選沒有清空清單，且策略引用沒有失效。

訂閱格式常見問題