Shadowrocket 自訂規則設定：匹配順序、FINAL 預設策略與 PROXY/DIRECT/REJECT

本文重點

自訂規則用來決定請求採用哪種連線策略，適合已在 Shadowrocket 設定好自己的服務，並需要調整分流結果的使用者。本文先確認 Global Routing 的運作模式，再說明規則語法、例外順序與 FINAL 的位置，最後介紹儲存和驗證步驟；預設策略以目前的 Config 為準，不應把任何範例視為適用於所有網路環境的通用設定。

Global Routing：先確認規則是否參與處理

Global Routing 是 Home 中控制整體路由方式的設定，與單一規則的策略不同。Shadowrocket（小火箭）的自訂規則主要在 Config 模式下參與分流；編輯前請前往 Home → Global Routing 確認目前選項，再到 Config 核對正在使用的設定檔。預設選項以 App 目前顯示為準，本文的規則驗證一律使用 Config。

Config

建議

依目前設定中的規則決定請求的去向。選取 Config 不代表所有請求都會使用 PROXY，最終結果仍取決於實際匹配到的規則。

適用情境：撰寫自訂規則、驗證網域例外與最終策略。

Proxy

將整體路由設為代理模式，不依照本文介紹的一般規則清單逐條分流。可暫時用來比較同一目標經代理存取的結果，測試後請恢復原設定。

適用情境：排除規則影響，確認現有代理連線是否可用。

Direct

將整體路由設為直連模式。此時變更一般分流規則，不能作為判斷規則是否正確生效的依據。

適用情境：確認目前網路能否直接連線至目標。

Scene

依已設定的場景管理路由選擇。排查時須一併核對場景條件與對應動作，不能只查看某個設定檔中的規則文字。

適用情境：已明確設定場景條件，並需要依環境切換路由的使用方式。

On Demand 是連線觸發機制，不能取代 DOMAIN-SUFFIX 等規則。如果中斷連線後又自動重新連線，請另外檢查 Settings → On Demand 的目前條件；若連線已建立，但請求去向不符，則優先檢查 Global Routing、目前的 Config 與匹配到的規則。這兩類問題應分開處理。

規則語法：分別撰寫匹配條件與處理策略

規則行由規則類型、匹配值與策略組成，常見格式為 類型,匹配值,策略。FINAL 沒有匹配值，只需填寫最終策略。編輯純文字時請使用英文半形逗號；網域匹配值不應包含網址中的通訊協定前綴、路徑或查詢參數。以下內容屬於設定檔的 [Rule] 區段，而非 Home 中的伺服器位址欄。

3 類

本文的匹配條件：DOMAIN-SUFFIX / IP-CIDR / GEOIP

3 種

本文的基本策略：PROXY / DIRECT / REJECT

1 條

範例只保留一條 FINAL，並放在規則末尾

