Shadowrocket 自訂規則設定與優先順序：由上而下比對、FINAL 後備規則與 PROXY／DIRECT／REJECT

本文重點

本文適合已在 Shadowrocket（小火箭）匯入自有服務，並準備調整 Config 分流的使用者。請先確認目前使用的設定檔與 Global Routing，再透過保留網域範例了解規則順序、策略動作與 FINAL，最後查看請求記錄確認命中結果。範例僅說明語法，不提供連線服務。

一、規則生效前，先確認 Config 與 Global Routing

自訂規則需寫在設定檔的 [Rule] 區段。開始編輯前，請在底部的 Config 頁面確認目前使用的設定檔；開啟另一個檔案查看內容，不代表已切換至該設定檔。請先保留原始設定檔，再編輯副本，以便發生解析錯誤或誤攔截時還原。

返回 Home，檢查 Global Routing。依本文驗證設定檔規則時，請選用 Config。Proxy 與 Direct 是全域路由選項，不能以這兩種狀態下的連線結果判斷自訂規則是否生效。如果目前使用 Scene，請先確認實際採用的路由選項；排查期間可暫時固定為 Config，減少其他變因。

前往 Config，記下目前使用的設定檔名稱，並儲存原始內容。
編輯該設定檔的 [Rule] 區段，保留其他區段的標題與必要設定。
儲存後，確認目前選取的仍是剛才編輯的設定檔。
前往 Home → Global Routing，選擇 Config，再建立新的測試請求。

二、由上而下比對：順序優先於「精確程度」

同一份設定檔中的規則會依序檢查；符合第一條規則後，就採用該規則指定的策略，不會繼續尋找後面「更精確」的規則。因此，精確網域通常要排在較廣泛的後綴規則之前，例外規則要排在通用規則之前，FINAL 則放在最後。

請求資訊第一條規則逐條檢查首次命中執行策略

以下是規則順序錯誤的範例。連線至 api.example.com 時，第一行的 DOMAIN-SUFFIX 已符合，因此結果為 PROXY；後面的 DOMAIN 不會因為比對範圍較窄，就自動取得較高優先順序。

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

若要讓這個子網域單獨直連，請交換前兩行。這裡的 example.com 是保留用的示例網域；請依實際目標撰寫規則，勿將範例當成可用性測試服務。

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

結論：將例外規則移到涵蓋範圍較廣的規則之前

調整策略後仍未生效，請先往上檢查是否有涵蓋範圍較廣的 DOMAIN-SUFFIX、IP 網段規則，或提早出現的 FINAL，而不是繼續在清單末尾重複新增同一個網域。

三、DOMAIN-SUFFIX、IP-CIDR 與 GEOIP 的比對對象

網域規則與 IP 規則檢查的對象不同。DOMAIN 檢查完整網域，DOMAIN-SUFFIX 檢查網域後綴，IP-CIDR 檢查目標 IPv4 位址是否位於指定網段，GEOIP 則依據 IP 地理資料庫判斷目標位址所屬地區。GEOIP 的 CN 是指目標 IP 的地理位置判定，不是裝置所在地，也不是所選伺服器的所在地。

關鍵字	語法範例	比對說明
DOMAIN	`DOMAIN,api.example.com,DIRECT`	僅比對這個完整網域。
DOMAIN-SUFFIX	`DOMAIN-SUFFIX,example.com,PROXY`	比對 example.com 及其子網域，不會比對 notexample.com。
IP-CIDR	`IP-CIDR,192.168.0.0/16,DIRECT,no-resolve`	比對指定的 IPv4 網段；此處為一段私人位址範圍。
GEOIP	`GEOIP,CN,DIRECT`	依據目標 IP 的地理資料庫判定結果，比對 CN。
FINAL	`FINAL,PROXY`	處理未符合前面任何規則的請求。

no-resolve 表示不會只為了嘗試比對這條 IP 規則而觸發網域解析。這不等於關閉全域 DNS，也不會阻止應用程式在存取網域時進行必要的正常解析。請求已有可用的目標 IP 時，仍可能參與位址比對；不要因此認定所有網域請求都會略過或符合這條規則。

IP-CIDR 中的 /16 是前綴長度，不是連接埠。範例範圍涵蓋 192.168.0.0 至 192.168.255.255，並不代表所有私人位址。若要讓其他本機網段直連，請依實際網路分別設定；網域規則本身也不會區分 HTTPS 的 443 連接埠與 HTTP 的 80 連接埠。

3 種

本文使用的策略動作：PROXY／DIRECT／REJECT

/16

範例私人網段的 IPv4 前綴長度

443

HTTPS 常用的目標連接埠，不屬於網域規則欄位

四、PROXY、DIRECT、REJECT 與 FINAL 的關係

PROXY、DIRECT、REJECT 是規則命中後採用的策略。PROXY 會交由目前選取的代理處理；若設定檔使用自訂策略群組，還需確認群組內的選項。DIRECT 使用直連路徑，不代表關閉系統 VPN。REJECT 會拒絕該請求，適用於明確需要封鎖的目標，不應用來處理解析失敗。

FINAL 是規則類型，不是第四種對外連線方式。它沒有網域或網段條件，寫法為 FINAL,策略，不要照抄一般規則的三個欄位。若將 FINAL 提前放入清單，後面的普通規則就沒有機會比對。

