Shadowrocket 自訂規則與優先順序：由上而下比對、FINAL 兜底與 PROXY/DIRECT/REJECT 策略

規則優先順序的核心：命中第一條後停止

Shadowrocket 的規則清單不是同時計算後再選擇「最精確」的一條，而是依照設定中的書寫順序，由上而下逐條檢查。某條規則一旦符合目前請求，後續規則便不再參與這次判斷。因此，優先順序由位置決定，不會由規則名稱、字元長度或策略類型自動決定。

例如，同一個網域既可能符合精確的 DOMAIN 規則，也可能符合涵蓋整個後綴的 DOMAIN-SUFFIX 規則。如果 DOMAIN-SUFFIX 寫在前面，即使精確 DOMAIN 更具體，也不會生效。設定時應將例外項目放在廣泛規則之前，並將涵蓋範圍最大的兜底項目放到最後。

一次典型的判斷可拆成五個步驟：應用程式發起連線；Shadowrocket 取得目標網域或 IP；從 [Rule] 第一行開始檢查；遇到第一條符合的規則後停止；依照該行末尾的策略處理。若所有具體規則都未命中，便會繼續交由 FINAL 處理。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

存取 api.example.com 時，會先命中第一行並使用 DIRECT；存取 www.example.com 時，第一行不符合，接著命中 DOMAIN-SUFFIX 並使用 PROXY。目標位於私有位址範圍 192.168.0.0/16 時使用 DIRECT；其餘請求經 GEOIP 判斷後，仍未命中的部分交給 FINAL。

DOMAIN、DOMAIN-SUFFIX、IP-CIDR 與 GEOIP 如何排序

規則排序應從「範圍窄、意圖明確」逐步過渡到「範圍廣、涵蓋面大」。DOMAIN 只匹配一個完整網域，適合設定個別例外；DOMAIN-SUFFIX 會涵蓋指定網域及其子網域；IP-CIDR 依位址範圍匹配；GEOIP 則根據目標 IP 的地理資料庫分類。FINAL 不檢查具體目標，而是接收前面所有未命中的請求。

建議採用的排列層級

1. 本地與保留位址：先處理區域網路位址，以及明確需要 DIRECT 的目標，避免內部裝置的請求進入其他策略。
2. 精確網域：使用 DOMAIN 表示單一主機的特殊處理方式，例如讓某個 API 網域優先於後面的後綴規則。
3. 網域後綴：使用 DOMAIN-SUFFIX 處理某個主網域及其所有子網域。
4. 位址範圍：使用 IP-CIDR 匹配明確的 IPv4 網段。前綴長度越大，涵蓋範圍通常越窄。
5. 地理分類：將 GEOIP 放在具體網域與位址規則之後，避免廣泛分類過早攔截例外請求。
6. 最終兜底：將 FINAL 放在最後，明確指定所有剩餘流量的處理方式。

DOMAIN-SUFFIX 的值只填寫網域本身，不要附帶 https://、路徑或查詢參數。規則匹配的是主機名稱，而不是完整網頁網址。若要處理 cdn.example.com，可寫成 DOMAIN,cdn.example.com,DIRECT；若要涵蓋 example.com 及其各級子網域，則寫成 DOMAIN-SUFFIX,example.com,PROXY。

IP-CIDR 的前綴長度必須與目標網段相符。以 192.168.0.0/16 為例，它涵蓋從 192.168.0.0 到 192.168.255.255 的位址。若誤寫成 /24，涵蓋範圍會縮小為單一末端網段，其他同類區域網路位址便不會命中。

PROXY、DIRECT 與 REJECT 分別會改變什麼

規則末尾的策略決定請求命中後如何處理。PROXY 表示交由目前設定指定的代理策略處理；DIRECT 表示直接連線至目標；REJECT 表示拒絕該請求。三者是處理動作，不是規則關鍵字。前面的 DOMAIN-SUFFIX、GEOIP、IP-CIDR 等負責判斷「匹配誰」，末尾策略則決定「如何處理」。

PROXY 不代表任意請求都一定成功，它只是將請求交給目前選取的代理策略繼續處理。最終結果仍取決於使用者現有的設定、對應協定參數與網路狀態。Shadowrocket 支援的設定可能包含 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 或 WireGuard 等協定，但規則順序與具體協定彼此獨立：更換協定不會改變 [Rule] 由上而下的匹配方式。

DIRECT 也不代表「忽略 Shadowrocket」。請求仍會先進入規則判斷，只是在命中後選擇直接連線。因此，遇到區域網路裝置無法存取時，應檢查私有位址規則是否位於 FINAL 之前，同時確認 Global Routing 沒有停留在 Proxy。

REJECT 應只用於邊界明確的目標。若將 DOMAIN-SUFFIX,example.com,REJECT 寫在前面，該主網域及所有子網域都會被拒絕，即使後面另有 DOMAIN,api.example.com,DIRECT 也不會生效。正確做法是先寫入允許的例外，再寫入涵蓋範圍較大的拒絕規則。

FINAL 為什麼必須放在規則末尾

