· 進階設定 · 約 9 分鐘

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

說明 [Rule] 段由上而下比對、首條命中即停止的規則順序，以及 FINAL 的後備作用、三種策略的選擇和常見排序錯誤。

本文重點

Shadowrocket（小火箭）的規則不會依「條件較具體」自動排序，而是根據目前請求可用的比對資訊，由上而下逐條檢查，命中第一條規則後便採用其策略。本文適合已有設定檔、需要新增網域例外或檢查分流結果的使用者：先確認 Global Routing 設為 Config，再把具體例外排在範圍較廣的規則之前，將 FINAL 留在最後，並以新連線確認實際命中的規則。

先確認 Config，再檢查規則是否生效

[Rule] 段用來描述請求如何選擇策略。排查「自訂規則沒有生效」時，第一步不是繼續新增規則，而是確認 App 目前使用哪一份設定檔，以及 Global Routing 的狀態。若目前使用 Proxy 或 Direct，就不能把結果當成 Config 下逐條比對的驗證結果。

  1. 開啟 Home → Global Routing，確認目前選取的是 Config，再返回 Home。
  2. 前往 Config，確認目前選取的設定檔。若有多份設定檔，先確認編輯的檔案與目前使用的檔案相同。
  3. 在該設定檔的編輯入口檢查 [Rule] 段，儲存變更，並確認修改後的設定檔仍處於選取狀態。
  4. 返回 Home，視需要重新建立連線，再對目標網域發出新請求；不要只重新整理仍沿用舊連線的頁面。

本文只討論 Config 下的規則順序，不涵蓋 Scene 的情境設定。Settings → On Demand 管理依條件連線的行為，並非規則優先順序設定；自動連線成功，只能表示連線已觸發，不能證明某條網域規則已命中。

先保留可還原的設定檔

修改前請先備份原設定檔。本文程式碼僅用於說明規則語法與排序，不包含完整連線參數，也不能取代使用者現有的設定。既有服務與訂閱由使用者自行管理，本網站不提供、不販售也不推薦節點或訂閱。

由上而下比對：具體規則不會自動排在前面

規則的比對條件與策略是兩回事。以 DOMAIN-SUFFIX,example.com,PROXY 為例，DOMAIN-SUFFIX 是規則類型，example.com 是比對內容，PROXY 是命中後採用的策略。網域後綴比對可涵蓋該網域本身及其子網域，因此排在後面的特定子網域例外可能根本沒有機會接受檢查。

新請求比對條件命中第一條採用策略停止檢查

以下是容易判斷錯誤的排序。造訪 docs.example.com 時，上方的後綴規則已可比對成功，請求會採用 PROXY；後面的精確網域規則不會因為「更具體」就取代它。

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

若要讓 docs.example.com 單獨使用 DIRECT，而其他符合該後綴的網域使用 PROXY，就應將精確例外移到前面。優先順序取決於所在位置，不取決於關鍵字名稱，也不取決於新增規則的時間。

[Rule]
DOMAIN,docs.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY
3 種
本文介紹的策略：PROXY / DIRECT / REJECT
4 類
以下範例的條件：DOMAIN / DOMAIN-SUFFIX / IP-CIDR / GEOIP
1 條
末尾的 FINAL：承接先前未命中的請求

結論：先找位置更前面的覆蓋規則

新增例外沒有作用時，先搜尋相同網域及其上層後綴，將例外移到第一條可能涵蓋它的規則之前；不要重複新增同一條規則，試圖提高優先順序。

PROXY、DIRECT、REJECT：命中後的三種結果

策略決定「命中後如何處理」，不會決定「先檢查哪一行」。將 PROXY 改成 DIRECT，不會讓該行自動取得更高優先順序；將 REJECT 放在範圍較廣的允許規則之後，也無法攔截已被前面規則接手的請求。

策略處理方式檢查重點
PROXY交由代理策略對應的對外連線處理。確認目前選取的代理及其可用性；規則命中不代表遠端一定連得上。
DIRECT不經代理伺服器，直接連線至目標。確認目前網路能否直接存取目標；這不是「中斷整個 VPN」的指令。
REJECT拒絕符合該規則的連線。確認遭拒絕的網域是否為頁面必要資源，避免比對範圍過廣而影響正常功能。

規則策略也可以引用設定檔中已有的策略群組。複製片段前，請確認引用名稱在目前設定檔中的含義；不能把任意文字當成已存在的策略。本文統一以 PROXY、DIRECT、REJECT 說明基本行為，不新增策略群組，也不指定任何服務。

FINAL 的作用：後備，不是自動重試

FINAL,PROXY 表示先前的規則都未命中時，使用 PROXY。它沒有網域或網段條件，因此應放在規則段最後。若將 FINAL 提前，後面的常規規則便沒有機會接手尚未命中的請求。

代理後備規則的配置方式

精確例外
DOMAIN,docs.example.com,DIRECT
後綴策略
DOMAIN-SUFFIX,example.com,PROXY
最終後備
FINAL,PROXY

未命中前兩條規則的請求交由 PROXY；是否能連線須另行確認。

直連後備規則的配置方式

精確封鎖
DOMAIN,blocked.example.com,REJECT
後綴策略
DOMAIN-SUFFIX,example.com,PROXY
最終後備
FINAL,DIRECT

