Shadowrocket 規則設定入門：DOMAIN、DOMAIN-SUFFIX、GEOIP、IP-CIDR、FINAL 的比對方式

本文重點

Shadowrocket（小火箭）的規則由比對條件與處理策略組成。本文適合已備妥自己的連線設定，並準備在 Config 中修改分流規則的使用者：先分辨網域與 IP 比對方式，再檢查規則順序，最後以實際請求確認命中結果。範例網域與位址僅用於說明語法，並非可用的連線服務。

一、先確認規則在哪種模式下生效

在 Home 查看 Global Routing。本文討論的是選擇 Config 後，依目前設定中的規則決定連線出口的情況。Proxy 以代理方式處理流量，Direct 則以直連方式處理流量；在這兩種模式下，不要只憑網頁能否開啟，就判斷某條 Config 規則是否生效。Scene 用於依情境選擇，需另外確認情境條件與實際採用的路由設定。

規則決定的是「這次連線交由哪種方式處理」，而不是「代理伺服器能否連線」。即使規則正確命中 PROXY，若現有伺服器無法使用，請求仍可能失敗。DIRECT 也只是選擇直連，不保證目前網路一定能連上目標網站。

請求進入隧道讀取目標資訊依序檢查規則採用命中策略建立連線出口

理解一行規則時，可以先拆成三個部分。第二段是比對值，第三段是策略；FINAL 不需要比對值，因此只有兩段。欄位之間以半形逗號分隔，請勿改用全形逗號。

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

DOMAIN：比對類型，要求目標網域完全相同。
api.example.com：比對值，不含通訊協定、連接埠與 URL 路徑。
PROXY：交由代理策略處理，仍須有可用的代理設定。
FINAL,DIRECT：前面的規則都未命中時，採用直連。

二、DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD 的比對範圍

這三種關鍵字都以網域為比對對象，但涵蓋範圍不同。取得完整網址後，應先找出主機名稱。例如 https://api.example.com:8443/v1/status 的主機名稱是 api.example.com；8443 是連接埠，/v1/status 是路徑，兩者都不能放進 DOMAIN 的比對值。

關鍵字	規則範例	比對範圍
DOMAIN	`DOMAIN,api.example.com,PROXY`	只比對 api.example.com，不包含其下層子網域。
DOMAIN-SUFFIX	`DOMAIN-SUFFIX,example.com,PROXY`	比對 example.com，以及 api.example.com 等子網域。
DOMAIN-KEYWORD	`DOMAIN-KEYWORD,example,PROXY`	比對網域中含有 example 字串的目標，涵蓋範圍較廣。

精確主機、整組子網域與關鍵字

只想讓單一 API 主機走代理時，先用 DOMAIN；若要涵蓋同一網域下的主站、圖片站與 API 主機，使用 DOMAIN-SUFFIX 會更容易維護。後綴會依網域層級比對，example.com 不會因此匹配 notexample.com，也不會匹配 example.com.other.test。

DOMAIN-KEYWORD 是字串包含比對。關鍵字 example 可以涵蓋不同後綴中含有相同字串的網域，也可能匹配到無關網域。它無法辨識網站歸屬、品牌關係或網頁內容。若能用精確網域表達需求，就不必為了縮短規則而改用範圍較廣的關鍵字。

三、IP-CIDR 與 GEOIP 比對目標 IP

IP-CIDR 會依目標 IP 是否位於指定網段內進行比對；GEOIP 則依 IP 地理資料庫中的歸屬進行判斷。這些判斷與網頁語言、網域後綴或帳號地區無關。透過網域連線時，可能要先取得解析結果，才能進行相應的 IP 判斷；直接連線至 IP 時，則沒有一般網域規則可比對的主機名稱。

[Rule]
IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

192.168.50.0/24 表示 IPv4 網段，涵蓋 192.168.50.0 至 192.168.50.255 的位址範圍，不是指「連接埠 24」。
no-resolve 表示不要只為這條 IP 規則主動解析網域；它不代表關閉所有 DNS，也不是直連開關。
GEOIP,CN,DIRECT 表示資料庫將目標 IP 歸類為 CN 時採用 DIRECT，而不是「中文網站直連」。
IPv6 網段應使用對應的 IP-CIDR6 寫法，不要將 IPv6 位址當成 IPv4 網段填入。

上方的區域網路網段僅為語法範例。實際路由器可能使用 192.168.1.0/24 或其他位址範圍，請依目前網路設定填寫。不要為了涵蓋單一裝置而任意加入較大的網段，否則其他位址也會套用相同策略。

GEOIP 的結果取決於資料庫與目標 IP。使用 CDN 的網站可能在不同網路下解析出不同位址；修改 DNS 後，歸屬判斷也可能改變。因此，「昨天走 DIRECT，今天走 PROXY」不一定代表規則檔案損壞，應一併確認網域、解析結果與命中規則。

四、規則由上而下檢查，FINAL 放在最後

在本文所述的一般規則清單中，系統會由上而下依序檢查，第一條符合的規則就會決定處理策略。並不是「所有規則中最精確的一條會自動優先」。若範圍較廣的規則先命中，後面的精確規則就沒有機會生效。

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

