Shadowrocket 規則類型解析：DOMAIN、DOMAIN-SUFFIX、GEOIP、FINAL 的比對方式

本文重點

Shadowrocket（小火箭）的規則需要同時確認比對對象、排列順序與執行策略。本文適合已有自己的服務商與設定、準備調整分流規則的使用者：先在 Config 啟用規則分流，再區分網域規則與 IP 規則，最後用 FINAL 處理未符合條件的連線。範例僅說明語法，不含可用的連線憑證。

先確認 Config：規則生效的前提

結論是：若要依設定中的規則分流，請前往 Home → Global Routing 選擇 Config，並確認 Config 頁面已選取要修改的設定。只儲存檔案卻未選取，或將 Global Routing 保持在 Proxy、Direct，都無法用來驗證這份設定是否依預期分流。

進入 Config，確認目前使用的設定；編輯前先保留副本，避免直接覆寫既有設定。
開啟該設定的編輯入口，找到 [Rule]。本文的程式碼應放在規則區段，不要貼到 Home 的伺服器位址欄位。
返回 Home → Global Routing，選擇 Config，再確認既有代理連線本身可正常使用。
儲存修改後重新發出目標請求，透過連線記錄確認目標、符合的規則與最終策略，不要只看 Home 的連線開關。

Proxy 用於將接管的連線交由代理處理，Direct 則直接連線；Scene 還需要檢查目前場景採用的設定。本文的驗證步驟統一使用 Config，避免將場景切換與規則修改混為一談。Settings → On Demand 控制依條件建立連線，不會決定某個網域符合哪一條規則。

6 種

本文涵蓋 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、FINAL

3 種

常見執行策略：PROXY、DIRECT、REJECT

1 條

最小範例會在規則末尾保留一條 FINAL 作為兜底

看懂規則語法：分開理解比對條件與執行策略

常見規則由規則類型、比對內容與執行策略組成，欄位之間以英文逗號分隔。規則類型說明「比對什麼」，執行策略則說明「符合條件後如何連線」。相同的網域條件可以搭配不同策略，因此不能把 DOMAIN-SUFFIX 理解為「自動走代理」。

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

以上片段用來展示六種語法，並非建議直接啟用的完整設定。例如第一條會先讓 example.com 符合 DIRECT，而不會繼續執行後面的 PROXY。FINAL 不需要網域或網段參數，因此寫成 FINAL,PROXY 即可，不要為了湊成三個欄位而加入空欄位。

策略	符合條件後的意義	需要確認的項目
`PROXY`	使用代理策略處理連線。	目前選用的代理及其連線參數是否可用。
`DIRECT`	直接連線至目標。	目前網路能否直接連線至目標。
`REJECT`	拒絕符合條件的連線。	比對範圍是否過廣，以及是否攔截頁面所需資源。

如果規則引用自訂策略群組，名稱必須與設定中的定義一致，並進一步確認群組內實際選用的項目。PROXY 也不等於某一種協定：Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 是連線設定層級的協定選擇，不能取代規則中的比對條件。

DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD 的適用範圍

只比對單一完整網域時使用 DOMAIN；比對主網域及其子網域時使用 DOMAIN-SUFFIX；只有確實需要搜尋網域中的字串時，才使用 DOMAIN-KEYWORD。常見錯誤包括把完整 URL 填入網域欄位，或以為後綴比對只會檢查結尾的幾個字元。

規則	會比對	不會比對
`DOMAIN,example.com,DIRECT`	`example.com`	`www.example.com`
`DOMAIN-SUFFIX,example.com,PROXY`	`example.com`、`img.example.com`	`notexample.com`、`example.com.test`
`DOMAIN-KEYWORD,example,REJECT`	`example.com`、`myexample.com`	`sample.test`

DOMAIN-SUFFIX 會依網域層級邊界比對，範例欄位填入 example.com 即可，不必加上 *.。DOMAIN-KEYWORD 不要求這個邊界，因此 example 也可能出現在其他不同歸屬的網域中；用於 REJECT 時尤其要縮小範圍。

