規則列結構：類型、比對內容、出站策略

Clash 自訂規則寫在設定檔的 rules 清單中。FlClash 使用 mihomo 核心時，會依據請求資訊逐條判斷，符合條件後交由指定策略處理。請先確認用戶端已選取要修改的設定檔，並將出站模式設為「規則」。全域模式和直連模式不會依照這份一般規則清單進行分流。

大多數規則採用三段結構：規則類型,比對內容,出站策略。各段以英文逗號分隔，YAML 清單項目則以連字號和空格開頭。以下範例可併入現有設定：

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,REJECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,DIRECT
  • DOMAIN 是類型，代表比對完整網域；login.example.com 是條件；DIRECT 代表直連。
  • REJECT 是拒絕策略。第二行用來示範封鎖，實際套用前請確認要封鎖的網域範圍。
  • no-resolve 是可選的第四段參數，適用於相關 IP 規則，並非策略名稱。
  • MATCH 是最終兜底規則，沒有比對內容，因此只有兩段。

DOMAIN 與 DOMAIN-SUFFIX：精確網域與網域後綴

只要調整單一登入入口、API 或下載網域，優先使用 DOMAIN。若要涵蓋主網域及其所有子網域，則使用 DOMAIN-SUFFIX。這兩種規則比對的是主機名稱，不是瀏覽器網址列中的完整 URL。

規則可比對的主機名稱範圍說明
DOMAIN,api.example.com,DIRECTapi.example.com不包含其子網域
DOMAIN-SUFFIX,example.com,DIRECTexample.com、api.example.com主網域及其子網域
DOMAIN-KEYWORD,example,DIRECT主機名稱中含有 example 的網域涵蓋範圍較廣，可能影響無關服務

網域規則不填寫通訊協定、路徑或連接埠

造訪 https://api.example.com:8443/v1/status 時，網域規則的比對內容仍是 api.example.com，而非整段網址。規則中也不必寫 *.example.com 表示後綴；使用 DOMAIN-SUFFIX,example.com,DIRECT 即可。

若只想依連接埠調整流量，可考慮使用 DST-PORT。例如 DST-PORT,8443,DIRECT 會比對目標連接埠為 8443 的請求，不限於特定網域。若要同時限制網域和連接埠，請查閱目前 mihomo 版本的邏輯規則語法，不要任意把兩個條件拼成一般三段規則。

網域是否可見，決定規則能否命中

透過 HTTP Proxy 或 SOCKS 傳遞網域時，核心通常能取得主機名稱。TUN 接管的連線則可能一開始只顯示目標 IP；能否還原網域，也與 DNS 模式、對應紀錄及嗅探設定有關。若連線詳細資料中只有 IP，新增網域規則未必會立即生效；請先確認用戶端實際辨識到的目標資訊。

IP-CIDR 與 no-resolve：位址範圍及解析時機

IP-CIDR 用於 IPv4 位址範圍，IP-CIDR6 用於 IPv6。CIDR 中斜線後的數字代表前綴長度：192.168.50.0/24 涵蓋 192.168.50.0 到 192.168.50.255；192.168.50.10/32 則只比對一個 IPv4 位址。這不是連接埠範圍。

rules:
  - IP-CIDR,192.168.50.10/32,DIRECT,no-resolve
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - MATCH,DIRECT

上方的 IPv6 規則涵蓋 fd00::/8，常見於本機配置的 ULA 位址。這裡僅示範特定網段，並非完整的內網直連清單。實際設定應依據區域網路、VPN 及遠端工作網段調整，避免將需要透過 Proxy 或專用通道連線的位址一律設為直連。

no-resolve 的實際作用

請求帶有網域但尚未取得目標 IP 時，IP 類規則可能會觸發 DNS 解析，以判斷目標位址是否落在指定網段。加上 no-resolve 後，該規則不會為了自身的 IP 比對而主動觸發這次解析；若請求已帶有目標 IP，仍可進行比對。

  • 這不代表停用 DNS，也不表示整條連線都不會解析網域。
  • 前面的規則可能已觸發解析，DNS 對應紀錄或入站連線也可能已提供目標 IP。
  • 若原本希望某個網域透過解析結果命中 IP 網段，加上此參數後，請求可能會繼續套用後續規則。

因此，區域網路位址規則常搭配 no-resolve，減少為了判斷網段而額外解析外部網域的機會；若規則需要依據解析結果分類，請先確認是否真的需要這個參數。

比對順序：由上往下，首次命中即停止

Clash 規則不會自動依網域長度或網段大小排序。一般規則會依設定清單由上往下檢查，命中第一條後便決定策略。即使規則更精確，若放在後面，仍可能被前面的寬泛規則攔截。

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,REJECT
  - MATCH,DIRECT

在這份清單中，login.example.com 會先命中第一條並直連；cdn.example.com 會命中第二條並遭拒絕；其他未命中的請求則套用最後的直連兜底規則。若將前兩條對調，登入網域也會被後綴規則拒絕。

建議依序整理例外、分類與兜底規則

  1. 明確例外：單一網域、單一主機位址等特殊處理，應放在對應的廣泛規則之前。
  2. 業務分類：依預期優先順序排列網域後綴、規則集、地區或網路分類。
  3. 最終兜底：將 MATCH 放在清單末尾，明確指定其餘流量的出站策略。

