Shadowrocket 設定指南 規則與比對順序

設定檔結構：先區分資料與規則

Shadowrocket 中的伺服器資訊與設定檔各有不同用途。伺服器資訊說明要連到哪裡、使用哪種協定，以及如何驗證身分；設定檔則描述如何處理請求、哪些目標直接連線，以及哪些目標交由代理策略處理。匯入訂閱後看得到伺服器，不代表已選取預期的規則檔。反過來說，儲存了一份規則完整的檔案，也不代表其中引用的代理出口已具備可用參數。排查問題時，應分別確認這兩部分。

Config 中的檔案與實際生效檔案

進入 Config 後，先確認目前使用的檔案，再檢查準備編輯的檔案。清單中有多份設定時，檔名只能用來辨識，無法證明內容相同。修改前先保留副本，並記下目前的 Global Routing 模式與所選伺服器；如此一來，即使修改後無法正常連線，也能切回原檔比對。遠端設定檔還要確認更新方式，以免本機編輯內容隨後被來源檔覆蓋。

設定檔通常採用分節結構，以方括號括住節名，並在各節逐行填入設定或規則。General 集中放置一般選項，Rule 用來設定請求分流，Host 用來設定靜態主機對應，URL Rewrite 則處理符合條件的 URL。各節用途不同，不能因為都寫在同一個檔案中，就把它們視為一張從頭執行到尾的規則清單。尤其不要將 Host 行直接貼到 Rule 節。

[General]
bypass-system = true
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY

閱讀片段時保留上下文

上方是用於參考的最小範例：General 中兩行以等號指定值，Rule 中各欄位以英文逗號分隔。此範例僅展示一般選項、網域規則、私有位址規則與兜底規則之間的關係，不能取代你的伺服器資訊。PROXY 表示交由代理策略處理，最終出口仍取決於目前的設定與所選伺服器。範例中的 example.com 是保留用的示例網域；替換時應填入實際要處理的目標，而非服務商的伺服器位址。

閱讀單行規則時，先看第一個欄位的規則類型，再看比對對象，最後確認策略與選用參數。例如 IP-CIDR 行比 DOMAIN-SUFFIX 行多了 no-resolve，表示與觸發網域解析有關，不是策略名稱。FINAL 的結構則不同，不包含比對對象欄位。複製時應保留英文標點與欄位順序，避免輸入法將逗號轉成中文逗號，或在節名中加入多餘字元。

註解應獨立成行，說明為何需要某個例外，而非只是重述規則內容。對於從其他地方取得的片段，先判斷它屬於哪個節、需要哪些前置條件，再決定插入位置。不要假設所有節名相似的設定檔都能直接共用；設定項目、選用參數與功能支援情況，請以 Shadowrocket 目前 App 內的說明為準。若有無法辨識的項目，先針對單行進行測試。

本機維護與訂閱更新的界線

Subscribe 主要用於更新伺服器項目；Config 檔案更新則可能變更規則、DNS 或其他一般行為。即使兩者來自同一家服務商，更新範圍也不一定相同。維護前先確認正在更新哪一類內容，再觀察更新後所選伺服器與規則檔是否有變化。若一概把連線異常歸因於訂閱失效，容易忽略實際原因可能是切換了檔案，或本機例外規則遭到取代。

儲存設定後，應回到使用介面確認生效狀態，而不只是確認編輯器已關閉。有些選項只影響新連線，既有連線仍可能沿用先前建立的通道。進行比對測試時，應先關閉舊請求，再重新發出；若需要重新建立連線，請先儲存進行中的工作。完整操作順序請參閱使用說明；本頁後續章節著重說明各項設定的判斷依據。

網域規則：精確比對、後綴與關鍵字

網域規則適合表達「這項服務應使用哪種策略」，通常也比追蹤不斷變動的服務位址更直觀。選擇類型時，先確認要涵蓋單一完整主機名稱、一個網域及其子網域，還是任何包含特定字串的網域。這三種規則的涵蓋範圍依序擴大，不要只因為寫法較短就選擇範圍最大的類型。範圍越廣，越需要確認是否會比對到原本無關的請求。