網域欄位不要填入 https://，也不要加入網頁路徑或查詢參數。
造訪 https://example.com/docs 和 https://example.com/account 時，這三種網域規則看到的網域都相同，無法據此對兩個路徑分別分流。
一般網域規則不會因目標連接埠是 80 或 443 而改變比對範圍；連接埠不是 DOMAIN-SUFFIX 的第三個欄位。
如果請求只提供目標 IP，沒有可用的網域資訊，就不能期待網域規則憑空還原網站名稱。

GEOIP 與 IP-CIDR：依目標 IP 判斷，而非依網站名稱

GEOIP 依據 IP 地理位置資料判斷目標位址；IP-CIDR 則依明確的位址範圍判斷。兩者都不是用來檢查網頁文字、網站備案或網域後綴。以中文提供服務的網站，其連線位址不一定會被 GEOIP 判定為 CN；同一網域也可能在不同網路環境下解析到不同位址。

GEOIP,CN,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
IP-CIDR,198.51.100.8/32,REJECT
FINAL,PROXY

此處的 192.0.2.0/24 和 198.51.100.8/32 是文件範例位址，不是可用的伺服器位址。/24 表示前 24 位是網路前綴，範例涵蓋 192.0.2.0 至 192.0.2.255；IPv4 的 /32 只對應一個位址。IPv6 網段應使用對應的 IP-CIDR6 類型，不可直接套用 IPv4 範例。

若在 IP 規則末尾使用 no-resolve，目的是避免為這條 IP 規則主動進行網域解析，並非關閉所有 DNS。對於原本只有網域、沒有可用目標 IP 的連線，這類規則可能會被略過，繼續比對後續規則。初次建立最小測試時，請勿同時加入這個選項，以免混淆比對條件。

FINAL 與規則順序：符合條件就執行，不會自動優先選最精確的規則

本文介紹的一般規則，應依由上而下的順序理解：首次符合條件後就執行對應策略。DOMAIN 不會因為比 DOMAIN-SUFFIX 更精確，就自動跳過排在前面的規則。前面的條件都未符合時，才會使用 FINAL 作為兜底，因此應將它放在規則清單末尾。

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

這份最小範例會讓 account.example.com 直接連線，讓 example.com 及其餘子網域使用 PROXY，其他未符合條件的目標則使用 DIRECT。如果將前兩條對調，account.example.com 就會先符合後綴規則，後面的 DOMAIN 例外便無法再決定該次連線的走向。

取得目標資訊讀取第一條規則逐條檢查條件決定執行策略發起目標連線

FINAL 也不是「代理失敗後改為直接連線」的故障切換方式。連線一旦符合上方的 PROXY，之後即使逾時，也不代表會返回清單繼續執行 FINAL。若要修改未符合規則之流量的預設走向，請調整 FINAL 的策略；若要處理代理無法使用的問題，則應檢查連線參數或既有策略群組的選擇。

單一網域的例外規則應放在涵蓋該網域的後綴規則之前。
範圍較大的 DOMAIN-KEYWORD、GEOIP 規則，應確認是否會提前涵蓋後續的特殊需求。
REJECT 可能會在規則命中的位置阻擋連線；不要將範圍過廣的關鍵字當成精確攔截條件。
不要在 FINAL 之後再加入預期會生效的一般規則；新增規則前，先找出兜底行的位置。

儲存後如何驗證：每次只修改一個條件

驗證時，先確認「是否符合規則」，再確認「符合後能否成功連線」。瀏覽器顯示頁面載入失敗，不足以證明規則語法錯誤；頁面成功開啟，也不代表所有資源都使用相同策略。單一頁面可能同時請求主網域、圖片網域和 API 網域，必須分別檢查。

在 Config 儲存上述最小範例並確認已選用，再前往 Home → Global Routing 確認目前使用的是 Config。
先使用既有設定確認代理能否連線。若基礎連線本身失敗，請先修正位址、連接埠、驗證資訊及協定相關參數。
結束舊請求後重新造訪測試目標，避免使用仍在重複利用的連線判斷新規則。
在 App 的連線記錄中查看實際目標、符合的規則與策略。測試網域必須是自己確實需要造訪的目標；本文保留的網域僅用於說明語法。
若主頁正常但圖片載入失敗，請找出圖片請求所用的網域，再決定要新增 DOMAIN 或 DOMAIN-SUFFIX；不要先擴大比對範圍，改用含糊的關鍵字。
記錄修改前後的結果，每次只變更一條規則。確認無誤後，再逐步整合回完整設定。

