Shadowrocket（小火箭）的自訂規則會依序檢查，由第一條匹配的規則決定策略；具體例外應置於較廣泛的規則之前，FINAL 則放在 [Rule] 區段末尾。本文適合 iPhone、iPad、Mac、Windows、Android 與 Linux 使用者了解規則檔案；介面操作請以裝置實際顯示為準。閱讀後即可建立最精簡的規則、分辨 PROXY／DIRECT／REJECT，並依序檢查目前使用的設定、運作模式、匹配順序與對外連線，找出問題所在。
1. 先確認 Config 模式，再檢查規則是否生效
連線開關已開啟，不代表自訂規則正在參與流量分流。以下以 iPhone／iPad 介面為例：先在 Config 確認已選取準備編輯的設定檔，再回到 Home 查看 Global Routing。排查本文的規則時應使用 Config；不要先以 Proxy 或 Direct 測試，再據此判定規則有誤。
本文假設你已經有可用的服務設定檔。規則只會決定請求採用哪種處理方式，無法產生連線憑證，也無法修復無法連線的伺服器。本網站不提供、不販售，也不推薦節點或訂閱。修改前請先備份目前的設定檔，避免一次取代所有設定後無從比對。
| Global Routing | 排查時的意義 | 適合用來確認什麼 |
|---|---|---|
| Config | 依目前設定檔中的規則決定策略 | 規則順序、例外與 FINAL |
| Proxy | 主要使用代理連線，不是用來測試本文逐條規則的模式 | 所選代理連線是否可用 |
| Direct | 主要使用直接連線 | 目前網路是否可直接連線至目的地 |
| Scene | 依已設定的場景邏輯運作 | 場景的選取與切換；不作為本文的測試基準 |
Settings → On Demand 可管理按需連線條件，但不會改變 [Rule] 的規則順序。若網路切換後連線狀態有變化，請先確認 On Demand 設定，再檢查規則；「隧道未連線」和「規則匹配錯誤」是兩種不同問題。
2. 規則語法：類型、匹配值、策略各占一欄
多數規則採用「規則類型,匹配值,策略」的逗號分隔格式，關鍵字與分隔符號都使用英文字符。FINAL 沒有匹配值，直接寫成 FINAL,PROXY 即可。以下是 [Rule] 區段的教學範例，不是包含伺服器、DNS 與其他設定的完整設定檔；請將它加入現有的可用設定檔中核對，不要把它當成可單獨連線的檔案。
[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYexample.com 及其子網域用於說明匹配方式；192.0.2.0/24 是文件專用的示範網段，並非可用的服務位址。上述規則僅用來說明語法與順序，不能證明這些位址提供實際服務。測試時請使用自己有權存取的目標，並依實際用途決定是否需要直接連線或拒絕連線。
- DOMAIN：精確匹配網域。例如
local.example.com，不會因為名稱相近就匹配其他子網域。 - DOMAIN-SUFFIX：匹配指定網域及其子網域。
example.com可匹配api.example.com，但不會匹配任何只包含這段字串的網域。 - IP-CIDR：匹配 IPv4 位址範圍。此處的
/24代表網路前綴長度，不是連接埠號碼。 - GEOIP：依目的 IP 在地理位置資料庫中的歸屬進行匹配。
CN不是根據網頁語言、網域後綴或使用者所在地判斷。 - FINAL：處理未匹配前面規則的請求，不需要再加上網域或 IP 條件。
3. 由上而下匹配：具體例外要排在廣泛範圍之前
規則不會先收集所有匹配項目，再自動挑出「最精確」的一條。針對同一個請求，排在前面的規則會先進行判斷；一旦匹配並決定策略，就不會再由後續的一般規則覆寫結果。因此，即使精確網域比網域後綴更具體，放在後面也不會自動取得較高優先順序。
例外優先：符合預期
- 第一行
DOMAIN,local.example.com,DIRECT- 第二行
DOMAIN-SUFFIX,example.com,PROXY- 最後一行
FINAL,PROXY
local.example.com 會先匹配 DIRECT，其他符合網域後綴的請求則使用 PROXY。
範圍優先：例外規則被遮蔽
- 第一行
DOMAIN-SUFFIX,example.com,PROXY- 第二行
DOMAIN,local.example.com,DIRECT- 最後一行
FINAL,PROXY
local.example.com 已匹配第一行，後面的 DIRECT 不會改變這次判斷。
結論：先列例外，再列範圍，最後放預設策略
新增規則卻「沒有作用」時，先往上檢查是否有舊規則涵蓋相同目標。將必要的精確例外移到該規則之前，再建立新連線測試；這比反覆切換策略更容易找出原因。
- 先明確寫出目標：例如只有
local.example.com直接連線，其餘example.com子網域使用代理。 - 先放精確的 DOMAIN 例外，再放 DOMAIN-SUFFIX 範圍；若有拒絕例外，也應依預期的優先順序排列。
- 確認是否已有更前面的規則涵蓋目標，包括目前設定檔引入的其他規則。
- 儲存後確認仍選取該設定檔；以新連線測試，不要依舊頁面中既有的連線下結論。
4. FINAL 為何必須放在最後？預設策略該怎麼選？
FINAL 沒有額外的匹配條件。如果將 FINAL,PROXY 放在 [Rule] 開頭，前面沒有規則可供篩選，後續的網域或 IP 規則就無法再處理這些請求。同樣地，放在中間也會遮蔽後面的規則。維護時請保留一條明確的 FINAL，並將它放在 [Rule] 區段末尾，而不是任意放在設定檔的其他位置。
[Rule]
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY此範例的意思是：先處理明確的網域需求，再讓 GEOIP 判斷其餘目的 IP，最後將仍未匹配的請求交給 PROXY。FINAL 不是連線失敗時的備用線路，也不是「上一條代理連線失敗就改用直接連線」的容錯開關。規則選擇 PROXY 後，即使末尾有 FINAL,DIRECT，連線失敗也不會因此自動改用直接連線重試。
| 預設策略寫法 | 未匹配請求的處理方式 | 修改前請先確認 |
|---|---|---|
FINAL,PROXY | 交由代理策略處理 | 代理出口可用，且符合未知目標的預期連線路徑 |
FINAL,DIRECT | 直接連線至目的位址 | 未列出的目標可使用目前網路直接連線 |
FINAL,REJECT | 拒絕其他請求 | 已列出所有允許的存取範圍，否則一般服務也可能遭到拒絕 |
不要只為了暫時開啟網頁就頻繁更改預設策略。先決定未列出的目標應採用哪條連線路徑，再補上必要的例外。將 FINAL 作為清楚的預設策略，有助於規則增加後仍能解釋每次分流結果。
5. PROXY、DIRECT、REJECT 不是三種連線協定
這三個關鍵字代表處理策略，不是協定名稱。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 是連線設定涉及的協定概念；使用 PROXY 並不會自動將目前連線改成某種協定。如果目前設定檔使用自訂策略群組，也要檢查群組名稱及實際選取的對外連線；未定義的群組名稱不能當成可用策略。
| 策略 | 用途 | 常見誤解 |
|---|---|---|
| PROXY | 將匹配的請求交由代理連線處理；請確認目前選取的連線或相關策略設定 | 不會自動選取最快的連線，也不保證伺服器可連線 |
| DIRECT | 使用目前網路直接連線至目的位址 | 不代表停止所有 VPN，也不代表其他請求都直接連線 |
| REJECT | 拒絕符合條件的請求 | 不是修復連線，也不是降低優先順序後等待重試 |
例如，DOMAIN,blocked.example.com,REJECT 會拒絕這個精確網域，不會連帶拒絕所有 example.com 子網域。若要拒絕整個網域範圍，應改用 DOMAIN-SUFFIX,example.com,REJECT；這也會擴大影響範圍，務必確認不會誤擋登入、API 或資源網域。
6. IP-CIDR、GEOIP 與 DNS：不要把網域請求直接當成 IP 請求
網域規則通常會依據請求中的網域進行判斷；IP-CIDR 與 GEOIP 則需要目的 IP 資訊。一個網域可能對應多個位址，位址也可能隨網路、解析結果或服務部署而變動。將某次看到的 IP 固定寫成直接連線規則，未必能涵蓋下次存取，也不能據此斷定整個網域都會採用相同策略。
no-resolve 用於避免只為了匹配這條 IP 規則而主動觸發網域解析。它不是「停用 DNS」，也不代表所有網域請求都能透過這條 IP 規則判斷；若沒有可供判斷的目的 IP，就無法靠它強行判定是否符合網段。
- 明確的網域需求：優先使用 DOMAIN 或 DOMAIN-SUFFIX，並放在 GEOIP 之前，避免讓業務需求取決於單次解析結果。
- 明確的位址範圍：使用 IP-CIDR，並檢查 CIDR 前綴。不要將
192.0.2.0/24寫成含連接埠的192.0.2.0:443。 - 地理位置判斷：GEOIP 依據資料庫中的目的 IP 歸屬進行判斷，不保證與伺服器的實際所在地相同；雲端服務或內容傳遞服務尤其需要確認。
- IPv6 目標：IPv4 的 IP-CIDR 範圍不涵蓋 IPv6。排查雙堆疊請求時，請分別確認實際位址類型，不要只憑一條 IPv4 規則判斷所有流量。
HTTPS 常見的目的連接埠是 443，但本文的 DOMAIN-SUFFIX 規則沒有連接埠條件。它依網域匹配，不限於 443。若某個 API 仍然失敗，請分別檢查目標網域、實際位址、目的連接埠與連線錯誤；不要將應用程式伺服器拒絕連線誤判為規則未匹配。
7. 儲存後如何驗證：一次只改一個變數
驗證時應區分「匹配是否正確」與「所選對外連線能否成功連線」。前者要確認請求被分配到哪種策略，後者則要確認連線是否成功。規則匹配 PROXY 但代理連線失敗，仍可能代表規則順序正確；反過來說，頁面可以開啟也不能證明流量一定採用預期策略。
- 保留基準：複製目前可用的設定檔，記錄修改前的 Global Routing、所選連線與要測試的網域。
- 一次只改一項：先新增一條精確的 DOMAIN 規則，或只調整兩行的順序；不要同時更改 DNS、連線協定與 FINAL。
- 確認選取項目：返回 Config 確認正在使用的設定檔，再到 Home 確認 Global Routing 設為 Config，且連線狀態正常。
- 建立新連線：關閉舊頁面後重新發出請求，必要時結束應用程式中既有的連線。已建立的連線可能會繼續使用建立時的路徑。
- 檢查記錄：在裝置可查看的連線記錄或日誌中，確認目標、匹配規則與策略；若記錄未顯示所有欄位，可使用暫時的精確規則進行比對，不要自行猜測結果。
- 還原並歸檔：若修改造成異常，先還原備份；確認有效後再合併至日常設定檔，並記下規則用途。
新增 DIRECT 規則後，為什麼這個網域仍使用 PROXY？
先確認 Global Routing 是否設為 Config，再確認編輯的設定檔就是目前使用的設定檔。從該 DOMAIN 規則往上檢查是否有 DOMAIN-SUFFIX 或其他規則涵蓋它，將必要的例外移到範圍規則之前，儲存後以新連線再次測試。
FINAL 設為 DIRECT，為什麼代理連線失敗後沒有改用直接連線？
FINAL 只處理未匹配前面規則的請求，不會處理已匹配 PROXY 後發生的連線錯誤。先確認該請求匹配的規則，再檢查目前的代理連線；若服務本身需要直接連線，應新增範圍明確的 DIRECT 規則，而不是依賴連線失敗後改用其他路徑。
更新訂閱後，自訂規則會被覆寫嗎？
先分清 Home 中的連線訂閱更新，與 Config 中的遠端設定檔更新。前者主要更新連線資料，後者則可能重新載入規則內容。編輯前請先儲存本機備份；若需要持續更新遠端設定檔，請先確認更新範圍，不要只在遠端內容上進行一次性的修改。
開啟 On Demand 後，為什麼規則仍然沒有作用？
在 Settings → On Demand 確認自動連線條件，再回到 Home 檢查實際連線狀態與 Global Routing。On Demand 負責決定何時連線，不會自動將運作模式視為 Config，也不會調整規則順序。
日常維護可遵循同一原則：具體例外在前、範圍規則居中、FINAL 放在末尾。遇到問題時先檢查目前的設定檔與匹配記錄，再確認對外連線是否可用；不要用不斷新增重複規則的方式掩蓋尚未查明的連線故障。