DOMAIN：完整網域精確比對

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

DOMAIN 用於比對完整網域。第一行只指定 api.example.com 的處理方式，不會自動涵蓋 example.com，也不會自動涵蓋更深層的子網域。適合用於單一介面，或作為大範圍規則前的特定例外。填寫時只輸入主機名稱，不要加上 https://、連接埠、路徑或查詢參數；這些 URL 組成部分不是 DOMAIN 的比對欄位，混在一起會改變原本要指定的對象。

精確規則便於檢查，因為每一項都能對應到一個特定服務。缺點是頁面若另外請求其他網域，就需要再確認它們的策略。不要因為主要網域已命中，就認定登入、圖片、驗證與介面請求也會使用相同出口。排查時應從失敗的請求記錄取得實際主機名稱，再決定是否補上規則；只從網址外觀推測依賴網域，容易漏掉真正失敗的位置。

DOMAIN-SUFFIX：涵蓋網域後綴

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

DOMAIN-SUFFIX,example.com,DIRECT 用於涵蓋 example.com 及其子網域。它依據網域後綴關係判斷，不代表任意包含該字串的網域都會命中；名稱中帶有 example.com 字樣的其他網域，不一定屬於同一範圍。上例先將 api.example.com 指定為 PROXY，再讓該網域下的其他請求使用 DIRECT。先列出精確例外，再列概括規則，便於理解例外與預設行為。

設定後綴時，通常只填 example.com，不要原樣貼上瀏覽器中的完整 URL，也不要將網頁路徑當成網域的一部分。不要因其他語法使用萬用字元，就直接套用 *.example.com。若只需要涵蓋單一主機名稱，優先使用 DOMAIN；確實需要涵蓋整組子網域時，再使用 DOMAIN-SUFFIX。涵蓋範圍應由實際需求決定，而非規則數量。

DOMAIN-KEYWORD：涵蓋範圍較廣的字串比對

[Rule]
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT

DOMAIN-KEYWORD 會檢查網域是否包含指定字串。它不會判斷某段文字是品牌、組織名稱或網域邊界，因此 example 可能出現在多個互不相關的網域中。關鍵字規則適合已清楚掌握涵蓋範圍的情境，也可用於暫時診斷，但不能取代目標網域盤點。短字串、常見詞或業務涵義廣泛的詞彙，尤其容易造成意外命中。

若把關鍵字規則放在精確規則之前，後面的精確規則便沒有機會處理這些請求。即使精確規則「看起來更具體」，也不會因此自動取得較高優先順序。測試時應挑選三類目標：確實要涵蓋的網域、不應涵蓋但含有相同字串的網域，以及完全無關的網域。只有涵蓋與排除都符合預期，才能確認這條規則的範圍適合目前設定。

規則比對對象不是伺服器名稱

網域規則的比對對象是請求目標，不是 Home 中顯示的伺服器備註。修改伺服器名稱不會改變 DOMAIN-SUFFIX 的比對對象；反過來，修改目標網域規則也不會修正伺服器驗證參數。若同一目標在 Proxy 模式下可連線，在 Config 模式下卻失敗，應先比較命中策略與出口，而不是立刻重新填寫 Add Server。兩個層面的變更應分開驗證。

檢查現有網域規則時，可依「精確例外、明確後綴、必要關鍵字」的順序整理，並為每組記錄用途。刪除重複項目前，先比較策略：相同網域搭配不同策略，並不能任意合併。若要封鎖目標，可將策略改為 REJECT，但比對範圍的判斷方式不變；詳細說明請參閱REJECT 規則與封鎖原理。

連線策略與 Global Routing 三種模式

規則告訴客戶端「哪些請求屬於這一類」，策略則告訴客戶端「這類請求要如何處理」。PROXY、DIRECT、REJECT 是規則中的策略關鍵字；Global Routing 下的 Config、Proxy、Direct 則是整體運作模式。兩組名稱彼此相關，但屬於不同層級。排查前必須同時記錄目前模式與命中策略，否則容易把模式變更造成的結果，誤認為某條規則已修復問題。

