Shadowrocket 分流規則怎麼設定：比對順序、FINAL 兜底與 PROXY/DIRECT/REJECT 策略

一、先確認 Global Routing，再檢查規則

規則寫入檔案，不代表目前的請求一定會依該檔案分流。Home 用來管理連線與服務項目，Config 用來管理設定檔，Settings 用來設定 App。排查時，先確認連線使用的設定檔，再查看 Home → Global Routing。本文說明規則時，前提是使用 Config；若以 Proxy 或 Direct 暫時覆寫分流，則不適用。

Global Routing 中的 Scene 涉及情境選擇，應確認該情境目前採用的設定；它不是可寫在 [Rule] 內的規則關鍵字。初次驗證規則時，建議明確切換至 Config，以減少變因。Settings → On Demand 控制依條件觸發連線的行為，不會改變規則的先後順序。

二、規則語法：條件在前，策略在後

設定檔中的規則位於 [Rule] 區段。常見規則採用「類型,比對值,策略」的結構，欄位之間以英文半形逗號分隔。以下三行分別示範精確網域、網域後綴與最終策略；示範網域僅用於說明，請勿直接照搬為實際業務清單。

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

PROXY 不是服務位址，也不是協定名稱。Shadowsocks、VMess、VLESS、Trojan、Hysteria2 與 WireGuard 屬於連線協定；規則決定請求採用哪種策略，服務項目則提供實際連線參數。請勿將協定名稱、訂閱網址或伺服器連接埠填入規則的策略欄位。若使用自訂策略組，其名稱必須與設定檔中的名稱一致。

三、比對順序：上方符合後，下方不再比對

規則會由上而下依序檢查，符合後便執行對應策略。並非「越精確就會自動優先」，也不會合併所有符合的結果。以上方範例來說，api.example.com 先符合 DOMAIN，因此使用 PROXY；img.example.com 不符合第一行，接著符合 DOMAIN-SUFFIX，因此使用 DIRECT。

1. 精確例外優先。需要個別處理的完整網域可放在寬泛的後綴規則前，例如將 DOMAIN,api.example.com,PROXY 放在 DOMAIN-SUFFIX,example.com,DIRECT 之前。
2. 接著放範圍規則。DOMAIN-SUFFIX 同時涵蓋指定網域本身及其子網域。example.com 會涵蓋 example.com 和 a.example.com，但不會匹配任意包含這段文字的網域。
3. 拒絕規則請謹慎安排。若先寫入 DOMAIN-SUFFIX,example.com,REJECT，後面針對 api.example.com 的允許規則就不會有機會執行。
4. 最後放置 FINAL。只有前面的條件都未符合時，才會採用最終策略；FINAL 後方的規則無法正常進行後續比對。

交換前兩行的順序，結果就會不同。以下寫法會讓 api.example.com 先符合第一行並直接連線；即使第二行更精確，也不會推翻已產生的結果。

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

四、FINAL 兜底與 IP 規則的搭配方式

FINAL 不需要網域或網段參數，正確格式是 FINAL,策略，例如 FINAL,PROXY 或 FINAL,DIRECT。它不是失敗重試機制：若某條 PROXY 規則已符合但連線失敗，不會因此繼續往下找到 FINAL 改用 DIRECT。兜底處理的是「沒有符合任何條件」，而非「連線未成功」。

no-resolve 用來避免為了比對這條 IP 規則而額外進行網域解析。它不等於關閉整個 App 的 DNS，也不會自動將網域轉成 IP。若請求本身已有可用的目標 IP，仍可依該 IP 進行比對；若只有網域且尚無可用 IP，就不能認定這條規則一定會符合。

GEOIP 的結果會受到目標 IP 與本機資料庫影響。同一個網域若解析出不同結果，符合的地理區域條件也可能不同。少數必須採用固定策略的業務網域，建議先設定明確的 DOMAIN 或 DOMAIN-SUFFIX 例外，再安排 GEOIP 等範圍較廣的條件。請勿將「解析成功」、「符合規則」與「成功建立連線」視為同一件事。

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

以上片段僅示範一種排列方式，不是完整設定，也不是適用於所有網路的建議清單。採用前請確認區域網路網段、目標網域與最終策略都符合自身需求。若目標實際使用 IPv6，單一 IPv4 的 IP-CIDR 規則無法涵蓋對應的 IPv6 位址，需另外檢查相關規則與網路條件。

五、儲存後如何確認比對結果

驗證單位應是新建立的連線，而非已開啟的頁面。瀏覽器可能重複使用舊連線，網頁也可能直接顯示快取；只看頁面是否仍能開啟，無法判斷剛才的規則是否生效。修改前先儲存原設定，測試期間每次只變更一項條件或策略。

1. 確認設定檔

   進入 Config，確認目前選用的檔案。編輯該檔案的 [Rule] 區段並儲存，請勿只修改另一份未啟用的副本。

2. 固定模式

   返回 Home → Global Routing → Config，確認選取的是 Config，而非 Proxy、Direct 或尚未確認的 Scene。

3. 重新建立連線

   讓設定重新生效後，再次發出目標請求；必要時中斷連線並重新連線。關閉測試頁面使用的舊連線，避免將重複使用連線誤判為新規則未生效。

4. 檢查記錄

   查看請求記錄中實際出現的目標網域或 IP、符合的規則及採用的策略。若頁面涉及多個網域，請逐一區分主文件、登入介面與資源請求。

5. 還原測試項目

   記下原有規則、變更內容與結果，並還原臨時新增的拒絕或例外規則。請勿將測試用的 REJECT 留在需要正常存取的業務網域上。

例如，將已獲授權的測試網域設為 REJECT 後，新的目標請求應顯示遭拒絕；但頁面上的舊文字仍可能來自快取，其他網域載入的圖片也可能繼續顯示。這是驗證方式的示例，並非本站實測資料。判斷時應以對應請求的記錄為準，而不是要求整個網頁立即變成空白。

六、規則分流常見問題

整理設定時，先確保少量規則就能解釋每次測試結果，再逐步擴大範圍。每新增一條規則，都應能回答三個問題：它會比對什麼、前面是否已有涵蓋它的條件，以及符合後會採用什麼策略。只要這三點清楚，FINAL 就只是最後一項明確選擇，而不是掩蓋前面規則錯誤的補丁。