Shadowrocket 自訂規則優先順序：由上而下比對與 FINAL 後備規則

一、規則優先順序：先命中，不是越精確越優先

使用設定檔進行分流時，[Rule] 區段會由上而下依序檢查；某條規則符合時，就採用該規則指定的策略，不會再繼續尋找後面「更精確的規則」。因此，規則類型本身沒有能取代排列順序的通用優先權。把 DOMAIN 寫在 DOMAIN-SUFFIX 後面，不會因此自動取得較高優先順序。

例如，希望 api.example.com 直連，而 example.com 的其他子網域走代理，應先寫出這個個別網域的例外。以下網域僅用來說明語法，不是服務位址，也不代表可用性。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

• 存取 api.example.com：符合第一行規則，使用 DIRECT。
• 存取 www.example.com：不符合第一行，符合第二行，使用 PROXY。
• 其他未被前面規則涵蓋的請求：由 FINAL,DIRECT 處理。

如果交換前兩條規則，api.example.com 也符合較廣泛的網域後綴條件，會先被 PROXY 規則攔截。排查「明明設了直連，卻仍走代理」時，先檢查目標規則之前是否已有其他規則涵蓋該請求，而不是在末尾不斷新增重複項目。

二、先確認 Global Routing，再編輯 Config

設定檔中有規則，不代表目前連線一定會依照這些規則分流。前往 Home → Global Routing 確認目前模式，再到 Config 確認正在使用的檔案。以下只比較本次驗證會用到的三種模式；Scene 用於場景設定，排查本文的規則時，請先明確選擇 Config，減少切換場景造成的變數。

1. 備份設定

   前往 Config，先儲存目前檔案的副本或匯出備份，保留可還原的原始規則；不要只備份新增的幾行。

2. 開啟編輯

   在 Config 中開啟目標設定的編輯入口，找到 [Rule] 區段。確認修改的是設定檔正文，而不是 Home 中的伺服器連線參數。

3. 排列規則

   將單一網域的例外放在對應的廣泛規則之前，再檢查 IP 範圍與 GEOIP 項目，並在末尾保留 FINAL；儲存後確認目前使用的是這個檔案。

4. 確認模式

   返回 Home → Global Routing → Config，確認已選取正確的伺服器，再啟用連線；若系統要求授權 VPN 設定，請依照系統提示操作。

5. 送出新請求

   關閉目標頁面後重新瀏覽，必要時重新建立連線，避免以舊連線判斷新規則。記下目標網域、時間與比對結果，再進行下一項修改。

三、DOMAIN-SUFFIX、IP-CIDR 與 GEOIP 的排列方式

規則比對的對象與規則所在行數，是兩個不同的問題。網域規則檢查主機名稱，IP 規則檢查目的位址，GEOIP 則依據位址資料庫分類。網域請求可能解析出多個位址，同一網域也可能因網路環境不同而解析到不同位址；不要把一次 IP 命中視為該網域永遠固定的屬性。

DOMAIN-SUFFIX 後方應填入 example.com，而不是包含 https:// 的完整網址，也不是 example.com/path。路徑是 URL 的另一部分；貼到網域欄位中，無法表示「只讓這個頁面走代理」。規則也不會因為網站常用 HTTPS 通訊埠 443，就自動加入通訊埠比對條件。

no-resolve 表示不為了比對這條 IP 規則而額外觸發網域解析；這不代表關閉整份設定的 DNS，也不代表這個網段永遠不會命中。若請求已有可供判斷的目的 IP，仍可依位址範圍進行比對。若只有網域名稱，且不希望這條規則觸發解析，請留意略過解析可能使請求繼續往下比對。

• 先列出業務上必須保留的精確例外，再列出對應的網域後綴；這樣可避免廣泛規則提早涵蓋例外。
• 只有在確實需要依目的位址區分時，才加入 IP 網段；/32 代表單一 IPv4 位址，/24 涵蓋 256 個位址。
• 範圍較廣的 GEOIP 通常排在明確例外之後，方便維護；但這只是排列建議，不是用戶端強制採用的規則類型優先順序。
• 若連線直接使用 IP，且沒有可用的網域名稱，就不能只靠 DOMAIN-SUFFIX 來比對。

四、PROXY、DIRECT、REJECT 與 FINAL 的完整寫法

規則末尾的策略會決定命中後的動作：PROXY 交由代理路徑處理，DIRECT 直接連線至目的地，REJECT 則拒絕請求。這些動作與伺服器通訊協定屬於不同層級的設定；將現有伺服器從 Shadowsocks 改為 Trojan，不會改變規則由上而下比對的基本順序。

以下僅為說明用的 [Rule] 區段，不能取代所有現有設定。範例假設使用者已有可用伺服器；示例網域不提供任何服務。實際合併前，請檢查現有檔案中的策略名稱、其他規則與所需網路範圍。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

• api.example.com 雖然屬於 example.com，但會先命中第一條例外規則，因此採用直連。
• blocked.example.com 會在後綴規則之前命中 REJECT；無法存取是此策略的預期結果。
• 192.168.0.0/16 只涵蓋這個私有位址範圍，不代表所有本機網路；其他範圍須依實際需求個別判斷。
• GEOIP,CN,DIRECT 依據目的 IP 的資料庫分類，不保證涵蓋所有中文網站，也不保證同一網域每次都會被歸入相同分類。
• FINAL,PROXY 只會處理先前未命中的請求；不會把已命中 DIRECT 的請求改為走代理。

將 FINAL 插在規則中段，會提早接手之後未分類的請求，使後續項目無法發揮預期作用。維護時只在末尾保留一條明確的後備規則，避免舊設定中殘留第二條 FINAL，造成判讀混淆。

五、透過單一變數測試找出規則未生效的原因

驗證順序應為「目前檔案 → 目前模式 → 請求目標 → 實際比對 → 連線結果」。網頁能開啟，只能證明該次請求成功，不能單獨證明使用了哪條路徑；網頁無法開啟，也可能是 REJECT、目的服務故障或代理連線問題。請分別記錄規則比對結果與連線成敗。

1. 建立基準：維持相同網路、同一台現有伺服器與同一個目標，記錄修改前的狀況，避免同時更換伺服器與規則。
2. 只修改一行：例如只交換 DOMAIN 與 DOMAIN-SUFFIX 的順序，儲存並確認目前使用這份設定，再重新送出請求。
3. 檢查請求資訊：在 App 的連線記錄或日誌中查看本次目標主機、目的 IP 與可見的策略資訊；若只看到 IP，先確認是否有網域資訊。
4. 檢查完整資源：頁面正文、圖片與登入介面可能使用不同網域。只為主站新增一條規則，不一定涵蓋整個頁面的所有相依資源。
5. 還原並比較：還原剛才的修改，再次瀏覽。若狀況沒有隨修改反覆變化，請繼續檢查快取、舊連線與目標服務狀態。

訂閱更新與設定編輯也應分開處理。在 Home 更新使用者現有的伺服器訂閱，主要是重新整理伺服器項目；在 Config 更新遠端設定，則可能取代設定檔正文。不要把這兩種更新都當成「重新整理規則」。修改遠端設定前，請先儲存本機副本；更新後重新檢查例外項目與 FINAL 是否仍存在。

六、規則順序與 FINAL 常見問題