PROXY、DIRECT 與 REJECT

PROXY 表示將符合條件的請求交由代理策略處理，最終能否建立連線，仍取決於出口選擇、協定參數、驗證資訊與目前網路。它不保證所有目標都能存取，也不會自動建立伺服器。DIRECT 表示直接連線至目標，連線仍會經過裝置目前使用的網路。REJECT 表示拒絕符合條件的請求，客戶端可能以相應的失敗結果結束連線；它不會把請求改送到其他伺服器。

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

三條範例分別表示代理、直接連線與拒絕處理，網域僅作為教學對象。若 api.example.com 命中 PROXY 後失敗，下一步應檢查出口，而不是假設客戶端會退回 DIRECT。若 blocked.example.com 命中 REJECT，連線失敗正是策略結果，不應再把它當成伺服器失效的證據。測試前先明確定義成功標準：允許存取、透過指定出口連線，或依預期拒絕。

比較 Config、Proxy、Direct 的用途

此處的三種模式是用來建立排查思路，並不代表系統中的每一類流量一定都以相同方式處理。系統流量、設定中的繞過項目與個別功能仍可能形成界線。比對測試應使用同一個目標與新建立的請求，維持網路環境一致，並查看實際記錄。只憑狀態列圖示或某個頁面能開啟，無法確認所有請求使用了哪種路徑。

若 Proxy 可用但 Config 不可用，應優先確認目標是否被 DIRECT、REJECT 或其他較前面的規則處理，再檢查目前的 Config 檔案是否正確。若 Config 與 Proxy 都失敗，可接著確認伺服器位址、連接埠、協定與驗證資訊，並以其他已知可用的目標區分出口整體異常或單一目標異常。Direct 可用只代表目前網路有一條可行路徑，無法證明代理參數一定正確。

所選伺服器與規則策略的關係

Home 中所選的伺服器、設定中存在的策略群組，以及規則引用的策略名稱，必須放在同一個脈絡下理解。簡單設定可以使用 PROXY，交由目前的代理策略處理；較複雜的設定若引用自訂策略名稱，就必須確認該名稱確實存在且指向有效成員。不要把他人檔案中的自訂名稱當成通用關鍵字直接複製，也不要以為修改伺服器備註後，所有引用都會自動維持有效。

協定參數決定代理連線本身的建立方式，與規則策略彼此相關但各自獨立。以 Trojan 為例，位址、連接埠、密碼與 TLS 相關參數應依據既有伺服器資訊填寫；將規則從 DIRECT 改成 PROXY，無法修正錯誤的驗證參數。欄位填寫範圍請參閱Trojan 參數說明；排查時仍應分開檢查規則與伺服器。

REJECT 也無法滿足所有內容過濾需求。同一個網域可能同時承載必要功能與希望拒絕的請求，拒絕整個網域可能影響登入、載入或同步。對加密流量而言，網域層級規則通常無法據此區分同一主機下的不同網頁路徑。若需要更細緻的控制，應先確認目標資訊的可見性與功能界線，而不是不斷新增涵蓋範圍更廣的關鍵字規則。

完成比對測試後，應切回原本預計使用的模式並再測試一次。暫時使用 Proxy 確認連線後忘記切回 Config，是「規則看起來沒有生效」的常見原因；暫時切到 Direct 後忘記復原，也會造成類似誤判。將目前模式、伺服器與檔案記錄在同一筆測試紀錄中，通常比保留大量缺乏脈絡的成功截圖，更有助於後續維護。

Host 與 URL Rewrite：位址對應與請求處理

Host、URL Rewrite 與 Rule 經常出現在同一個設定檔中，但不能用同一套方式理解。Host 為指定主機名稱設定靜態位址對應，URL Rewrite 依據可辨識 URL 的比對條件執行相應處理，Rule 則選擇連線策略。三者分別涉及「位址來源」、「請求處理方式」與「連線路徑」。若一個問題牽涉多個層面，應分開驗證各層是否符合預期。

