Clash 訂閱格式詳解：設定類型辨識、相容性差異與轉換原則
辨識 Clash、Mihomo 與通用節點訂閱的結構差異，了解轉換前應檢查的欄位與規則。
訂閱、設定與編碼並非同一層
排查 Clash 訂閱問題時，第一步不是尋找轉換工具，而是釐清連結、回應內容與用戶端設定之間的關係。訂閱連結只是取得內容的入口。用戶端請求該網址後，伺服器可能回傳完整 YAML 設定、僅包含節點的 YAML、逐行排列的分享連結，也可能回傳經過 Base64 編碼的文字。連結結尾是否帶有副檔名，通常無法準確判斷回應類型。
完整的 Clash 設定描述一條可執行的流量處理路徑。除了節點外，還可能包含監聽連接埠、代理群組、規則、規則集合、DNS、TUN、嗅探與設定提供器等部分。節點訂閱只負責提供「有哪些代理入口」，無法單獨決定網域應進入哪個策略群組，也不能取代本機的 DNS 與網路接管設定。
常見內容可分為以下四類：
- 完整設定：通常可看到
proxies、proxy-groups與rules。匯入後即可建立規則模式的基本執行鏈。 - 節點提供器設定：常見主體是一個
proxies陣列，供主設定中的proxy-providers引用，不一定能作為完整設定獨立執行。 - 通用分享連結清單：每一行都是一個協定連結，例如
ss://、trojan://或vmess://。能否直接匯入取決於用戶端的訂閱解析能力。 - 編碼後的文字：Base64 只是文字傳輸方式。解碼後仍須判斷內容是連結清單、YAML、JSON，還是服務端回傳的錯誤頁面。
從回應內容辨識設定類型
判斷格式時應查看訂閱請求實際回傳的正文，而不是只看網頁中的說明。可以使用瀏覽器開發者工具、用戶端更新日誌，或能顯示回應標頭與正文的命令列工具。若訂閱需要驗證，請避免將完整網址貼到公開日誌、截圖或線上分析頁面，因為查詢參數可能包含長期有效的存取憑證。
先確認回傳的是設定，而不是網頁
訂閱網址失效、驗證過期或存取頻率受限時，伺服器可能回傳 HTML 登入頁、錯誤頁或驗證頁面。若正文開頭出現 <!doctype html>、<html>，就不應繼續以 YAML 解析。HTTP 狀態為成功也不能單獨證明正文是有效設定，有些服務會用一般網頁顯示錯誤說明。
檢查 YAML 的頂層欄位
結構較完整的 Clash 設定可能包含以下骨架。具體欄位會隨核心與需求而變化，但代理群組引用與規則目標必須能夠完整對應：
mixed-port: 7890
mode: rule
log-level: info
proxies:
- name: Tokyo-01
type: trojan
server: edge.example.invalid
port: 443
password: example-password
sni: edge.example.invalid
proxy-groups:
- name: PROXY
type: select
proxies:
- Tokyo-01
- DIRECT
rules:
- DOMAIN-SUFFIX,example.org,PROXY
- MATCH,DIRECTproxies 定義節點，proxy-groups 將節點或其他策略群組組織成可選策略，而 rules 的最後一段則引用策略群組、節點名稱或內建動作。若規則指向 PROXY，設定中就必須存在同名策略群組或可用目標。名稱會區分字元與空格，轉換時任意改名會造成引用中斷。
辨識連結清單與編碼內容
逐行文字解碼後若大量出現協定前綴，通常屬於節點連結訂閱。連結中帶有伺服器、連接埠、驗證資訊與部分傳輸參數，但一般不包含完整規則體系。有些連結會將顯示名稱放在片段識別碼中；若解析器對百分比編碼或字元集的處理不同，匯入後可能出現節點名稱亂碼或重複。
不能只憑「文字看起來像一串隨機字元」就判定它是 Base64。先排除壓縮資料、JSON、HTML 與服務端提示，再使用符合字元集的解碼方式。完成解碼後仍須重新辨識格式，不能將成功解碼等同於設定可用。
| 觀察到的特徵 | 可能類型 | 下一步 |
|---|---|---|
| 同時出現 proxies、proxy-groups、rules | 完整的 Clash 或 Mihomo YAML | 檢查核心欄位的相容性與引用關係 |
| 只有 proxies 陣列 | 節點提供器內容 | 由主設定透過 provider 引用，或補齊策略與規則 |
| 每行以協定連結開頭 | 通用節點訂閱 | 使用支援相應協定的解析器產生節點項目 |
| 正文以 HTML 標籤開頭 | 登入頁或錯誤頁 | 檢查網址、驗證、狀態碼與重新導向 |
| 解碼後才出現 YAML 或連結 | 經編碼包裝的訂閱 | 繼續根據解碼後的實際內容判斷 |
Clash、Clash Meta 與 Mihomo 的相容邊界
「Clash 格式」並不是永遠固定的單一版本。早期 Clash 核心建立了常用的 YAML 結構，Clash Meta 在此基礎上擴充協定、規則、DNS、TUN 與路由能力，後續專案則使用 Mihomo 這個名稱。現在許多用戶端以 Mihomo 作為核心，但介面或訂閱提供方仍沿用 Clash 這個通用稱呼。
相容性通常代表新核心能讀取較多傳統欄位，但不表示任意 Mihomo 設定都能反向交給舊核心。設定中只要使用舊核心不認識的代理類型、傳輸參數、規則語法或 DNS 選項，啟動時就可能回報欄位錯誤，也可能忽略部分設定。轉換目標必須對應實際執行的核心，而不能只根據用戶端名稱判斷。
代理協定與傳輸參數
節點能否使用，取決於核心是否實作相應協定及其參數組合。即使兩份訂閱都包含同名協定，TLS 指紋、Reality、HTTP/2、gRPC、QUIC 或其他擴充參數的欄位名稱與支援範圍也可能不同。轉換器若不認識某個欄位，常見結果不是「自動相容」，而是刪除該欄位，或降級成無法連線的節點。
規則提供器的行為類型
rule-providers 不只是遠端檔案網址，還包括 behavior、格式、更新間隔與儲存路徑。常見行為有 domain、ipcidr 與 classical。網域集合不能直接當作 IP 網段集合使用，而經典規則集合則可承載帶有類型前綴的規則項目。主規則中的 RULE-SET 引用必須與提供器名稱一致。
DNS 與 TUN 屬於本機執行環境
DNS 與 TUN 設定與作業系統、權限、網路介面及用戶端實作緊密相關。節點訂閱中的伺服器資訊可以跨裝置遷移，但整段複製 TUN 介面名稱、路由排除項目、DNS 監聽位址或系統代理設定，往往會將來源裝置的前提帶到目標裝置。桌面系統可用的設定不一定適合伺服器，Android 用戶端也可能由介面接管 VPN 權限而忽略部分桌面欄位。
訂閱轉換前應檢查的六項內容
轉換的目標應是將來源資料對應至目標核心能理解的結構，而不是把所有內容壓縮成一個「能匯入」的檔案。開始轉換前，至少檢查以下六項。
- 確認目標核心。記錄用戶端使用的是 Mihomo、傳統 Clash 相容核心，還是具有自有解析層的行動用戶端。同一份訂閱在不同用戶端中的匯入結果可能不同。
- 確認來源範圍。判斷來源是完整設定、節點集合還是單一分享連結。節點集合轉換後通常仍需要主設定提供策略群組、規則與 DNS。
- 列出協定與關鍵欄位。檢查各種節點類型的驗證、TLS、SNI、傳輸方式、UDP 支援及擴充參數。轉換後應抽樣比對，而不是只比較節點數量。
- 檢查名稱引用。代理群組可以引用節點與其他代理群組，規則則會引用策略目標。重新命名、去重或字元正規化時，必須同步更新所有引用。
- 檢查規則語意。規則順序會影響結果，因為 Clash 會依設定順序由上而下比對，命中後即停止。轉換時重新排序規則可能改變流量路徑。
- 區分遠端與本機設定。節點與遠端規則可以依排程更新；連接埠、控制介面、DNS、TUN、區域網路監聽與驗證通常更適合由本機範本維護。
為什麼節點數量相同仍可能轉換失敗
節點數量只能證明解析器建立了相同數量的項目，不能證明每個項目的參數完整。轉換器可能保留伺服器與連接埠，卻遺漏 SNI、傳輸路徑或協定擴充；也可能自動為兩個同名節點加上後綴，導致原有策略群組仍引用舊名稱。驗證時應分別選擇不同協定的節點檢查，並查看連線日誌中的握手階段錯誤。
為什麼規則不能只靠文字串接
直接將兩份規則清單首尾串接，可能造成順序衝突。例如前方較寬泛的網域規則會提前命中，使後方的精確規則失效；IP 規則也可能觸發 DNS 解析，具體行為取決於規則類型與參數。合併時應先確定優先順序：本機例外規則通常放在較具體的位置，寬泛規則與最終兜底規則置後，並讓整份設定只保留清晰且可控的最終去向。
線上轉換服務的憑證界線
訂閱網址通常具備讀取節點設定的權限。將完整網址提交給第三方轉換服務，等同於讓該服務取得訂閱回應的存取能力。較穩妥的做法是在可信環境中使用本機轉換流程，或使用訂閱提供方明確提供的目標格式。若必須經過中介服務，應了解其請求方式、日誌策略與快取行為，並在處理後依提供方能力更新存取憑證。
建立可驗證、可回復的轉換流程
穩定的轉換流程應分開儲存遠端節點、本機主設定與產生結果。如此一來，訂閱更新時只需替換資料來源，不會覆蓋已驗證的 DNS、TUN 與規則結構。
步驟一：固定來源快照
儲存一次原始回應，記錄取得時間、回應類型與使用的目標核心。快照可用來排除「訂閱來源在排查期間發生變化」的干擾。儲存時應限制檔案存取權限，因為其中可能包含節點驗證資訊。
步驟二：解析而不改寫
先讓解析器輸出結構化結果，查看辨識出的協定、節點名稱與欄位。此階段不新增規則，也不進行批次重新命名。若某類節點無法辨識，應先解決來源與目標之間的協定相容問題，避免在後續範本中掩蓋錯誤。
步驟三：對應至本機主設定
將節點作為 proxy-providers 或明確的 proxies 資料接入主設定，再由本機主設定定義策略群組。使用提供器時，可讓策略群組透過 use 引用節點集合，減少每次訂閱變更後手動修改群組內清單的工作。
proxy-providers:
remote-set:
type: http
url: https://config.example.invalid/profile.yaml
interval: 21600
path: ./providers/remote-set.yaml
health-check:
enable: true
interval: 600
url: https://www.gstatic.com/generate_204
proxy-groups:
- name: PROXY
type: select
use:
- remote-set
proxies:
- DIRECT此範例用於說明結構關係。實際使用時，提供器回傳的內容必須符合目標核心要求；健康檢查網址、更新間隔與儲存路徑也應依網路環境調整。若訂閱來源只回傳完整設定，而不是提供器格式，不能只將網址放入 proxy-providers 就期待核心自動擷取節點。
步驟四：進行三層驗證
- 語法層：確認 YAML 縮排、清單層級、引號與欄位類型正確。包含冒號、井號或特殊字元的名稱，適合以引號包住。
- 引用層：確認代理群組引用的節點或提供器存在，規則目標存在，規則集合名稱與提供器一致。
- 執行層：啟動後查看設定載入、提供器更新、DNS 查詢、節點握手與規則比對日誌，分別測試直連與代理流量。
步驟五：逐項啟用 DNS 與 TUN
先在一般系統代理或明確的代理連接埠下驗證節點與規則，再啟用複雜的 DNS 設定，最後依需求測試 TUN。若同時修改節點格式、DNS 與 TUN，將難以判斷連線失敗的原因。每次只增加一組變數，並保留上一份可啟動的設定。
匯入失敗與節點遺失的排查順序
訂閱更新提示解析錯誤
先查看錯誤發生在下載階段還是 YAML 解析階段。下載階段應重點檢查狀態碼、重新導向、驗證與回應正文；解析階段則重點查看具體行號附近的縮排、冒號、清單符號與字元編碼。YAML 使用空格表示層級，定位字元或錯位縮排都可能導致整個檔案無法載入。
匯入後沒有節點
確認回應是否確實是節點集合。若檔案只有 proxy-providers 定義，它描述的是如何繼續取得節點，不代表目前檔案內已存在 proxies。若檔案只有規則集合，本來就不會產生節點。還應查看用戶端是否將完整設定匯入與獨立節點訂閱功能分為兩個入口。
節點存在但策略群組為空
靜態策略群組的 proxies 清單需要填入節點名稱，而提供器策略群組則需要透過 use 引用對應提供器。若轉換器修改了節點名稱卻未更新群組內引用，用戶端可能回報目標不存在。正規表示式篩選型策略群組還要檢查過濾表達式，過於嚴格的篩選會排除所有節點。
設定能啟動但所有連線都失敗
先避開複雜規則，直接選擇一個節點進行連通測試。檢查系統時間、伺服器網域解析、連接埠可達性、TLS 伺服器名稱與傳輸參數。若只有特定協定失敗，應重點比對轉換前後的協定擴充欄位；若所有節點同時失敗，則優先檢查訂閱是否過期、網路出口、DNS 與系統代理接管狀態。
規則模式下流量去向不如預期
開啟規則日誌並確認實際命中的規則。不要只根據規則檔中「應該存在」的項目推斷結果，因為更前面的規則可能已完成比對。檢查規則集合是否更新成功、規則行為類型是否正確、策略目標是否指向預期群組，並確認最終兜底規則沒有被放得太前面。
同一份訂閱在不同裝置上的結果不同
比對用戶端版本、核心名稱、核心版本與訂閱匯入入口。有些用戶端會在匯入前執行自有轉換，另一些則將 YAML 原樣交給核心。行動裝置還可能限制背景更新、VPN 接管與本機檔案存取。應從兩端匯出實際生效的設定或查看啟動日誌，而不是只比較訂閱網址。
Base64 訂閱可以直接當作 Clash 設定使用嗎？
不能只根據編碼方式判斷。Base64 解碼後可能是逐行節點連結，也可能是 YAML 或其他文字。用戶端必須同時支援解碼後的內容格式，以及其中使用的協定。
Mihomo 設定可以直接匯入舊版 Clash 核心嗎？
基礎欄位可能相容，但 Mihomo 擴充的協定、規則、DNS 與 TUN 欄位不一定能被舊核心辨識。應依舊核心的支援範圍刪減或對應，並重新驗證規則與連線。
訂閱轉換後需要保留原本的規則嗎？
取決於轉換目標。若只需要節點資料，可以由本機主設定統一維護規則；若要遷移完整設定，則必須保留規則順序、規則集合與策略目標之間的關係，不能只複製規則文字。
為什麼訂閱更新會覆蓋手動修改？
直接編輯下載的訂閱檔案時，下次更新通常會以遠端內容重新寫入。可以將裝置相關設定放入獨立主設定，透過提供器引用遠端節點，或使用用戶端支援的覆寫機制。
格式辨識的最終檢查表
訂閱轉換完成後，可以沿著固定流程複核：確認回應不是網頁錯誤，辨識真實內容類型，核對目標核心，抽查協定欄位，驗證節點與策略群組引用，檢查規則順序，再分別測試 DNS 與 TUN。遇到問題時回到最早出現異常的層級，不要反覆更換轉換工具。
對多數長期使用情境而言，最穩固的結構不是將所有選項塞進遠端訂閱，而是分離更新頻繁的節點資料與裝置相關的本機設定。如此既能持續接收訂閱變更，也能保留已驗證的規則鏈、連接埠、DNS 與網路接管方案。