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

本文重點

Shadowrocket（小火箭）的規則優先順序取決於排列位置，而非網域長短或策略名稱。本文適合已有自己的服務商與訂閱、需要調整流量分流的使用者：先確認 Home 中的 Global Routing，再到 Config 檢查目前設定，將個別例外排在通用規則之前，並以新連線確認 FINAL 是否正確處理未命中的請求。

先確認 Global Routing 設為 Config

編輯規則前，先分清楚「是否連線」與「如何分流」。Home 中的連線開關用來啟用連線；Global Routing 則決定請求採用哪種處理方式。若要驗證設定檔中的規則，請先將 Global Routing 設為 Config，再到 Config 確認目前使用的設定檔。只修改未啟用的檔案，不會改變目前生效的分流結果。

1 條

每次規則判定都由第一條命中的規則決定策略

3 種

本文介紹的基本策略：PROXY / DIRECT / REJECT

最後一條

將 FINAL 放在規則段末尾，處理未命中的請求

Global Routing 中的 Proxy 代表全域採用代理方式處理，Direct 則代表全域直連；兩者都不能用來判斷某條設定規則是否命中。Scene 用於依不同情境套用相應設定，也不應視為固定的 Config 狀態。排查單條規則時，先明確選擇 Config，減少切換情境造成的干擾。

結論：先固定模式，再修改規則

調整規則後，若連線路徑沒有改變，第一步不是再新增規則，而是回到 Home 確認 Global Routing，並在 Config 核對實際生效的檔案。

依序由上而下比對，不會自動按「條件更明確」排序

規則段可以視為依序排列的判斷清單。請求進入分流流程後，程式會依序檢查規則條件；一旦命中，就採用該條指定的策略，不會繼續尋找「看起來更適合」的後續規則。因此，個別例外通常應排在通用規則之前，而不能依賴程式自動比較條件的明確程度。

請求送入讀取目標依序比對決定策略執行輸出

以下片段示範常見的順序問題。DOMAIN-SUFFIX,example.com,PROXY 會涵蓋 example.com 本身及其子網域。當請求目標是 api.example.com 時，第一行已經命中，後面的精確網域規則便不會參與這次判定。

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

若要讓這個子網域直連，而其他相同後綴的網域使用代理，應將例外規則提前。這裡的網域僅用於說明語法，不是連線服務，也不能用來測試可用性。

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

拒絕例外也適用相同原則：若只要拒絕某個子網域，並讓相同後綴的其他請求繼續使用代理，精確的 REJECT 規則也必須排在通用後綴規則之前。不要誤以為「拒絕策略看起來較強」就有較高優先順序。

DOMAIN-SUFFIX、IP-CIDR 與 GEOIP 如何排列

這些關鍵字代表不同的比對條件，而非固定的優先順序。DOMAIN-SUFFIX 檢查網域後綴，IP-CIDR 檢查目標 IP 是否位於指定網段，GEOIP 則依 IP 地理歸屬資料比對地區代碼。實際排列時，應先寫明確的例外，再寫涵蓋範圍較大的位址或地區規則。

網域條件

DOMAIN: api.example.com,DIRECT
DOMAIN-SUFFIX: example.com,PROXY
比對依據: 請求所對應的網域資訊

精確例外在前，後綴涵蓋規則在後。

位址條件

IP-CIDR: 192.168.0.0/16,DIRECT,no-resolve
GEOIP: CN,DIRECT
比對依據: 目標 IP 與本機歸屬資料

特定網段通常排在通用地區規則之前。

IP 規則需要有可供判斷的目標 IP。若請求一開始只有網域名稱，解析流程可能影響後續能否命中 IP-CIDR 或 GEOIP。範例中的 no-resolve 表示不要只為這條規則主動觸發網域解析；這不代表停用整個應用程式的 DNS，也不代表所有網域請求都能直接命中該網段。

網域有明確例外：先加入 DOMAIN 或 DOMAIN-SUFFIX，讓該請求在遇到通用 IP 條件之前就確定策略。
區域網路有明確範圍：依實際網路填寫 IP-CIDR；192.168.0.0/16 是其中一段私有位址範圍，不代表所有本機網路。
依地區設定一般策略：將 GEOIP 放在特定例外之後。歸屬資料描述的是 IP 所屬地區，不是網站使用的語言，也不是網域後綴。
沒有任何條件命中：交由規則段末尾的 FINAL 處理，不要在前面插入無條件規則。

GEOIP 結果取決於應用程式使用的 IP 歸屬資料，未必與網站營運者所在地一致。使用 CDN 的網站也可能在不同時間解析到不同位址。若某個網域必須採用固定策略，通常應為該網域單獨設定規則，不宜只靠 GEOIP 推斷連線路徑。

PROXY、DIRECT、REJECT 是處理動作，不是優先順序

規則通常由關鍵字、比對值與策略組成。例如 DOMAIN-SUFFIX,example.com,PROXY 的前兩部分回答「比對哪個目標」，最後一部分則說明「命中後如何處理」。FINAL 是特殊的備援形式，不需填寫網域或網段，因此寫作 FINAL,PROXY。

策略	命中後的處理方式	排查重點
`PROXY`	透過目前設定所對應的代理出口處理	確認所選伺服器或策略組的實際選擇，以及服務是否可用
`DIRECT`	不經過代理伺服器，直接連線至目標	確認目前網路能否直接連線至目標
`REJECT`	拒絕符合條件的請求	確認是否誤擋登入、圖片或 API 網域

