為什麼 Clash 愛用 YAML，而不是點選式設定就好？

多數圖形化用戶端最後仍會把結果輸出成一份 config.yaml（或同等結構）。原因很實際：文字格式便於版本管理、差異比對與自動合併，也方便在訂閱更新與個人覆寫之間切換責任界線。對使用者來說，學會讀 YAML 並不代表每天都要手刻上千行，而是能在「機場範本突然改名」「策略組引用錯誤」「規則打不中」時，快速看出問題落在哪一段。

本文從語法心智圖出發，串起 proxies（節點定義）、proxy-groups（策略組／選路邏輯）與 rules（分流條款）三者如何互相指名；並以 Clash 生態系常見的核心實作（含 Mihomo／Meta 相容寫法）為主軸說明。讀完後，你應能自信地調整一份中等複雜度的設定檔，並知道各類策略組適合什麼場景。

適用範圍：下列欄位名稱以多數現行用戶端產生的設定為準；極舊版本或分支核心可能缺少部分策略組型態。若載入報錯，請以你安裝版本對應的文件為最終依據。

YAML 入門：你最少要懂的縮排與清單

YAML 靠縮排層級表達父子關係：同一層一定要共用相同數量的空白（建議只用空白，不要用 Tab）。清單項目以 - 開頭，後接一個空格，再寫鍵值對或純量。下列是極度精簡、僅說明語感的示意（欄位名可隨你的環境變動）：

# Illustrative structure only
port: 7890
socks-port: 7891
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: "demo-node"
    type: ss
    server: example.com
    port: 443
    cipher: aes-128-gcm
    password: "******"

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

rules:
  - MATCH,Proxy

上例中，proxies 底下每一個 - 代表一個獨立節點；proxy-groups 下的 proxies: 清單則引用先前定義的 name。任何一處拼錯或層級跑掉，都可能讓整份設定無法解析，因此在複製片段時，務必連縮排一起貼上，並在編輯器開啟「顯示空白字元」輔助檢查。

設定檔骨架：port、mode、dns 與日誌等前置區塊

在深入策略組之前，先確認服務如何對外提供埠號與運作模式。port／socks-port／mixed-port 之類欄位決定本機要開哪個 HTTP／SOCKS／混合代理入口；allow-lan 則關係到是否允許區域網路其他裝置連線進來（涉及安全，開啟前請評估防火牆與信任範圍）。

mode 常見值包含 rule、global、direct 等，決定預設走規則分流還是全域代理。新手若尚未弄懂 rules，可能會暫時切到較單純的模式除錯，但長期仍建議回到 rule，才能依網域與使用情境細緻分流，而不是整包流量長期鎖在同一路徑。

許多範本也會包含 dns 區塊與進階的解析行為設定。DNS 與分流規則的命中環環相扣：若你不理解 fake-ip、enhanced-mode 等選項，可能在「規則看起來對了，瀏覽器卻連錯站」的迷霧裡打轉。入門階段可先把重點放在 proxies 與 proxy-groups 的命名一致性；待規則行為穩定後，再回頭細調 DNS。

proxies：節點是整份設定的原子

每一個 proxies 清單元素描述單一可連線的出口，至少包含 name、type、遠端位址與認證資訊。常見 type 可能是 ss、vmess、trojan、snell，或由核心版本延伸的其它協定。name 是後續所有引用的唯一鍵；替換訂閱後若名稱大洗牌，記得同步調整策略組清單，否則會出現「找不到節點」錯誤。

實務上你可以把 proxies 看成資料表：列是節點，欄是屬性。複製別人片段時最常犯的錯是漏帶必要鍵（例如某些協定要求額外 uuid、alterId、TLS 相關欄位）或層級少縮一排，導致該節點整段被解析器忽略。若節點數量非常龐大，建議不要在主檔直接手刻全部內容，而讓訂閱或 proxy-providers（若你的版本支援）承擔資料來源，你再額外插入少數手動維護名稱即可。

proxy-groups：把節點組成「可選策略」

proxy-groups 定義策略組：給 UI 一個下拉選項或在規則裡一個可被指向的名稱。每一組同樣需要唯一的 name，以及 type 描述這組要用什麼邏輯挑節子清單。proxies: 子清單中可列出節點名稱、另一個策略組名稱，或系統保留字如 DIRECT、REJECT（依核心而定）。

初學者可先把事情想成兩層：底層 proxies 負責真正的連線參數；上層 proxy-groups 負責把多個底層出口包裝成一個語意名稱。例如 自動選路、影片串流、公司 VPN 這類中文或英文別名，應該出現在策略組的 name，再由 rules 最後一欄指向它們——而不是直接把某個 IP 寫進 rules。

select：最直覺的手動選擇

type: select 會列出所有候選，讓使用者或前台面板手動點選當下要用的路徑。優點是什麼都透明，缺點是要自己切換。它適合明確需要固定在某一節點的操作（例如銀行網址必須固定出口 IP），或當你尚在觀察延遲與路由特性、尚未放心交給自動化演算法時。

url-test：用量測網址做延遲自動挑選

type: url-test 會週期性對候選節點發出測試請求，依延遲或可用性指標挑出當前最佳者。設定時通常要提供 url（測試目標）、interval（多久測一次）等欄位；有些版本還支援逾時與容忍度參數。它適合「一組伺服器隨時可能掛點或忽快忽慢」的情境，讓客戶端幫你換線。

需要注意的是：測得「延遲低」不完全等於「體感最好」，尤其當測試 URL 與你實際瀏覽的服務位於不同網路路徑時。若長時間遇到「測試漂亮但看影片仍卡」，可嘗試調整測試目標或改以 fallback 控制優先序。