依目標指定策略

PROXY: 交由目前選取的代理處理，需已有可用服務。
DIRECT: 目標採用直連路徑，仍受本機網路狀況影響。
REJECT: 拒絕請求；誤命中會導致無法連線。

先確認目標應採用哪種連線路徑，再選擇策略。

設定末尾後備規則

FINAL,PROXY: 未符合前面規則的請求交由代理處理。
FINAL,DIRECT: 未符合前面規則的請求採用直連。
擺放位置: 放在規則清單末尾，並在前面保留明確的例外與通用規則。

後備策略應依預期路徑選擇，沒有固定答案。

若希望「列出的網域走代理，其他請求直連」，可讓這些網域規則使用 PROXY，並以 FINAL,DIRECT 收尾。若希望「明確允許直連的目標直連，其餘交由代理」，則採用相反的安排。兩種結構都應先處理必要的本機連線例外，不能只依規則數量判斷哪種比較適合。

五、可逐行推演的規則範例

以下範例包含精確例外、拒絕項目、網域後綴、私人網段、地區判斷與後備規則。內容僅示範排序，並非完整設定檔；請保留現有設定檔中的 [General] 等內容。使用前請依實際目標調整，不要用這段內容覆蓋整份設定檔。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN,telemetry.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：符合第一行，採用 DIRECT，不再檢查後綴規則。
telemetry.example.com：符合第二行，採用 REJECT；這是語法示範中的假設設定，不代表對該網域用途的判斷。
www.example.com：前兩行均未符合，符合第三行，採用 PROXY。
目標 IP 為 192.168.1.20：若未先符合網域規則，第四行可比對這個私人位址。
其他目標：若 GEOIP 判定目標位址屬於 CN，則採用 DIRECT；否則繼續比對 FINAL，並採用 PROXY。

網域後綴規則排在 GEOIP 之前，表示 example.com 的一般子網域會先採用 PROXY，不會再依目標 IP 所屬地區決定路徑。這正是規則排序所要表達的意圖：網域策略優先於後續較通用的地區策略。若要表達不同意圖，請重新安排順序，並檢查是否影響既有例外。

六、以新請求與命中記錄驗證，不要只看頁面是否開啟

網頁成功開啟，只能表示這次連線成功，不能單憑此結果證明使用了預期策略。網頁也可能同時請求多個網域：主文件符合 DIRECT，靜態資源卻符合 PROXY 或 REJECT。檢查時應在請求記錄中找到具體目標，核對命中的規則與最終策略，而不是只查看 Home 的連線開關。

固定測試環境：記錄目前使用的 Config、Global Routing 與所選代理，測試期間不要同時切換網路和策略。
建立新連線：儲存設定檔後，重新建立測試請求。已建立的長連線可能繼續使用原有路徑，不適合用來判斷新規則。
確認目標：依實際請求的完整網域檢查，不要只記下網址列中的主站名稱。
找出第一條命中規則：若結果不符，請從清單頂端開始找出最先命中的規則，特別留意範圍較廣的後綴規則與提早出現的 FINAL。
分別檢查路徑與連線狀況：命中 PROXY 後仍失敗，請繼續檢查所選服務與解析；命中 DIRECT 後仍失敗，請檢查本機網路能否連上目標。
每次只改一項：一次只調整一條規則的位置或策略，儲存後再次驗證，最後記錄生效結果。

結論：先確認命中規則正確，再排查連線失敗

若記錄顯示目標已符合預期規則，請先停止調整排序，改為檢查 DNS、目標位址與所選的對外連線路徑；只有命中結果不符時，才繼續調整條件與位置。

若規則來自遠端維護的設定檔，更新後也應確認自訂規則是否保留。伺服器訂閱更新與設定檔規則更新是不同操作，不能把「服務清單已重新整理」當成「目前規則已替換」。保留修改前後的內容與測試目標，下次更新後即可重複驗證相同的預期行為。

七、常見狀況：規則修改後仍不如預期

規則加在 FINAL 後面，為什麼沒有作用？

FINAL 已接住所有未符合前面規則的請求，後續普通規則便沒有執行機會。請將自訂規則移到 FINAL 之前，並檢查它上方是否還有涵蓋該目標的規則。

網域規則設為 DIRECT，為什麼資源仍走 PROXY？

請先確認資源是否另有請求其他網域。DOMAIN 只涵蓋完整網域，DOMAIN-SUFFIX 也只涵蓋相符的後綴，不會自動涵蓋頁面引用的其他網站。請依實際請求記錄分別判斷，不要為了解決單一資源問題，就擴大規則涵蓋範圍。

使用 REJECT 後頁面空白，該如何還原？

先找出遭拒絕的目標，暫時移除相關規則或還原備份，再以新請求重新測試。登入、驗證碼與靜態資源可能使用不同網域；確認封鎖目標及影響範圍後，才重新啟用 REJECT。

切換 Shadowsocks、VMess 或其他協定，會改變規則優先順序嗎？

對外連線協定與規則清單的比對順序，是兩個不同層面。更換協定不會讓排在後面的 DOMAIN 自動優先於前面的 DOMAIN-SUFFIX。請先確認規則選用了哪種策略，再檢查該策略對應服務的連線條件。