Shadowrocket（小火箭）的 Rule 不會自動依「精確度」排序，而是依設定順序比對。本文適合已有自己的服務商與連線設定、準備調整分流的使用者：先確認 Global Routing 設為 Config，再區分網域規則與 IP 規則，最後將 FINAL 放在末尾。讀完即可撰寫一組容易理解、能逐條驗證的規則，並分辨「沒有比對到」與「比對到但連線失敗」。
先確認規則生效條件
先檢查 Home 中的 Global Routing，再編輯 Config。使用 Config 時，請求會依目前啟用的設定檔進行分流；Proxy 與 Direct 是不同的全域處理模式，不能用來驗證自訂 Rule 是否生效。Scene 會依已設定的情境處理，也不等於固定使用某一份 Config。排查期間先固定使用 Config，避免情境變化影響判斷。
- 在 Home 確認已有可用的連線設定，並開啟連線開關；首次建立系統 VPN 設定時，依照系統提示授權。
- 進入 Config，確認目前啟用的檔案。編輯前先保留副本，避免遠端檔案更新與本機修改混在一起。
- 返回 Home，將 Global Routing 設為 Config；儲存修改後，依介面提示重新載入或建立連線。
- 關閉待測試 App 的舊連線，再發出新請求。已建立的長連線通常不會因為修改一行規則就立即改變路徑。
Home 用於管理連線與服務項目，Config 用於存放設定檔，Settings 則是全域設定所在位置。Settings → On Demand 控制在何種條件下建立連線，不負責將特定網域指派給某條 Rule；若出現「中斷後又自動連線」，應檢查這裡，而不是反覆修改 FINAL。
先比對，再執行策略
常見規則由類型、比對內容與策略組成，並以英文半形逗號分隔。例如 DOMAIN,api.example.com,DIRECT 表示：網域恰好是 api.example.com 時，執行 DIRECT。FINAL 沒有比對內容欄位，因此寫成 FINAL,PROXY，不要補成三段。
同一個請求命中前面的規則後，就不會繼續尋找後面「更精確」的規則。假設 DOMAIN-SUFFIX,example.com,PROXY 排在前面，而 DOMAIN,api.example.com,DIRECT 排在後面，後者就不會為這個網域提供例外。正確做法是將例外規則移到範圍較廣的規則前面。
三種網域規則
網域規則比對的是主機名稱，而非完整網址。不要在比對欄位填入 https://、路徑 /login、查詢參數或連接埠 :443。以下的 example.com 都是文件範例，並非需要設定的實際服務。
| 類型與寫法 | 比對範圍 | 容易混淆的情況 |
|---|---|---|
DOMAIN,api.example.com,DIRECT |
只比對 api.example.com | 不比對 example.com 或 img.api.example.com |
DOMAIN-SUFFIX,example.com,PROXY |
比對 example.com 及其子網域 | 不比對 notexample.com，網域邊界很重要 |
DOMAIN-KEYWORD,example,PROXY |
比對主機名稱中包含 example 的請求 | 可能同時比對 example.net 與 notexample.com，範圍較廣 |
只想改變單一 API 的輸出路徑時，優先使用 DOMAIN；要涵蓋同一主網域下的資源網域時，使用 DOMAIN-SUFFIX；只有明確需要子字串比對時才使用 DOMAIN-KEYWORD。關鍵字規則不會判斷網站歸屬，字詞過短可能影響無關網域，也更難界定故障範圍。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,media-sample,PROXY
FINAL,DIRECT在這組範例中，api.example.com 先比對到 DIRECT，img.example.com 比對到後綴規則；未符合前面任何條件的請求則執行 FINAL 的 DIRECT。若將第一行移到後綴規則之後，API 例外就會被涵蓋。只要調整順序就足以改變結果，不必同時修改 DNS 或連線參數。
GEOIP 與 IP-CIDR
GEOIP 依目標 IP 在本機地理資料庫中的歸屬進行比對。GEOIP,CN,DIRECT 表示對歸屬於 CN 的目標 IP 使用 DIRECT。判斷依據不是網頁語言、網域後綴或服務商註冊地。同一網域可能解析至不同地區的位址，因此結果會同時受到解析結果與資料庫內容影響。
IP-CIDR 則直接比對 IPv4 網段。192.168.0.0/16 涵蓋 192.168.0.0 至 192.168.255.255；10.20.30.40/32 只代表一個 IPv4 位址。遮罩描述的是位址範圍，不是連接埠範圍，也不是主機數量參數。
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.20.30.40/32,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- 直接連線至 IP：連線至 192.168.1.20 時，目標位址明確，可用網段規則判斷；通訊協定使用連接埠 80 或 443，不會改變這條網段規則的涵蓋範圍。
- 透過網域連線：IP 類規則可能涉及網域解析。
no-resolve表示不為該條 IP 規則主動觸發網域解析，不代表封鎖所有 DNS，也不代表已知 IP 無法比對。 - IPv6 請求：IPv4 的 IP-CIDR 無法涵蓋 IPv6 位址。排查時應記錄實際目標的位址類型，不能只因 IPv4 網段設定正確，就認定所有請求都會比對到。
- 區域網路例外：若全域代理影響本機裝置的連線，可將明確的本機網段規則放在範圍較廣的策略前面；只加入自己的網路確實需要的範圍。
不要只憑「網站屬於某個地區」就推斷 GEOIP 一定會比對到。內容傳遞網路可能讓同一網域回傳多個目標 IP，App 也可能使用快取位址。先查看新請求的目標位址，再判斷地理規則是否符合預期。
FINAL 與完整順序
FINAL 是前面的規則都未比對到時使用的兜底規則，不是連線失敗後的重試開關。若前面的規則選中了 PROXY，但該輸出連線逾時，請求不會因此自動略過它，再由 FINAL 改走 DIRECT。應修正已選取的輸出連線或規則選擇，而不是再新增一條末尾規則。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,media-sample,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- 具體例外放前面。API 單一網域規則應排在同一網站的後綴規則之前，確保例外能先比對到。
- 接著設定網域範圍。先決定已知網站的輸出路徑，再處理 IP 範圍，可減少地理歸屬變動對指定網站的影響。
- 安排位址規則。本機網段與 GEOIP 之間也有順序關係；若規則範圍重疊，應將需要優先執行的條件放在前面。
- 最後保留兜底規則。將 FINAL 放在末尾。應依照希望如何處理未分類請求，決定使用 DIRECT 或 PROXY，而不是照搬他人的設定習慣。
依現象排查分流問題
每次只修改一項，並以同一個目標發出新請求。查看可用的連線記錄或日誌時，優先記下目標網域、實際 IP、命中規則與最終策略。若日誌只提供部分資訊，就根據現有內容縮小排查範圍，不要把「頁面無法開啟」直接視為規則寫錯。
錯誤：Connection timed out
原因與處理方式：連線未能在指定時間內完成，可能與目標、連線路徑或輸出服務有關；先確認命中的策略，再使用 Home 中的 Connectivity Test 檢查目前連線，並比對同一目標的其他請求。逾時本身不能證明 DOMAIN-SUFFIX 語法有誤。
錯誤：Connection refused
原因與處理方式：通常表示目標端或中間設備明確拒絕連線；請確認請求的目標連接埠，以及使用者現有服務的連接埠設定。例如服務只監聽 443，卻連線至 8443 時，應修正連線參數，而不是依賴調整 FINAL 兜底。
以上英文是網路錯誤訊息，實際顯示內容取決於日誌來源。若沒有錯誤，只是輸出路徑與預期不同，先檢查目前是否仍處於 Proxy 或 Direct，再確認編輯的檔案是否為目前啟用的 Config，最後從第一條 Rule 開始，找出更早比對到的條件。
「新增規則後，為什麼還是走原本的輸出路徑？」
先在 Home 將 Global Routing 固定設為 Config，再確認 Config 中啟用的檔案。將單一網域例外移到範圍較廣的後綴或關鍵字規則之前，儲存後關閉舊連線，再重新請求同一網域；不要只重新整理仍沿用舊連線的頁面。
「設定 GEOIP 的 CN 後，為什麼這個中文網站沒有走 DIRECT？」
查看該次請求實際連線的 IP，而不是網頁語言。如果請求已比對到前面的網域規則，GEOIP 就不會參與後續判斷；若比對流程到達 GEOIP，則應確認該 IP 在資料庫中的歸屬，以及解析結果是否已變動。
「更新訂閱後，自訂規則也會一起更新嗎？」
服務訂閱與 Config 是不同項目。在 Home 更新現有服務訂閱，主要是更新連線項目；需要更新遠端設定時，應在 Config 中操作對應檔案。不要把訂閱更新成功，當成本機 Rule 已儲存或啟用的證明。
「更換通訊協定後，需要重寫 DOMAIN-SUFFIX 嗎？」
更換通訊協定不代表必須重寫。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 屬於連線通訊協定層，網域規則則負責選擇策略。先確認原有策略仍指向有效項目，再依自己的服務參數檢查通訊協定連線。
儲存前逐項確認
可靠的分流設定應能回答三個問題：這條規則比對什麼、為什麼排在這裡，以及命中後使用哪個策略。先維護少量明確的規則，再逐步擴充，比一次加入大量難以說明的關鍵字更容易排查問題。本網站僅說明用戶端設定操作，不提供、不販售或推薦節點或訂閱服務。
- 類型、逗號與策略名稱皆使用正確的英文寫法；網域欄位不含通訊協定標頭、路徑或連接埠。
- DOMAIN 例外應排在涵蓋它的 DOMAIN-SUFFIX 或 DOMAIN-KEYWORD 之前。
- IP-CIDR 的位址類型與網段設定正確；並已了解 no-resolve 不會取代 DNS 設定。
- FINAL 位於末尾，且已確認未分類請求會使用 DIRECT 或 PROXY。
- 目前啟用的是修改後的 Config，Global Routing 設為 Config，並已使用新連線驗證結果。