訂閱若已有完整規則集，新增規則時不應直接加在檔案末尾。放在 MATCH 後面的規則不會有比對機會。若用戶端提供「前置規則」、「追加規則」或覆寫功能，請確認合併後的實際位置，而非只看編輯器中已儲存的行數。

RULE-SET：分開管理規則內容與出站策略

網域數量增加後，可使用 mihomo 的 rule-providers 管理規則集，再以 RULE-SET 引用。規則集保存比對內容，主設定檔則決定命中後使用哪個策略。以下範例使用本機檔案，適合先確認結構，再決定是否接入遠端更新來源。

主設定檔：宣告提供者並加入規則清單

rule-providers:
  local-work:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-work.yaml

rules:
  - RULE-SET,local-work,DIRECT
  - MATCH,DIRECT

local-work 是規則提供者名稱，引用時必須保持一致。相對路徑以核心的工作目錄為基準，不一定是下載資料夾。FlClash 在行動系統上還會受到應用程式檔案存取權限限制，不能只把檔案放在任意目錄，就假定核心讀得到。

規則集檔案：只寫比對條件

payload:
  - DOMAIN,portal.example.com
  - DOMAIN-SUFFIX,example.net
  - IP-CIDR,192.168.50.0/24,no-resolve

以下是 behavior: classical、format: yaml 對應的檔案內容。每個項目都不必填寫 DIRECT 或策略組名稱，出站策略由主設定檔中的 RULE-SET,local-work,DIRECT 統一指定。請勿將完整的一般三段規則原樣複製到此檔案。

  • behavior: domain 用於網域集合，內容格式與上方的 classical 範例不同。
  • behavior: ipcidr 用於 IP 網段集合，不可混入一般網域規則。
  • 使用 HTTP 類型的提供者時，必須設定可連線的 url；也可用 interval: 86400 設定每 86400 秒更新一次，也就是 24 小時。

更新規則集和更新訂閱是兩回事。更新訂閱會更新主設定檔，規則提供者則更新對應的規則資料。若規則集未載入，請先查看提供者的錯誤記錄及檔案格式；反覆重新整理訂閱無法修正格式錯誤的規則檔。

FlClash 設定與驗證：檢查生效設定和新連線

自訂規則是否生效，應以核心實際載入的設定和連線記錄為準。不同版本的用戶端，編輯或覆寫入口名稱可能不同；請先開啟 FlClash 的「設定」頁面，確認目前選取的項目，再透過該項目的操作選單查看可用的編輯功能。只使用確實存在的編輯入口進行修改，並另外確認訂閱更新後如何保留變更。

  1. 保留原始設定：匯出或複製目前的設定，並記下原本的出站模式及策略組選擇。遠端訂閱更新可能會覆蓋直接編輯的內容。
  2. 每次只新增少量規則：先加入一條精確網域規則，放在相關的廣泛規則及 MATCH 之前；若已有 rules，請合併清單，不要重複建立同名的頂層鍵。
  3. 套用並查看記錄：儲存後依用戶端提供的方式重新載入設定。若發生解析失敗、策略未知或讀取檔案失敗，請先排除錯誤再測試連線。
  4. 使用新連線測試：關閉原有頁面或相關連線後，再重新送出請求。HTTP/2、HTTP/3 及應用程式的連線池可能重複使用既有連線；新增規則不會讓舊連線自動重新選擇出站。
  5. 核對連線詳細資料：在「連線」頁面查看目標主機、目標 IP、命中的規則及出站鏈。不同版本顯示的欄位可能不同，可搭配記錄核對規則類型與策略名稱。

TUN 負責將更多應用程式流量導入核心，規則則負責分類進入核心的請求。啟用 TUN 不會自動提高特定規則的優先順序。若連線清單始終找不到目標請求，請先檢查流量接管、應用程式的 Proxy 設定及路由，再繼續修改規則。

常見錯誤：依照症狀找出規則問題

症狀常見原因處理方式
儲存後無法載入設定使用全形逗號、Tab 縮排，或策略名稱不存在改用英文標點和空格縮排，並檢查記錄指出的行
規則存在卻始終未命中規則放在 MATCH 或更廣泛的規則之後將具體例外移到相關規則之前
主頁面直連，但資源仍使用其他策略頁面呼叫了其他網域檢查連線記錄中的圖片、API 及資源主機名稱
IP 規則未套用到網域請求尚未取得目標 IP，且設定了 no-resolve確認解析狀態，或改用精確的網域規則
更新訂閱後自訂內容消失遠端設定覆蓋了編輯內容使用目前版本支援的持久化覆寫方式，或自行維護獨立設定
規則集載入失敗behavior、format 與實際內容不一致檢查 payload 結構、檔案路徑及提供者記錄

規則已命中，但仍無法連線

規則命中只代表分流判斷已完成，不保證目標服務一定連得上。直連仍取決於本機網路與 DNS；Proxy 策略仍取決於所選節點；REJECT 則會主動阻止連線。若連線詳細資料已顯示預期策略，請改為檢查該出站鏈路，而不是繼續堆疊相同規則。

維護規則時，請保留說明「為什麼需要這條例外」的 YAML 註解，並定期移除已失效的項目。優先使用精確網域、較小的網段及明確的兜底策略。若需了解完整的用戶端操作流程，請參閱快速入門；若要確認規則、策略組與 TUN 的概念，請參閱協定詳解。