關鍵字	範例寫法	匹配說明
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,PROXY`	匹配 example.com 本身及其子網域，不匹配 notexample.com。
`IP-CIDR`	`IP-CIDR,192.168.1.0/24,DIRECT,no-resolve`	匹配指定的 IPv4 網段；no-resolve 可避免僅為這條規則主動解析網域。
`GEOIP`	`GEOIP,CN,DIRECT`	依據 IP 地理資料庫判斷位址所屬地區，不依據網頁語言或網域後綴判斷。
`FINAL`	`FINAL,PROXY`	接收前面規則都未匹配的請求，並採用指定策略。

IP-CIDR 中的 /24 是網路前綴長度，上例涵蓋 192.168.1.0 至 192.168.1.255。若只針對單一 IPv4 位址，可使用 /32。這些數值不是伺服器連接埠；網域規則也不應寫成 example.com:443。依連接埠區分請求屬於另一種匹配需求，無法透過修改 DOMAIN-SUFFIX 的匹配值達成。

匹配順序：先寫明確例外，再寫廣泛條件

規則順序是逐條判斷的優先順序，不是系統自動計算的「最精確匹配」。在一般規則分流過程中，請求匹配到前方的有效規則後便會採用該策略，不會再由後方的一般規則覆蓋。因此，明確的網域例外應放在較大範圍的網域規則之前，網段與地區規則則放在適當位置，FINAL 留在最後。

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

這段範例用來說明規則順序：api.example.com 匹配第一條規則並走 DIRECT；www.example.com 匹配第二條規則並走 PROXY；直接連線至 192.168.1.20 時則由網段規則處理。其他請求是否匹配 GEOIP，取決於目標位址與資料庫結果；只有前面的規則都未匹配時，才會套用 FINAL。example.com 是說明用網域，不代表有可用服務。

若將 DOMAIN-SUFFIX,example.com,PROXY 移到精確網域規則之前，api.example.com 會先匹配這條規則，後面的 DIRECT 例外便不會生效。
若將 GEOIP,CN,DIRECT 放在某些網域例外之前，當目標 IP 資訊可用時，可能會先匹配地區條件；有明確去向要求的網域應優先列出。
若將 FINAL,PROXY 放在規則中間，後面的常規規則便無法發揮預期的匹配作用；新增規則應插在 FINAL 之前。
同一網域重複出現且策略相反時，以先匹配到的規則為準。排查時請搜尋整個規則區段，不要只查看剛新增的一行。

PROXY、DIRECT、REJECT：依目標選擇策略

策略說明匹配後要採取的處理方式，不代表規則的匹配範圍。PROXY 會將請求交由代理路徑處理，DIRECT 會透過目前網路直接連線，REJECT 則會拒絕請求。預設最終策略以目前的 Config 為準；建議先決定未分類流量預期的去向，再選擇 FINAL，不要未經驗證就一律替換。

策略	適用條件	驗證重點
`PROXY`	明確需要透過使用者現有的代理服務存取該目標。	確認目前選取的服務或策略群組及其連線狀態；規則匹配不代表遠端連線成功。
`DIRECT`	區域網路裝置，或已確認可透過目前網路直接存取的目標。	檢查本機路由、網路權限與目標服務本身；DIRECT 仍需要正常的 DNS 與網路連線。
`REJECT`	明確不希望建立連線，且已確認拒絕該目標不會造成問題。	先用精確的 DOMAIN 範圍測試，避免誤拒絕登入、付款或頁面所依賴的公用網域。

FINAL,PROXY 表示未分類請求仍透過代理處理，適合明確希望保留此預設行為的設定；FINAL,DIRECT 則會讓未分類請求直接連線，適合已充分列出代理目標的設定。兩者沒有脫離使用目的的絕對優劣。若將 FINAL 設為 REJECT，所有未列出的請求都會遭到拒絕，新加入的網域也可能立即無法使用，因此不建議將它作為初次撰寫規則的起點。

DOMAIN,blocked.example.com,REJECT
DOMAIN,printer.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

上例展示同一網域範圍內的策略例外，不是可直接套用的連線方案。PROXY 的實際出口也須配合目前選取的服務，以及設定中引用的策略名稱進行核對；如果規則引用自訂策略群組，必須確認名稱與設定檔定義一致。不要將 Global Routing 中的 Proxy 模式與規則行中的 PROXY 視為同一層設定。

儲存與驗證：一次只修改一項

驗證的目的，是確認「編輯內容」、「目前啟用的檔案」與「實際請求結果」彼此對應。開始前，請在 Config 保留原始檔案的副本，並記錄原本的 Global Routing 選項。本文假設使用者已有自己的服務與訂閱，只調整路由規則；Home 中的 Subscribe 更新與 Config 檔案更新是不同項目，重新整理伺服器訂閱不代表正在使用的規則已經替換。

確認模式

前往 Home → Global Routing → Config。記錄 Home 目前選取的服務，避免同時修改規則與切換服務，導致結果無法比較。
找到設定檔

前往 Config，確認目前選取的設定檔；開啟該檔案的編輯入口，並核對 Rule 清單或純文字中的 [Rule] 區段。不同編輯畫面的入口名稱以 App 目前顯示為準。
新增例外

在較廣泛的規則與 FINAL 之前插入一條明確指定目標的規則。若使用純文字編輯，只修改既有的 [Rule] 區段，不要將範例重複貼成兩個規則區段。
儲存並套用

儲存後返回 Config，確認仍選取已修改的檔案，再返回 Home。必要時先中斷連線，再重新建立連線，以新的請求進行驗證；現有的長連線不適合用來判斷修改是否立即生效。
核對記錄

重新存取目標，並在 App 的請求記錄中核對目標網域或 IP、使用的策略及可查看的規則資訊；Settings → Log 可用於進一步查閱診斷資訊，實際記錄欄位以目前畫面為準。

合格的驗證記錄至少包含目標、預期策略與實際策略三項。例如，針對自己的測試目標記錄：「精確網域規則預期使用 DIRECT，記錄也顯示 DIRECT」；若結果是 PROXY，請先檢查目前使用的檔案與上方的廣泛規則，不要立即修改 DNS。本文的範例推演不代表實際網路測試，也不提供可直接存取的測試服務。

DNS 與位址規則：別把解析問題當成順序問題

DNS 會將網域轉換成位址，而 IP-CIDR 與 GEOIP 需要可用的位址資訊才能判斷。DOMAIN-SUFFIX 主要依據網域匹配，IP-CIDR 則依位址範圍判斷。請求是否帶有網域、是否已完成解析，以及設定中的解析選項與快取狀態，都會影響排查時可查看的資訊，因此不能只根據網頁是否開啟來推斷匹配到哪條規則。

no-resolve 的適用範圍：IP-CIDR,192.168.1.0/24,DIRECT,no-resolve 不會僅為匹配這條規則而主動解析網域，但這不代表全域停用 DNS，也不保證其他規則不會觸發解析。
GEOIP 的適用範圍：地區結果取決於目標 IP 與資料庫。使用相同語言的兩個網站可能得到不同的地區結果，同一網域的不同位址也可能歸屬不同地區。
IPv6 的適用範圍：IP-CIDR 範例是 IPv4 網段規則，不代表已涵蓋 IPv6。若實際連線使用 IPv6，請另外檢查相應的位址規則與設定支援情況。
快取的影響：瀏覽器快取與現有連線可能讓請求沒有依預期重新發出。修改規則後，請建立新的測試請求；必要時重新連線再觀察。

建議依序確認模式與檔案、匹配到的規則，最後再檢查解析位址與服務連線狀態。如果實際記錄已顯示預期策略，但目標仍無法使用，問題可能出在 DNS、遠端服務、TLS 或目前的網路路徑；此時繼續調整 FINAL 的位置通常無法解決連線問題。

常見問題：規則未生效與更新後被覆蓋

新增規則後，為什麼流量還是全走代理？

先開啟 Home → Global Routing，確認目前選取的是 Config，而不是 Proxy；再到 Config 核對選取的檔案。如果這兩項都正確，請檢查目標是否先匹配上方的 DOMAIN-SUFFIX 或其他廣泛規則，將明確的例外移到這些規則之前，再儲存並發出新的請求。

FINAL 後面的規則還會生效嗎？

就本文討論的一般規則清單而言，不應依賴 FINAL 後面的規則。請將所有匹配條件移到 FINAL 之前，並只保留一條明確的最終策略。檢查重複的 FINAL 時，應搜尋整個規則區段，而不只是檢查檔案底部幾行。

更新訂閱後，自訂規則為什麼不見了？

先確認更新的是哪個項目：Home 中的 Subscribe 通常會更新伺服器資訊，遠端 Config 更新則可能替換設定內容。前往 Config 檢查目前檔案是否已更新或切換；若要穩定保留本機修改，請先儲存獨立副本，並在每次更新後比較規則區段。

網站首頁能開，卻無法登入，需要修改 FINAL 嗎？

先查看登入時新出現的網域與實際使用的策略。登入可能使用獨立網域，也可能被 REJECT 或分配到不同出口。只為已確認相關的網域新增必要例外，並將其放在廣泛規則之前；不要直接把整組規則全部改成 DIRECT 或 PROXY。

規則維護的完成標準是結果可解釋、修改可還原：每條例外都對應明確目標，每次驗證都能指出匹配位置，FINAL 的處理方向也符合預期。若仍無法解釋結果，請還原備份並逐條新增規則，不要同時疊加多組來源不同的設定片段。更多介面入口請參閱選項手冊。