Clash 訂閱格式詳解:YAML、Base64 與訂閱轉換的正確用法
拆解 Clash YAML、通用 Base64 與各用戶端專屬格式的差異,說明訂閱轉換服務的運作原理、常見轉換失敗原因,以及如何在不同核心用戶端之間移植同一份訂閱。
READ →Clash 不是單一軟體,而是一套圍繞同一核心的用戶端家族。不同平台各有維護活躍的圖形用戶端,下載頁按平台分組列出可選項目、系統需求與安裝說明,以下入口可直達對應分組。
規則是 Clash 的核心機制:每條連線依網域、IP 所屬地區或處理程序名稱逐條比對,命中即送往對應出口,未命中則落入 MATCH 兜底規則。常用類型包括 DOMAIN-SUFFIX(網域尾碼)、DOMAIN-KEYWORD(網域關鍵字)、GEOIP(IP 地理資料庫)與 IP-CIDR(網段)。規則自上而下比對、先命中先生效,順序即優先權。與逐個手動套用代理設定相比,規則分流一次設定後長期生效:台灣本地網站直連不繞路,目標網站走代理,廣告網域直接拒絕,三類流量互不干擾。多數訂閱已內建成熟規則集,新手無須從零手寫。
規則比對後的去向由出口決定,共三種基本值:DIRECT 直連本地網路、PROXY 經代理節點轉發、REJECT 直接拒絕連線。PROXY 通常不是單一節點,而是一個策略群組:手動選擇群組(select)由使用者指定節點,自動測速群組(url-test)定期測延遲並選出最快節點,容錯移轉群組(fallback)在首選節點失效時自動切換備援節點。策略群組可以巢狀組合,例如「地區分組再套自動測速」。理解出口策略後,節點切換不再是玄學操作——在用戶端面板裡點選的每一項,都對應設定檔裡明確的群組與節點。
訂閱是一條 HTTP 連結,指向服務商託管的節點與規則清單。在用戶端的設定/訂閱頁貼上連結,用戶端會下載並解析為完整設定,之後依設定的週期自動更新,節點變動無須手動改檔案。格式上分兩類:Clash YAML 原生格式可直接匯入;通用 Base64 格式需先經訂閱轉換服務轉成 YAML 才能使用。匯入失敗時先核對三點:連結是否完整未被截斷、回傳內容是否為 YAML 而非網頁、用戶端核心版本是否支援設定中用到的協定。本站教學頁對匯入步驟有逐畫面截圖級說明。
系統代理只對遵守代理設定的應用程式生效,命令列工具、遊戲用戶端與部分桌面軟體會繞過它直接連網。TUN 模式會在系統裡建立一張虛擬網卡,把所有網路流量在網路層截取後交給 Clash 核心依規則處理,不依賴應用程式是否配合。啟用前提:Windows 需以系統管理員身分安裝服務元件,macOS 需授權系統延伸功能,Linux 需要對應權限。啟用後建議搭配 fake-ip 的 DNS 模式使用,避免 DNS 解析先於規則比對造成分流失準。日常瀏覽用系統代理即可,涉及全局接管時再啟用 TUN。
網域名稱解析發生在規則比對之前,DNS 設定不當會導致兩類典型問題:解析結果被汙染,直連流量拿到錯誤 IP 打不開網頁;或解析走了錯誤路徑,GEOIP 規則把代理流量誤判為直連。Clash 核心提供內建 DNS 服務,支援 fake-ip 與 redir-host 兩種模式:fake-ip 回傳保留段虛擬位址、由核心在建立連線時再決定真實解析路徑,搭配 TUN 使用最穩定;redir-host 行為更接近傳統解析,相容部分對 IP 敏感的應用程式。多數訂閱已內建可用的 DNS 設定,出現「已連線但打不開網頁」時優先檢查這裡。
Clash 最初是一款用 Go 語言撰寫的開源規則代理核心,以「一份 YAML 設定描述全部行為」的設計在技術社群獲得廣泛採用。原始儲存庫封存後,社群分支 Clash.Meta 延續開發並改名為 Mihomo,成為當前事實上的標準核心:協定支援更完整、規則類型更多、TUN 實作更完善,主流圖形用戶端均已切換至該核心。
圖形用戶端與核心是兩層關係:核心負責協定交握、規則比對與流量轉發,用戶端負責訂閱管理、介面互動與系統整合。Clash Plus、Clash Verge Rev、FlClash 等用戶端各自獨立開發維護,但讀取同一套 YAML 設定格式——這意味著訂閱與規則可以在不同用戶端之間直接移植,換用戶端不必重學一次設定。
核心與各用戶端的原始碼均託管在公開儲存庫,提交紀錄、議題討論與版本發布任何人都可查閱。版本更新由各專案社群驅動:核心修正協定與規則實作,用戶端跟進核心版本並迭代介面。本站下載頁的版本資訊與安裝包同步各專案的正式發布管道,不做修改分發。
設定格式是純文字 YAML,這帶來一個實際好處:任何設定問題都可以還原成「檔案裡哪一行寫了什麼」,可以備份、可以比對、可以在文章裡逐行講清楚。本站的教學與排錯文章全部基於這一格式展開,拿到自己的設定檔即可對照操作。
git clone https://github.com/MetaCubeX/mihomo.git
核心原始碼儲存庫。一般使用者無須編譯,直接在下載頁取得圖形用戶端即可。
下面四條是新手最常卡住的地方。它們的共同特徵是:表面症狀相似,根因卻分布在設定的不同層面,因此排查順序比具體操作更重要。遇到問題先判斷故障發生在哪一段——是用戶端沒能正常啟動、訂閱沒能正確解析,還是用戶端已經跑起來但流量走錯了出口——再針對該層動手,可以避免把原本可用的設定越改越亂。
一個通用的判斷方法:先看用戶端介面是否列出了節點。列不出節點說明問題在訂閱解析或設定格式;能列出節點但全部逾時,說明問題在節點或線路;節點延遲正常卻打不開網頁,問題基本落在系統代理、DNS 或分流規則這三處本機設定上。依這個次序走,絕大多數故障都能在幾分鐘內定位到具體某一層。
另外建議在動手改設定之前先備份目前可用的設定檔。YAML 是純文字,複製一份留底的成本極低,卻能保證任何一次改動失敗後都可以立刻退回到已知可用的狀態,而不是靠回憶去還原改過哪幾行。完整解法與逐步截圖請見常見問題頁與故障排查文章。
拆解 Clash YAML、通用 Base64 與各用戶端專屬格式的差異,說明訂閱轉換服務的運作原理、常見轉換失敗原因,以及如何在不同核心用戶端之間移植同一份訂閱。
READ →把網速慢拆成節點、線路、本機三層逐段排查:先用延遲測試與切換節點隔離問題,再檢查協定與連接埠選擇,最後核對系統代理、DNS 與分流規則是否拖慢了直連流量。
READ →啟動時顯示 bind: address already in use 的完整處理流程:用 netstat 與 lsof 找出占用 7890 連接埠的行程,判斷該結束行程還是改連接埠,並說明改連接埠後同步系統代理設定的步驟。
READ →