未命中前兩條規則的請求直接連線；直連失敗時不會退回上一條規則。

FINAL 不是「前面的代理連線失敗後，改用其他方式重試」。一旦某條規則命中，即使後續連線逾時，比對流程也不會自動往下繼續。若請求已命中某條 PROXY 規則，應檢查該策略對應的連線，而不是在末尾再加一條 FINAL，期待連線失敗時自動回退。

  1. 先決定未分類流量要由 PROXY 還是 DIRECT 承接。
  2. 確認現有設定檔是否已有 FINAL，修改原本的後備策略，不要在未檢查的情況下直接新增。
  3. 將要保留的規則整理到 FINAL 之前，並確認後面沒有仍有效的規則。

將網域、網段與 GEOIP 放入同一份範例

以下片段示範一種容易閱讀的排序：明確封鎖項目、精確網域例外、網域後綴、指定網段、GEOIP，最後是 FINAL。這只是範例排列，不代表固定的類型優先順序。若需求相反，例如某個網段必須一律直連，就需要重新評估其位置，以及請求是否具備可供比對的 IP 資訊。

[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,docs.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

example.com 及其子網域用來說明網域關係；192.0.2.0/24 是文件範例網段，不應視為真實服務位址。GEOIP,CN,DIRECT 示範依目標 IP 的地理資料庫分類進行設定，不表示所有使用者都應採用此策略。

規則關鍵字比對對象本例注意事項
DOMAIN完整網域。只為明確指定的單一網域設定例外，不會自動涵蓋其所有子網域。
DOMAIN-SUFFIX網域本身及其子網域。若先寫這一行，後面的同後綴精確例外可能不會命中。
IP-CIDR目標 IPv4 位址所屬的網段。no-resolve 表示不主動為此規則觸發網域解析，不能理解為關閉所有 DNS。
GEOIP目標 IP 在地理資料庫中的分類。判斷依據不是網頁語言、網域後綴或網站所屬公司的所在地。
FINAL先前未命中的請求。放在末尾，只作為後備，不會檢查目標是否可用。

網域規則需要可用的網域資訊，IP 規則則需要目標 IP；不能只因為「看起來是同一個網站」就互相取代。同一個頁面也可能向多個資源網域發出請求。主頁命中 DIRECT，不代表圖片、影片或登入介面也會使用 DIRECT。排查時應記錄實際請求的目標，而不只是瀏覽器網址列的內容。

結論：每次只調整一項比對條件

先用一個明確網域驗證規則位置與策略，再逐步加入後綴、網段或 GEOIP。若同時變更 DNS、Global Routing 和多條規則，即使結果有所改變，也很難判斷是哪一項調整造成的。

修改後的驗證順序與常見問題

驗證規則時，應分開確認「是否命中」與「命中後能否連線」。前者檢查設定檔、規則順序與目標資訊；後者檢查 DIRECT 的網路可達性，或 PROXY 對應的連線。只憑網頁載入速度判斷策略，很容易把快取、連線重用和伺服器回應差異誤認為規則效果。

  1. 記錄基準狀態：記下目前的設定檔、Global Routing 狀態、目標網域和預期策略。修改前保留原本的規則位置。
  2. 儲存並套用：確認目前使用的是修改後的設定檔，必要時重新連線。不要只編輯未選取的檔案。
  3. 建立新連線：結束原本的連線後再試一次，避免持續使用舊連線及其建立時的處理結果。
  4. 查看連線記錄：在 App 提供的請求或連線記錄中，確認目標、策略及可用的命中資訊。若沒有記錄，先檢查請求是否進入目前的連線。
  5. 一次只改一項：先驗證規則位置，再驗證策略。若未成功，還原備份後重新測試，不要接連堆疊未經確認的例外規則。

規則加在最後了，為什麼還是採用原本的策略？

先確認新增規則是否位於 FINAL 之後，再向上搜尋可能涵蓋目標的 DOMAIN-SUFFIX 或其他規則。將新規則移到第一條涵蓋目標的規則之前，儲存後用新連線測試。不要依賴重複新增來改變結果。

已設定 DIRECT，為什麼還是無法開啟？

先確認請求記錄是否確實顯示採用 DIRECT。若是，接著檢查目前網路能否直接存取目標，以及網域解析是否正常；DIRECT 只指定對外連線方式，不保證目標在目前網路上可連線。

設定 REJECT 後，整個頁面都異常，該怎麼辦？

暫時移除剛新增的 REJECT 規則並重新發出請求，確認異常是否因此消失。若兩者有關，將範圍過廣的 DOMAIN-SUFFIX 縮小為需要封鎖的精確 DOMAIN，再檢查頁面依賴的其他資源網域。

更新設定後，手動撰寫的規則不見了？

先確認更新的是 Home 中既有訂閱的伺服器清單，還是 Config 中的遠端設定檔。重新取得遠端設定檔可能會覆蓋本機編輯內容；更新前先備份，更新後比對 [Rule] 段，並再次確認目前選取的設定檔。

若要回到基本設定，可參閱使用指南；若要確認 Global Routing 狀態，可參閱功能介紹中的 Global Routing 說明。驗證完成後保留必要的例外、刪除重複規則，讓下次檢查時仍能由上而下看懂整段設定。

取得 ShadowrocketApp Store 正版確認