以下兩類錯誤發生在連線層，並非某條規則專屬的語法提示；實際顯示文字可能包含系統或協定資訊。請先查看記錄中的實際輸出策略，再沿著對應連線排查，不要一看到錯誤就刪除 FINAL。

錯誤：Connection refused

原因與解決方式：連線的目標連接埠拒絕建立連線，可能是對應服務未在該連接埠監聽，或連接埠設定不符。先確認記錄中的策略是 DIRECT 還是 PROXY；若為 DIRECT，請檢查目標服務的連接埠；若為 PROXY，則檢查既有代理的位址、連接埠與服務狀態。

錯誤：Connection timed out

原因與解決方式：連線未能在等待時間內完成，可能與網路連通性或輸出連線有關。先使用相同設定確認其他目標，再檢查該次連線符合的規則與策略；不要只因逾時就將網域規則改成 IP 規則。

常見問題：規則設定正確，結果卻不如預期

已新增 DOMAIN-SUFFIX，為什麼還是直接連線？

先前往 Home → Global Routing 確認選擇的是 Config，再到 Config 確認編輯的是目前選用的設定。接著檢查後綴規則之前是否已有 DOMAIN、DOMAIN-KEYWORD 或其他可能符合的規則，然後重新發起連線並查看記錄。

只想讓指定網站走代理，FINAL 應該怎麼設定？

將需要走代理的網域寫成 DOMAIN-SUFFIX,example.com,PROXY，並在末尾使用 FINAL,DIRECT。實際使用時，請將範例網域換成自己的目標，並補上頁面所需的其他網域；這不會自動為所有頁面資源產生規則。

可以把 GEOIP,CN,DIRECT 放在最前面嗎？

語法上可行，但先符合 GEOIP 的連線可能會被該規則處理，影響你希望強制使用代理的目標。若某個網域必須使用 PROXY，通常應先放入該網域的明確規則，再放 GEOIP，最後放 FINAL，並透過實際連線記錄確認結果。

更新 Home 中已有的訂閱，會一併修改分流規則嗎？

請區分伺服器訂閱與 Config 中的設定檔。更新伺服器訂閱主要是更新連線項目，不能因此認定目前設定中的規則也已同步變更。更新後請分別檢查 Home 的連線選擇與 Config 的規則內容，並保留自己的修改副本。

加入 REJECT 後頁面變成空白，是代理故障嗎？

先查看載入失敗的資源是否符合 REJECT。若誤攔截了 API 或指令碼，請將必要網域的例外規則放在範圍較廣的攔截規則之前，或縮小攔截範圍。REJECT 代表明確拒絕連線，不應以「連線失敗」判斷代理是否可用。

規則的作用範圍：負責選擇輸出方式，不會補齊服務

規則可以決定連線使用 DIRECT、PROXY 或 REJECT，但不會產生可用的代理服務，也無法修正不一致的協定參數。符合 PROXY 後仍須依賴既有連線設定；符合 DIRECT 後則仍會受到目前網路與目標服務狀態影響。應分別驗證「規則比對正確」與「連線成功」。

比對層：確認網域或 IP 是否符合條件，以及規則順序是否正確。
策略層：確認規則引用的策略、策略群組及目前選擇。
連線層：確認實際輸出連線所需的位址、連接埠、驗證資訊與協定參數。
維護層：訂閱或遠端設定更新後，重新確認選用狀態，避免將舊的驗證結果套用到已變更的設定。

Shadowrocket 主要供 iPhone 與 iPad 使用，唯一取得管道為 App Store，系統需求請以 App Store 頁面標示為準。App 一次性買斷不等於線路方案；本文以使用者已有自己的服務商與設定為前提。若要了解規則結構，可接著查看規則手冊；初次設定則可依照教學逐步完成。