分流規則到底在做什麼？
在 Clash 系家族（含以 Mihomo 為核心的現代用戶端）裡，分流規則對應設定檔中的 rules 區塊。你可以把它想成一連串「如果…就…」的判斷題：程式從陣列最上方開始，拿目前這筆連線的特徵（常見是網域名稱、IP、地理區域等）去比對，一旦命中某一條，就立刻採用該條後方指定的動作，不再往下看。
動作通常會寫成某個 proxy-groups 的名稱，例如 PROXY、Auto，或是內建關鍵字 DIRECT（直連）、REJECT（拒絕）。因此，規則寫得好不好，一半取決於語法是否正確，另一半則取決於順序是否符合你的意圖。
若你完全沒碰過 YAML，只要先記住兩件事：rules 是一個清單，每一行（每一條）都是字串；以及越具體、越想優先處理的條件要放越上面。接下來我們會用幾個最常見的前綴，帶你寫出第一組可執行的規則。
動手前：先確認策略組名稱對得上
規則列的最後一個欄位，幾乎永遠是「要把這筆流量丟給誰」。若你寫 PROXY，但設定檔裡根本沒有名為 PROXY 的 proxy-groups，核心在重載時就會報錯，或出現難以理解的行為。建議你先在圖形介面或文字編輯器中搜尋 proxy-groups:，把實際存在的組名抄到小紙條上，再回來寫規則。
另一個新手常見誤會，是把「規則模式」當成節點名稱。其實規則只負責分派到哪一個策略組；真正選哪一條線路、要不要自動測速，是策略組內部的邏輯。先把這層分工想清楚，之後閱讀日誌會輕鬆很多。
若你希望先建立對全站文件的印象，可先瀏覽本站的使用說明與文件，再回到本文專注在 rules 語法本身。
一條規則長什麼樣子？
多數古典寫法的規則，可以粗分成三個欄位：類型前綴、比對值、動作或策略組名。欄位之間用英文逗號分隔，逗號後面是否留空格取決於可讀性，核心通常兩者皆可解析，但維持一致風格較利於版本控管。
下面是一個刻意精簡、可直接貼進測試環境骨架的範例（註解僅用英文，方便你複製到正式檔案時保留或刪除）。請把 MY_PROXY_GROUP 換成你檔案中真實存在的策略組名稱。
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- DOMAIN,announce.example.org,MY_PROXY_GROUP
- GEOIP,CN,DIRECT
- MATCH,MY_PROXY_GROUP閱讀順序如下：若連線的網域結尾符合 example.com，直連；若是精確主機名 announce.example.org，改走你指定的策略組；若 IP 落在資料庫標示為 CN 的區段，直連；最後所有還沒被前面規則接住的流量，全部丟給 MATCH 後方那一組。
新手最該認識的五種前綴
DOMAIN：精準比對單一主機名，適合處理少數你非常確定的網域。DOMAIN-SUFFIX：比對網域後綴，適合一次涵蓋整個網域樹下的大量子網域，例如影音或雲端服務的官方網域。兩者差異在於「要不要連子網域一起算進來」，寫錯時常見症狀是主站可走、CDN 子網域卻落進另一條規則。
DOMAIN-KEYWORD：只要主機名稱中包含某段字串就命中，威力強但誤傷面積也大，建議只在非常小的關鍵字上使用，並搭配日誌觀察是否誤判其他站台。
GEOIP：依 IP 地理資料庫判斷區域，典型寫法是讓「判定為本國／區內」的流量直連，其餘再走代理。請留意資料檔版本與更新來源，過舊的 GeoIP 可能把部分 CDN 節點標錯區域，造成「以為會直連卻走了代理」的錯覺。
MATCH：永遠命中，因此必須放在整份 rules 的最底層，當作兜底。若你把 MATCH 放在中間，後方所有規則都會變成死碼，這也是新手設定「怎麼改都沒反應」的第一名原因。
順序：為什麼「上面贏下面」這麼重要？
假設你先寫了一條很寬鬆的規則，把所有 DOMAIN-KEYWORD,google 都丟去代理，後面才想針對 fonts.googleapis.com 直連。由於關鍵字規則在上面先命中，後面的直連條件永遠等不到機會。解法不是把直連寫得更聰明，而是把更精確的例外往上搬。
實務上可遵循一個簡單口訣：例外在前、通則在後、MATCH 收尾。例如公司內網、網路銀行、區域免流網域，通常都應該早於寬鬆的 GEOIP 或關鍵字規則。
當你從服務商一鍵訂閱拿到預設規則時，也建議用同樣的眼光掃過一次：哪些集合涵蓋面極大、是否壓住了你想自訂的細節。必要時把自訂段落放在訂閱模板會保留的位置，避免每次更新訂閱就被覆寫。
直連與代理：什麼時候該用 DIRECT？
DIRECT 代表讓系統依一般路由出去，不經由 Clash 選定的出站線路。對區內網站、區域 CDN、或必須露出住宅／公司 IP 的服務，直連通常較自然。相對地，閱讀跨區內容、連線品質受擾動較大的網站，才適合丟給代理策略組。
新手最常犯的錯，是為了「全部走代理比較安心」而把所有規則都指到代理組，結果區內影音或支付頁面反而變慢、甚至被風控。較健康的起點，是先讓「明確需要跨區的網域」走代理，其餘維持直連或交給訂閱模板處理。
若你之後想把大量網域清單改為遠端維護，可銜接閱讀本站的Rule Providers 進階教學，把資料與策略骨架拆開，較容易長期維護。
YAML 新手坑：縮排、引號與複製來源
YAML 對縮排敏感，混用空格與制表符（Tab）可能導致整份檔案解析失敗。建議在編輯器開啟「顯示空白字元」功能，並統一使用兩個或四個空格作為一層縮排，與你手邊範本保持一致。
當網址或關鍵字包含特殊符號時，適度使用引號包起來，可避免被誤判成 YAML 結構。若你從論壇或聊天室複製片段，也要留意是否夾帶了「全形逗號」或不可見的控制字元，這類問題在重載失敗時很難肉眼看出，卻極常發生。
完成小幅度修改後，請養成先備份整份設定再重載的習慣。多數圖形介面支援一鍵匯出；純文字工作者則可使用版本控制，讓每次變更都可回滾。
怎麼知道自己寫對了？用日誌對照
規則是否命中，最可靠的證據在連線日誌：你應該能看到目標網域或 IP、命中的規則類型、以及最後走向哪個策略組。若日誌顯示的流量類型與你想像不同，優先懷疑 DNS 解析結果與規則比對所使用的欄位是否一致，而不是急著再加十條關鍵字。
建議的除錯順序是：先確認策略組名稱拼字無誤，再檢查命中順序，最後才調整 DNS 或進階功能（例如 fake-ip、TUN）。把範圍縮小，每次只改一個變因，你會更快定位問題。
若你希望把測試環境與日常環境分開，可在不同設定檔中維護兩份規則骨架，透過用戶端快速切換，降低實驗時誤傷主要流量的風險。
三個「可立刻用上」的小配方
配方一：讓單一測試網域固定走代理。在規則陣列前段加入 DOMAIN,lab.example.net,MY_PROXY_GROUP，重載後用瀏覽器開啟該站，並於日誌確認命中列與策略組一致。
配方二：讓家用監視器或 NAS 管理介面永遠直連。使用 DOMAIN-SUFFIX 或精確 DOMAIN 指到 DIRECT，並確保這條規則位於任何寬鬆的代理規則之前，避免被關鍵字規則提前接走。
配方三：在兜底之前插入本機區網例外。若你使用 IP 規則（例如 IP-CIDR），可把區網段放在 GEOIP 與 MATCH 之間，讓內部服務不經代理；實際前綴名稱請以你所使用的核心文件為準，並留意 IPv4／IPv6 兩套位址家族是否都要涵蓋。
圖形介面使用者的實務建議
多數人並非直接編輯整份 YAML，而是在「覆寫」「片段」或「Merger」區塊插入自訂段落。無論介面如何稱呼它，請記得最後送進核心的仍是一份合併後的設定；你仍應理解 rules 在合併結果裡的相對順序。
若介面提供「預覽完整設定」功能，請在每次大改後打開一次，確認你的自訂規則沒有被模板插到錯誤深度，或與訂閱自動段落發生重複。
安裝與版本選擇可參考本站的用戶端下載頁，先確保圖形介面與核心版本彼此相容，再啟用進階規則功能，可避免「介面顯示成功、核心其實拒絕載入」的落差。
寫完基礎規則之後，可以往哪裡延伸？
當你熟悉 DOMAIN 與 GEOIP 的搭配後，下一步通常是學會使用 RULE-SET 與 rule-providers，把長清單移出主設定檔；或進一步理解 DNS 與 fake-ip 對命中結果的影響。這些主題各自值得獨立文章，本文刻意停在「你能安全改寫的最小範圍」。
若你開始遇到「瀏覽器正常、某些應用程式卻繞過代理」的情況，可能與 TUN 或系統路由有關，可搭配閱讀本站 TUN 相關教學，但請在完成基礎規則理解後再切換，降低一次調整太多變因的壓力。
關於開源專案與下載來源
Clash 生態的核心與各圖形介面多為開源專案，GitHub 上的儲存庫適合查證授權條款、閱讀變更日誌或提交 issue。一般使用者若目標是穩定取得已打包的用戶端與一致的操作說明，建議以本站整理的入口為主；將「安裝包取得」與「原始碼查閱」分開理解，較不容易混淆發布頁上眾多檔名與分支。
總結：先把「順序與名稱」寫對，再談進階
自訂分流規則的本質，是用一份由上而下的清單，把連線特徵映射到你已定義好的策略組或內建動作。對新手而言，最重要的不是背下所有前綴，而是建立三個習慣：確認策略組名稱存在、把精確例外放在寬鬆通則之前、以及永遠用 MATCH 收尾。
相較於在社群片段中東拼西湊，選擇核心版本清楚、能安全合併自訂片段的用戶端，通常能減少語法不相容與規則被覆寫的挫折；搭配日誌逐步驗證命中結果，也比一次堆疊大量關鍵字規則更穩健。若你希望在一套清楚流程內完成安裝、更新與規則調校，不妨從本站取得適用你平台的版本，再依本文步驟寫出第一組屬於你的分流邏輯。