在上述範例中，api.example.com 先命中 DOMAIN，採用 PROXY；www.example.com 未命中第一行，但命中第二行，採用 DIRECT。若將前兩行對調，API 主機也會先被 DOMAIN-SUFFIX 匹配。這就是「例外規則先寫，通用範圍後寫」的原因。

目標	第一條命中的規則	策略
`api.example.com`	DOMAIN	PROXY
`www.example.com`	DOMAIN-SUFFIX	DIRECT
其他網域，目標 IP 歸類為 CN	GEOIP	DIRECT
其他網域，且未命中 GEOIP	FINAL	PROXY

只讓列出的網域走代理

若需求是「只有指定網站走代理，其餘直連」，可以從以下最精簡的片段開始。這裡沒有加入 GEOIP，因為此需求不需要依地區增加另一層判斷。規則較少不代表功能不完整，重點是策略能否準確符合需求。

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

五、在 Config 修改後，以新連線驗證

開始前應已備妥自己的服務供應商與可用設定。編輯規則不必重新購買用戶端，也不需要更換通訊協定；Shadowsocks、VMess、VLESS、Trojan 等通訊協定負責代理連線，本節介紹的關鍵字則用來決定請求是否交由代理處理。兩者屬於不同層次。

保留原有設定

進入 Config，先保留目前設定的副本或匯出備份，並記下正在使用的設定。遠端設定更新可能會覆蓋本機修改，請勿只在唯一副本上反覆測試。
編輯規則區段

在 Config 開啟目標設定的編輯入口，找到 [Rule]。請在現有規則區段中調整內容，不要將整段範例重複貼到檔案末端，造成多個同名區段。
檢查欄位順序

使用半形逗號；網域欄位請移除 https://、連接埠與路徑。精確例外應放在通用規則前，FINAL 放在最後，並確認策略名稱拼寫正確。
啟用目標設定

儲存並選用剛修改的設定，返回 Home → Global Routing → Config。再確認 Home 中選用的是現有且可用的伺服器，避免將連線故障誤認為規則問題。
建立新請求

重新建立連線後，前往測試目標，並在 Data 中確認新請求的目標、策略與命中資訊。舊連線可能沿用原本的連線出口，不能只重新整理持續重複使用同一連線的頁面就下結論。

每次只修改一個條件。例如先驗證精確的 DOMAIN，再擴大為 DOMAIN-SUFFIX，最後才加入 IP 判斷。記錄預期策略與實際策略，比一次加入數十條規則更容易找出問題。範例網域僅用於說明語法，實際驗證時應改用自己確實需要連線的目標。

六、分別排查「是否命中」與「能否連線」

排查時先查看 Data 中的新請求是否採用預期策略，再檢查目標能否連線。若命中策略有誤，請回頭檢查目前的 Config、Global Routing 與前置規則；若策略正確但連線逾時，則繼續檢查代理連線狀態、DNS 與目標伺服器，不要立刻把規則改成範圍更廣的關鍵字。

以下是 Apple 網路錯誤的標準識別碼，可能出現在系統或 App 的詳細錯誤資訊中；不同請求入口顯示的文字可能有所不同。這些錯誤代表連線失敗，不是 Shadowrocket 規則語法錯誤提示，也不能只憑錯誤碼判斷應使用 DIRECT 或 PROXY。

NSURLErrorDomain Code=-1001

原因：請求等待逾時，可能發生在代理連線或等待目標回應的階段。

解法：先確認 Data 中採用的策略，再分別測試目前伺服器與同一目標是否可連線，避免只調整規則順序來掩蓋逾時原因。

NSURLErrorDomain Code=-1003

原因：找不到指定主機，請優先檢查網域拼寫與 DNS 解析條件。

解法：確認請求的主機名稱正確，再檢查目前的 DNS 設定；為網域新增 PROXY 規則並不能修復網域解析問題。

已設定 DOMAIN-SUFFIX，為什麼還是走直連？

先到 Home → Global Routing 確認已選擇 Config，再檢查 Config 中選用的檔案。若兩者都正確，請確認該規則之前是否已有 DOMAIN、其他後綴規則或 FINAL 優先命中，並在 Data 中確認實際請求的主機名稱。

網站能開啟，圖片卻載入失敗？

網頁與圖片可能來自不同網域。重新載入後，查看 Data 中載入失敗的資源所屬主機，並依實際用途補上精確規則；不要只根據頁面網址，就推定所有資源都使用相同的 DOMAIN-SUFFIX。

IP-CIDR 加上 no-resolve 後，為什麼沒有命中？

若請求以網域名稱發起，當下又沒有可供比對的目標 IP，這條規則就不會為了判斷網段而主動解析。若明確需要依網域分流，請直接設定網域規則；若確實要依解析出的 IP 判斷，再評估是否保留 no-resolve。

修改規則後，重新連線卻又恢復原狀？

先確認編輯的是目前啟用的檔案，再檢查是否發生遠端設定更新。連線訂閱與規則設定不是同一份內容；請保留本機修改副本，並在更新後檢查規則差異。Settings → On Demand 控制按需求連線，不負責儲存或還原規則。

最後可依四項逐一確認：Global Routing 設為 Config、目前使用的設定確實包含修改、第一條命中的規則符合預期，以及對應的連線出口能成功建立連線。依此順序驗證，才能分辨問題是由語法、順序、DNS 還是連線狀態造成。