Shadowrocket 規則設定入門：DOMAIN-SUFFIX、GEOIP、IP-CIDR 與 FINAL 比對順序

一、先確認 Global Routing，再檢查規則是否命中

規則檔案存在，不代表目前連線正依照該檔案分流。Home 管理連線與所選的輸出端，Config 管理設定檔，Settings 管理應用程式設定。開始排查前，先記下 Home → Global Routing 目前的選項，再到 Config 確認正在使用的檔案；「檔案已下載」和「檔案已啟用」是兩件事。

Settings → On Demand 管理依條件建立連線的行為，並非控制規則清單優先順序的開關。系統顯示 VPN 已連線，也只代表隧道目前處於連線狀態；個別請求是否經過代理，仍須依據路由方式、命中規則與最終策略判斷。

二、讀懂一行規則：類型、比對值與策略

常見規則以英文逗號分隔。以 DOMAIN-SUFFIX,example.com,DIRECT 為例，第一個欄位指定比對方式，第二個欄位是比對目標，第三個欄位則決定命中後的處理方式。設定檔中的一般規則放在 [Rule] 區段，不能隨意把一行規則貼到檔案末尾，而不確認所在區段。

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECT

這是語法示範，並非適用於所有需求的完整設定。192.0.2.0/24 是文件中的示範網段；所有規則都指向 DIRECT，是為了先觀察比對結果，不引入尚未定義的代理策略。請勿直接用它覆蓋既有設定。

• DIRECT 代表直接連線，不表示這次請求一定成功；目標服務仍可能無法連線。
• 規則使用 PROXY 或自訂策略名稱時，請先確認目前設定中有可用的對應策略或策略群組，且拼字與設定一致。不要把任意字詞當成已存在的輸出端。
• FINAL 沒有網域或網段欄位，通常寫成 FINAL,DIRECT，不要套用三欄位格式。
• 請使用半形英文逗號。網域欄位不包含 https://、連接埠、路徑或查詢參數。

例如，瀏覽器造訪 https://docs.example.com:443/help 時，網域規則比對的是 docs.example.com。其中 443 是連線埠，/help 是 URL 路徑；兩者都不是 DOMAIN-SUFFIX 的比對值。協定連線參數與分流規則屬於不同層次，不應在網域欄位填入協定名稱。

三、DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD 的差異

這三個關鍵字都用於比對網域，但涵蓋範圍不同。需要精確設定例外時，優先考慮 DOMAIN；需要涵蓋整個網域及其子網域時，再考慮 DOMAIN-SUFFIX。DOMAIN-KEYWORD 涵蓋範圍較廣，請確認不會一併匹配其他僅包含相同字串的網域。

DOMAIN-SUFFIX 依網域層級邊界判斷，不是任意比對字串結尾。通常直接填入 example.com，不必加上 *.。若只要匹配 api.example.com，使用 DOMAIN 可避免一併涵蓋同網域下的其他主機。

四、IP-CIDR、GEOIP 與 DNS 的關係

IP-CIDR 比對目標 IP 位址是否位於指定網段，而不是比對網域文字。192.0.2.0/24 表示這個 IPv4 網段，192.0.2.18/32 則表示單一 IPv4 位址。前綴數字不是連接埠，也不是優先順序；數字越大，網段範圍通常越小，但不會因此自動排到清單前面。

IP-CIDR,192.0.2.18/32,DIRECT,no-resolve
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

GEOIP 依據目標 IP 在位址資料庫中的歸屬資訊進行比對。例如 GEOIP,CN,DIRECT 會匹配資料庫歸屬為 CN 的位址，不代表比對中文網頁，也不是檢查網域是否以 .cn 結尾。內容傳遞、位址變動與資料庫資訊都可能使實際結果不同於依網站名稱所做的推測。

• 請求帶有網域時：檢查部分 IP 類規則可能需要解析位址，因此 DNS 結果可能影響後續判斷。
• 使用 no-resolve 時：這類 IP 規則不會為了比對而主動觸發網域解析；它不是全域關閉 DNS 的設定。
• 請求本身是 IP 時：可以直接檢查網段或位址歸屬，但不能假設一定能還原原本的網域。
• 測試位址變動時：同一個網域可能解析出多個位址，IPv4 與 IPv6 的實際路徑也可能不同，請檢查這次連線的目標位址。