Host：固定解析結果不等於指定出口

[Host]
service.example.com = 192.0.2.10

此處將 service.example.com 對應到示例位址 192.0.2.10。該位址屬於文件專用示例位址範圍，並非可供連線的服務。Host 行使用等號，不採用 Rule 的逗號結構，也不能直接在後面加上 PROXY 來指定策略。若同一目標還需要特定連線方式，應另外在 Rule 中設定規則，並透過實際連線記錄確認目標位址與策略都符合預期。

Host 適合用於目標位址明確且能持續維護的情境，不適合任意固定經常變動的公用服務位址。網域背後可能有跨地區調度、故障切換或位址輪替；固定單一位址會略過這些變化，也可能在一段時間後失效。新增對應時，應記錄用途、預期有效條件與移除方式，而不是把某次解析得到的位址直接當成長期修復方案。

HTTPS 請求中的網域也會參與憑證驗證與服務選擇。即使對應位址能建立 TCP 連線，目標服務仍可能因憑證、SNI 或虛擬主機設定而拒絕請求。Host 對應不會讓任意位址自動取得該網域的有效憑證，也不會變更伺服器驗證參數。遇到憑證錯誤時，應檢查目標服務設定，不能以關閉驗證取代確認位址是否正確。

URL Rewrite：先確認比對範圍

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302

上例示範如何針對明文 HTTP 的特定路徑執行重新導向：正規表示式比對舊位址，目標 URL 指向新位址，302 表示暫時重新導向。這不是網域分流規則，不能放在 Rule 節中。將句點寫成反斜線加句點，是為了表示網域分隔點本身；開頭與結尾的錨點則用來限制範圍，避免更長路徑或額外字元也符合範例條件。

URL 中的查詢參數也會影響比對結果。上述結尾的美元符號表示帶有額外查詢字串的位址不在此範例的精確範圍內；是否允許查詢字串，應依實際需求重新設計表示式。不要只為了「讓所有項目都命中」就任意刪除界線或加入寬鬆的萬用比對。修改前先列出應命中與不應命中的範例，再逐一驗證，有助於找出路徑、參數與跳脫字元之間的差異。

HTTPS 可見性與循環風險

網域可以用來分流，不代表加密請求的完整路徑與請求標頭自然可見。對 HTTPS 而言，路徑位於加密內容中，不能只靠網域規則推定 URL Rewrite 一定能處理。若要進一步處理加密內容，必須另外了解憑證信任、適用網域與隱私影響；本頁選用 HTTP 作為範例，就是為了不把這些額外前提隱藏在看似簡單的重寫片段中。

重寫規則也可能形成循環：舊位址指向新位址，新位址又被另一條規則改回舊位址，瀏覽器便會不斷重試，或顯示重新導向次數過多。也可能因目標位址仍符合原比對表示式，導致同一條規則反覆作用。測試時應觀察完整跳轉鏈，而不只看最後頁面是否出現；若無法解釋鏈中的每一步，應先縮小表示式範圍並暫時移除相關重疊規則。

驗證 Host 時，保持原有 Rule 不變，只比較目標位址來源；驗證 URL Rewrite 時，先用明確的 HTTP 測試位址確認重新導向，再檢查目標位址的分流結果。若同時修改三個節，即使最後成功，也很難確認各項設定的相依關係。對正常業務請求，盡量保留原始設定檔副本，避免測試規則影響登入返回、表單提交或其他帶有狀態的請求。

來源更新後，也應重新檢查 Host 與 URL Rewrite，不能只確認 Rule 是否有變化。位址對應可能已過期，服務路徑可能已調整，過去必要的重寫規則也可能與新行為衝突。維護記錄至少應包含目標、用途與撤銷條件；對於無法說明來源與目的的項目，先在副本中停用並測試，再決定是否刪除，比長期保留不明規則更容易控制影響。