命中 PROXY 只代表規則選擇了代理處理，不代表一定能連上目標。伺服器無法使用、目標服務異常或解析失敗，仍可能造成連線失敗。命中 DIRECT 也不代表請求略過所有規則檢查；它只表示完成規則判定後採用直連方式。

若設定中使用自訂策略組名稱，規則結尾必須與現有名稱完全相符。不要把任意說明文字直接當成策略，也不要只因規則寫著 PROXY 就認定目前出口正確；還要確認 Home 中的選擇，以及設定檔內相關策略組的實際狀態。

FINAL 為何要放在最後，以及如何選擇 PROXY 或 DIRECT

FINAL 不再限定特定網域、網段或地區，而是處理排到該位置時仍未命中的請求。若放在規則段前面，後續規則就沒有比對機會。因此維護設定檔時，應檢查規則段末尾的備援設定，而不是遇到問題就一再新增 FINAL。

[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

這是一段用來說明比對順序的規則範例，並非完整設定檔。請保留現有設定中的其他必要段落，再依實際需求合併規則；不要用這幾行取代整份檔案。範例中的第一個子網域使用 DIRECT，第二個使用 REJECT，相同後綴的其他網域使用 PROXY；其餘請求則依序比對位址、地區，最後交由備援規則處理。

選擇 FINAL,PROXY：表示未命中特定例外的請求也使用代理。適合希望未分類請求一律經由代理出口處理的設定需求。
選擇 FINAL,DIRECT：表示只有前面明確指定使用代理的請求才經由代理，其餘請求直連。請留意，未列入規則的目標可能因此無法直連。
修改前先備份：保留目前可用的設定檔，並記下原本的 FINAL 策略。若影響範圍擴大，可還原原始檔案，而非繼續疊加例外。

結論：先釐清未分類請求的預期路徑

檢查 FINAL 時，先回答「沒有命中任何已知規則的目標應走哪條路徑」，再選擇 PROXY 或 DIRECT；不要把備援策略當成修復所有連線問題的開關。

修改後如何驗證，避免把快取誤認為新結果

修改規則後，應完成「儲存、生效、建立新連線、核對紀錄」整個流程。瀏覽器與應用程式可能重用既有連線，單純返回頁面不一定會重新進行相同的規則判定。測試時應區分舊連線的延續與新請求的結果。

備份目前檔案：在 Config 確認正在使用的設定檔，保留修改前的副本，並記下這次預計調整的目標網域或網段。
一次只改一個變數：例如只將 DOMAIN 例外移到 DOMAIN-SUFFIX 之前，暫時不要同時修改 DNS、伺服器和 FINAL。
儲存並確認生效：編輯完成後，確認目前使用的仍是目標檔案；返回 Home 檢查 Global Routing 是否為 Config，以及連線狀態是否正常。
建立新連線：關閉目標頁面或相關應用程式的舊連線後再試；必要時可在允許短暫中斷的情況下重新連線，再開啟目標。
核對連線紀錄：在 Data 查看可用的連線紀錄或日誌，核對目標網域、目標 IP 與策略；若紀錄有提供規則資訊，再確認具體命中的規則。

例如，預期 api.example.com 命中 DIRECT，紀錄卻顯示它依相同後綴規則使用 PROXY，應先檢查規則順序及設定檔是否生效。若紀錄已顯示 DIRECT，但仍無法連線，應改查直連是否可用，而不是繼續把同一條規則往上複製。

也要區分既有伺服器訂閱更新與設定檔更新。伺服器清單變動不一定會改變 Config 中的規則；遠端設定更新則可能取代本機編輯內容。修改前先確認編輯對象，更新後重新檢查規則順序與 FINAL，才能判斷問題出在比對，還是內容遭更新覆蓋。

規則優先順序常見問題

規則條件更明確，為什麼還是沒有生效？

Shadowrocket 不會自動將條件更明確的規則移到前面。到 Config 檢查實際規則順序，將 DOMAIN 例外移到會涵蓋它的 DOMAIN-SUFFIX 之前，然後儲存並建立新連線。也要確認目前使用的設定檔正是該檔案，且 Global Routing 設為 Config。

將 FINAL 改為 PROXY 後，為什麼仍有請求直連？

FINAL 只會處理前面沒有命中的請求。先確認該目標是否已命中較前面的 DIRECT 規則，例如 DOMAIN、IP-CIDR 或 GEOIP；已命中的請求不會再由 FINAL 重新決定策略。

GEOIP,CN,DIRECT 會覆蓋前面的網域代理規則嗎？

不會。若請求已命中前面的 DOMAIN-SUFFIX 代理規則，比對就會停止。只有尚未命中的請求才會繼續比對 GEOIP。若結果與預期不同，請核對請求的實際網域、目前使用的檔案，以及紀錄中的命中資訊。

新增 REJECT 後頁面只載入一半，該如何恢復？

先還原剛新增的 REJECT 規則，再重新開啟頁面確認是否恢復。單一頁面可能同時要求登入、API、圖片等多個網域；確認誤擋的目標後，縮小比對範圍，必要時將明確允許的精確例外排在通用拒絕規則之前。

每次更新設定後，自訂規則都消失，該怎麼辦？

先確認更新的是伺服器訂閱，還是遠端設定檔。若遠端檔案覆蓋本機修改，請保留一份可獨立維護的設定檔副本，並在之後更新前比對需要保留的規則；不要只靠重複貼上規則處理，也要避免重複項目改變實際順序。