因此，「網域看起來屬於某個地區」不等於「GEOIP 一定會命中」。排查時應先確認實際目標，再檢查解析結果與資料庫判定。如果尚未取得可供判斷的位址，帶有 no-resolve 的 IP 類規則可能不會匹配，流量會繼續檢查後續規則。

五、由上而下比對：精確例外在前，FINAL 在後

一般規則依設定中的順序逐一檢查，命中後便採用對應策略，不會繼續往下尋找「更精確」的規則。DOMAIN 不會自然優先於 DOMAIN-SUFFIX，單一位址規則也不會自然優先於大網段規則；若要讓例外優先，必須將它放在涵蓋範圍較大的規則之前。

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

此範例的前提是目前設定中已有可用的 PROXY 策略。造訪 login.example.com 時，第一條規則已命中，因此直接連線；造訪 img.example.com 時，第一條不匹配，第二條命中並交由 PROXY 處理。若將第二條移到第一條之前，登入網域也會先命中後綴規則，後面的精確例外便無法生效。

1. 先加入明確的主機例外，例如單一登入網域。
2. 接著加入網域後綴、關鍵字或其他整理好的規則，並留意彼此涵蓋的範圍。
3. 安排位址類規則時，確認是否允許為比對而進行解析，以及是否會涵蓋後續規則。
4. 將 FINAL 放在最後，作為前面規則都未命中時的最終處理方式。

FINAL 不是連線失敗後的備援選項。某條規則命中 PROXY 後，若對應連線逾時，不會因此繼續往下套用 FINAL。連線失敗後的切換行為取決於所用策略群組及其設定，無法透過在 FINAL 後追加另一條規則達成。

六、從備份到驗證：一次只修改一條規則

以下步驟假設使用者已備有自己的連線設定。修改前請保留原始檔案，先驗證一條目標明確的網域規則，再考慮批次整理。遠端設定更新可能覆蓋本機修改，因此請區分自行編輯的副本與日後會重新取得的檔案。

1. 保留原始設定

   進入 Config，確認目前使用的設定檔，並保留可還原的副本。記下原本的 Global Routing 選項與目標規則順序，不要一開始就刪除整個規則區段。

2. 修改規則區段

   在 Config 中開啟待修改檔案的編輯功能，找到 [Rule]，加入一條針對自己測試網域的 DOMAIN 規則。儲存後確認目前啟用的是修改後的檔案；實際編輯入口以應用程式內顯示為準。

3. 確認路由

   返回 Home → Global Routing → Config。確認連線已啟用，且所使用的代理策略有可用的輸出端；若使用 Scene，請先記下場景設定，避免將場景切換誤認為規則變動。

4. 重新發出請求

   讓目標應用程式重新建立連線，再檢查連線記錄中的目標網域、位址、命中規則與策略。既有長連線可能沿用原路徑，單純儲存檔案不一定會立即重建舊連線。

5. 比對結果後還原

   逐項比對實際結果與預期：先確認命中規則，再確認連線是否成功。測試完成後，移除臨時規則或還原原始檔案，並恢復原本的 Global Routing 選項。

不要只用 Home 中的延遲測試來判定規則是否正確。延遲測試針對所選輸出端的測試目標，瀏覽器請求則可能涉及不同的網域、位址與連接埠。記錄「目標網域、目標連接埠、命中規則、最終策略、錯誤狀況」這五項，比反覆切換所有設定更有助於重現問題。

七、分開排查連線錯誤與規則錯誤

以下列出網路診斷中常見的英文錯誤訊息。實際介面可能顯示更完整的上下文，不應假設每次都使用相同措辭。先確認請求命中了哪條規則，再沿著該規則選擇的路徑排查；不要一看到逾時，就立刻把所有請求改用相同策略。

如果檔案無法正常儲存或載入，先檢查區段名稱、英文逗號、策略名稱與欄位數量；如果檔案可用但命中錯誤，先檢查規則順序與比對範圍；如果命中正確但仍無法連線，再檢查連線路徑。這三種情況的處理方向不同。