FINAL 是未匹配請求的統一出口。它不限制網域、IP 或位址範圍，因此放在中間時，會接住之前尚未命中的所有請求，後續規則便完全失去執行機會。即使設定允許繼續書寫其他行，位於 FINAL 後面的行也無法改變已完成的首條匹配結果。

# 建議順序
DOMAIN,internal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

# 錯誤順序
FINAL,PROXY
DOMAIN,internal.example.com,DIRECT

第一組順序會先檢查精確網域、後綴與 GEOIP，最後才使用 PROXY 處理剩餘請求。第二組在第一行便讓所有請求命中 FINAL，因此第二行永遠沒有機會生效。出現「新增規則完全沒有反應」時，首先檢查它是否寫在 FINAL 後面。

FINAL 的策略應由設定目標決定，而不是機械式固定為某個值。若設定採用「列出直連例外，其餘走代理」的結構，可使用 FINAL,PROXY；若設定採用「只列出需要代理的目標，其餘直連」的結構，則可使用 FINAL,DIRECT。兩種結構都成立，但前面的規則必須與兜底方向一致。

修改後依固定步驟驗證

1. 在 Config 中開啟目前使用的設定，確認修改發生在實際啟用的設定上，而不是另一份同名或備用設定。
2. 檢查 [Rule] 中是否只有一條負責最終兜底的 FINAL，並確認它位於規則清單末尾。
3. 返回 Home，將 Global Routing 設為 Config。若處於 Proxy 或 Direct，自訂規則的預期分流結果便無法在 Config 狀態下驗證。
4. 分別測試一個應命中 DIRECT 的目標，以及一個應命中 PROXY 的目標，不要只用單一網站判斷全部規則。
5. 若結果與預期不符，請從規則頂部開始尋找第一條可能命中的 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 或 GEOIP，而不是只檢查剛新增的那一行。

設定更新、On Demand 與規則未生效的常見原因

使用者已有自己的服務商與訂閱時，設定更新可能會重新寫入遠端提供的規則內容。若自訂規則直接修改在會被更新覆蓋的設定中，重新整理後可能恢復為遠端內容。修改前應分清目前設定是手動維護，還是隨訂閱更新，並在更新後重新檢查 [Rule] 順序與 FINAL 位置。

On Demand 與規則優先順序處理的是不同階段。入口為 Settings → On Demand，它會根據已設定的網路條件決定何時建立連線；連線建立後，請求如何分流仍取決於 Global Routing 與目前的設定規則。On Demand 尚未建立連線時，僅調整 [Rule] 無法取代對連線條件的檢查。

另一個常見原因是規則內容包含 URL。DOMAIN 與 DOMAIN-SUFFIX 只接受網域部分；將協定標頭、連接埠或路徑一併寫入，會導致匹配對象不正確。例如要匹配存取 https://api.example.com:443/v1/status 時，DOMAIN 值應寫成 api.example.com，連接埠 443 與路徑 /v1/status 不屬於該網域規則的值。

規則名稱與策略名稱也應使用英文原文，並以英文逗號分隔欄位。全形逗號、欄位缺失、額外空格造成的不可見差異，都可能讓一行設定無法依預期解析。複製規則後，可先保留三段式結構，再逐項核對關鍵字、匹配值與策略。

儲存前的規則檢查清單

一份便於維護的設定通常具有清晰的分層：區域網路與精確例外在前，網域後綴和位址範圍居中，GEOIP 靠後，FINAL 收尾。同一目標不應在多個位置反覆出現互相衝突的策略；若確實需要例外，應以「具體規則在前、通用規則在後」來表達，而不是期待後面的規則覆蓋前面。

• 目前修改的是正在使用的 Config，而不是另一份未啟用的設定。
• Home → Global Routing 已設為 Config，測試過程沒有停留在 Proxy 或 Direct。
• DOMAIN 與 DOMAIN-SUFFIX 的值不含協定標頭、連接埠、路徑及查詢參數。
• 規則欄位使用英文逗號分隔，關鍵字與策略保留英文原文。
• 精確 DOMAIN 位於可能覆蓋它的 DOMAIN-SUFFIX 之前。
• 確認 IP-CIDR 的前綴長度，避免混淆 /16 與 /24 的涵蓋範圍。
• GEOIP 位於需要優先處理的網域與位址規則之後。
• FINAL 只負責兜底，並位於 [Rule] 最後。
• 訂閱更新後，重新核對自訂內容是否仍然存在。
• Settings → On Demand 只控制連線時機，不取代 Global Routing 與規則檢查。

完成檢查後，應使用至少兩個方向相反的樣本驗證：一個預期 DIRECT，另一個預期 PROXY；若設定包含 REJECT，再增加一個明確的拒絕目標。逐一從規則頂部推演每個樣本的首條命中項，比只觀察連線開關或單次載入速度，更能定位問題。

Shadowrocket 是 Apple 平台的閉源商業應用程式，iPhone 與 iPad 為主要使用裝置；Mac、Apple TV 與 Apple Vision 的相容性及系統要求以 App Store 頁面標示為準。唯一取得入口為 App Store，開發者應顯示為 Shadow Launch Technology Limited，應用程式 ID 為 932747118，購買方式為一次買斷。用戶端買斷與線路服務是不同事項，設定與訂閱由使用者自行準備及管理。