fallback：依清單順序找到可用即止

type: fallback 的典型語意是由上而下試錯：當前排節點不可用時換下一個。相較 url-test 的「比誰快」，fallback 更重視你心儀的優先序。在網路品質波動大、只想保證「至少有線」而非追求極致最佳化時，fallback 往往最直覺。

load-balance：分散負載的多出口用法

type: load-balance 嘗試把連線分散到多個節點，以降低單點壅塞或關聯封鎖風險。實作細節與可用參數依核心版本而異，可能涉及雜湊欄位或一致性策略選項。對一般家用使用者而言，除非你真的理解其副作用（例如部分網站對 IP 輪換敏感），否則不必一開始就上 load-balance；但在多人共用或小企業拆分流量時，它有其價值。

relay：鏈式多跳的進階拼圖

type: relay 讓流量依序穿越多個代理，形成鏈路。好處是可疊加不同供應商或不同地區的能力；壞處是任一-hop卡住就整條失效，除錯也較痛苦。除非你明確知道為何需要第二跳，否則入門階段可先跳過。

# Sketch — names are examples only
proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - AUTO
      - NODE-A
      - DIRECT
  - name: AUTO
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - NODE-A
      - NODE-B
  - name: FALLBACK-CHAIN
    type: fallback
    proxies:
      - NODE-A
      - NODE-B
      - DIRECT

rules 如何指向策略組：命名一致是最低成本的安全網

rules 區段是一連串條件句，語意近似「若流量符合某特徵，就採用某策略」。每一列寫法依規則類型而異，但最後一欄幾乎永遠是策略名稱：可能是 DIRECT、REJECT，或你在 proxy-groups 定義過的 name。因此，當你把策略組從 Proxy 改名成 MAIN，卻忘記同步修改規則列，就會出現看似詭異的未命中或載入錯誤。

規則由上而下比對、先命中先贏——這點與分流專題文章相通。你在調整 YAML 時，心中要同時有兩條軸線：垂直的優先序（誰先被檢查）與水平的策略名稱是否仍存在於 proxy-groups。把個人最常改的幾條規則放在清單前段，能减少被後方寬泛規則「吃掉」的機率。

訂閱、覆寫與本機片段：實務上的檔案治理

多數使用者並非每天從零撰寫 YAML，而是匯入機場訂閱後再局部修改。不同用戶端對「訂閱檔」與「使用者覆寫檔」的支持度不一：有的會在更新訂閱時重新產生整份主設定，覆寫掉你手動插入的區塊；有的允許 Merge 規則。無論如何，你應建立一個習慣：把個人必備片段另外備份在版本庫或筆記系統，一旦發生被覆寫，能在五分鐘內貼回正確位置。

若團隊內多人共用一份策略，也建議約定命名前綴（例如 corp-）避免與訂閱自動產生的節點撞名；並對 url-test 的測試目標达成一致，以免每人都用不同 URL，導致挑路結果不具可比性。

除錯心法：從「能否載入」到「挑路是否合理」

  1. 先用語法檢查與核心提示定位錯列：多數用戶端會告知第幾行附近解析失敗。
  2. 核對三點一致：proxies.name、proxy-groups.proxies 清單、rules 末欄引用是否同步。
  3. 策略組型態專用欄位是否缺漏：尤其 url-test／fallback 常有各自必填鍵。
  4. 變更後重載或重啟：避免舊設定留在記憶體內造成假陽性。
  5. 把問題縮小為單一變因：同時改 DNS 與十條規則只會讓除錯地獄更深。

安全與合法性：本文僅說明設定檔結構與策略組觀念，不提供任何未經授權的網路使用建議。請在所在地法令、契約與公司政策範圍內操作；對來路不明的訂閱與範本保持警覺。

常見問題與延伸思考

我需要把所有節點都塞進同一個 url-test 嗎？不一定。過大的候選池會讓測試時間拉長，也可能把地區差異很大的節點硬比在一起。實務上可用多個策略組分層：例如「亞洲組」「歐洲組」各自 url-test，再由上層 select 手動或自動決定要用哪一洲的結果。

手寫 YAML 會不會比 GUI 更容易出錯？初期確實如此，但熟悉後，純文字反而讓你能用搜尋或版本比對快速找出差異；GUI 若隱藏細節，有時更難察覺「其實策略組名字已變」。兩者可並行：平常 GUI 調整，關鍵時刻仍要回頭閱讀產生的檔案。

寫完 YAML，再來為什麼仍建議用整合度高的 Clash 用戶端？

有些工具要嘛把節點清單管得很漂亮，卻不讓你看最終合成 YAML；要嘛乾脆不走規則模式，長期使用只能全域開關。另有一批腳本方案每次更新都要手動重拼片段，稍不留神就把個人覆寫衝掉。當你開始玩轉 url-test、fallback、甚至多份策略並存，「看得到完整設定、改得動每一行、又能在更新訂閱時維持結構」變成硬性需求。

若你希望把本文提到的觀念落在穩定且持續跟上核心演進的介面上，不妨改用仍深度整合當前主流能力、並針對中文使用者整理過操作流程的 Clash 官方用戶端：訂閱匯入、策略組切換與規則編修能對應到同一份看得見的結構，遇到錯誤訊息時也較容易沿著「節點 → 策略組 → 規則」路徑依序排查。相比之下，純靠片段拼湊或過度簡化的面板，往往在你最需要細調策略組參數時顯得力不從心。

你可以先從只調整一組 select 與幾條規則開始，確認命名與縮排都無誤後，再逐步導入 url-test 這類自動化型態，讓設定檔的複雜度與你的網路環境成長速度成正比。

立即免費下載 Clash，開啟流暢上網新體驗 →