Shadowrocket 規則與設定參考

01 / CONFIG STRUCTURE

設定檔結構：先區分伺服器資料與行為規則

Shadowrocket 中的伺服器資料說明「透過哪一台伺服器建立連線」，設定檔則說明「某個請求應如何處理」。兩者相關，但不是同一份資料。使用者已有的訂閱通常用來匯入及更新伺服器項目；包含分流規則的設定檔則需在 Config 中確認並啟用。Home 中已有伺服器，不代表自訂規則已生效。閱讀設定前，先記下目前選取的伺服器、已啟用的設定檔，以及 Global Routing 狀態，後續排查才能維持相同條件。

四個設定區段各自的用途

常見文字設定檔會以方括號標示區段名稱。[General] 放置一般參數，例如 DNS 與系統流量相關設定；[Rule] 放置請求比對條件及對應策略；[Host] 為指定網域設定位址對應；[URL Rewrite] 依運算式處理符合條件的 URL。區段名稱不是裝飾用標題，所在區段會決定每一行的解讀方式。將網域規則貼到 General 下方，即使整行拼寫正確，也不能當成 Rule 中的規則使用。

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

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

[Host]
localhost = 127.0.0.1

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

這段範例用來辨認結構，不是要整份套用的通用設定。General 中兩行分別示範布林參數與 DNS 值；Rule 中三行示範網域、位址範圍與最終策略；Host 中的 localhost 是本機迴路名稱範例；最後一行示範將 HTTP 重新導向至 HTTPS 的寫法。範例網域不代表實際服務，複製前請先確認自己的需求。尤其 FINAL 的值會影響所有未比對的請求，不能只因範例使用 PROXY 就照抄。

標點、段落與易讀性

規則欄位以半形逗號分隔，參數指定值使用半形等號，區段名稱使用半形方括號。中文輸入法輸入的全形逗號、引號或空格，可能導致內容無法如預期解析。每條規則各自占一行，不要把網頁排版造成的換行誤認為新規則。閱讀時可依序拆解為「關鍵字、比對值、策略、選用參數」，但並非所有關鍵字的欄位數都相同；FINAL 就沒有比對值，不能一律補成三欄。

設定區段的排列順序不應解讀為固定的處理流程。檔案中 General 寫在 Rule 上方，不代表每個請求都會先執行所有一般參數，再逐行執行其他區段；Host 與 URL Rewrite 也不是 Rule 後續的規則。真正需要由上而下閱讀的是 Rule 內部的比對順序。將設定結構與規則優先順序分開理解，便能避免藉由移動整個設定區段來「提高規則優先順序」的無效修改。

在 Config 中確認啟用的項目

進入 Config 後，先確認目前選取的檔案，再開啟要閱讀或編輯的項目。修改副本前，請為副本取一個能說明用途的名稱，並保留原檔。儲存編輯內容與啟用檔案是兩個檢查步驟：儲存只表示文字已寫入，不一定表示目前連線已使用這份檔案。返回檔案列表確認選取狀態，再檢查 Global Routing。介面項目位置可能隨應用程式調整；判斷時應依據檔名、選取狀態與實際請求結果，而不是固定的螢幕座標。

如果目前還無法確認應用程式身分，可先依照正版核驗說明確認開發者 Shadow Launch Technology Limited、官方圖示與 App ID 932747118。Shadowrocket 是 Apple 平台的付費用戶端，唯一取得管道為 App Store；系統需求請以 App Store 頁面標示為準。確認基本環境後，再使用本頁的局部片段進行有目的的編輯，比同時更換伺服器與設定更容易判斷問題來源。

03 / DOMAIN MATCHING

網域規則：完整名稱、後綴與關鍵字

分流目標能以穩定網域描述時，請優先考慮網域規則。相較於直接列出位址，網域條件更能表達「某個網站或服務」的意圖，也較不受伺服器位址變動影響。不過網域不是完整網址：通訊協定、路徑、查詢參數與連接埠都不應直接貼到 DOMAIN 的比對值中。例如瀏覽器網址列中的完整 URL，需先取出主機名稱，再判斷只比對該名稱，還是涵蓋其下所有子網域。

DOMAIN：只比對指定名稱

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

第一行比對 api.example.com，第二行比對 account.example.com。DOMAIN 不表示「包含這個字詞」，也不會自動涵蓋其他子網域。如果實際請求是 images.api.example.com，不能因為看起來屬於同一項服務，就認定第一行應該命中。精確規則適合處理少數明確例外：例如大多數請求採用最終策略，只有某個主機名稱需要 DIRECT。使用前請從實際請求中確認完整名稱，不要把頁面顯示的品牌名稱當成網路請求的主機名稱。

DOMAIN-SUFFIX：依網域邊界涵蓋後綴

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

DOMAIN-SUFFIX,example.com 會涵蓋 example.com 及其子網域，例如 www.example.com。它依網域邊界比對後綴，不是任意比較字串結尾，因此 notexample.com 不會正常包含在此後綴範圍內。上例先為 private.example.com 設定精確例外，再加入較廣的後綴規則；若交換兩行，後綴規則會先比對該例外名稱，精確規則便無法發揮預期作用。比起規則數量，更應留意規則的涵蓋關係。

設定後綴時通常不必加星號。將 *.example.com 當作 DOMAIN-SUFFIX 的標準值，會混淆萬用字元運算式與後綴比對兩種機制。也不要為了涵蓋圖片網域，就把範圍擴大到很短的公用後綴。範圍越廣，誤納其他服務的可能性越高。合理的起點是服務實際使用的註冊網域，再依請求記錄補上獨立網域，而不是猜測所有請求都共用相同後綴。

DOMAIN-KEYWORD：範圍較廣，也更容易誤比對

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

DOMAIN-KEYWORD 用於比對網域中包含的關鍵字。這裡的 example 不是完整網域，也沒有 DOMAIN-SUFFIX 的網域邊界，因此可能比對到無關的名稱。只有在確實需要這種較寬鬆的條件，且能檢查影響範圍時才使用。如果目標只是 example.com 及其子網域，後綴規則通常更符合需求。規則較短不代表更精確，關鍵字較少也不代表維護成本較低。

頁面網域不等於所有請求網域

同一頁面可能分別向登入、圖片、介面與靜態資源網域發出請求。首頁能開啟但登入失敗，不一定表示同一條規則時好時壞，也可能是另一組請求採用不同策略。請在操作發生時查看請求記錄，找出實際失敗的名稱，再決定是否新增規則。第三方資源網域可能由多項服務共用，不要只因它出現在某個頁面，就認定所有存取該網域的請求都應採用該頁面的策略。

如果請求記錄中只有 IP，沒有可用來比對的網域資訊，網域規則可能不是正確的檢查入口。此時應繼續檢查位址規則、DNS 與請求產生方式，而不是堆疊更多類似的網域規則。對於國際化網域或格式特殊的名稱，也應以實際記錄中的形式為準。修改後，同時測試目標名稱及一個相近但不應命中的名稱，才能確認規則既涵蓋需要的範圍，也沒有把邊界外的項目一併納入。

05 / POLICY

Global Routing 與 PROXY、DIRECT、REJECT

Global Routing 中的 Config、Proxy、Direct 是模式選擇；Rule 中的 PROXY、DIRECT、REJECT 則是規則的處理策略。兩組詞看起來相近，但屬於不同層次。排查規則是否生效時，先查看 Global Routing；如果目前不是以設定檔處理請求的 Config，就不能只根據修改 Rule 推斷連線結果會跟著改變。尤其暫時切換至 Proxy 或 Direct 測試後，請記得還原原本模式，再驗證自訂分流。

PROXY：採用代理路徑，不代表遠端一定連線成功

規則策略 PROXY 表示透過目前選取的代理建立連線。它不是伺服器位址，也不會補上伺服器所需的驗證資訊與協定參數。若使用者已有的伺服器資料中，位址、連接埠、憑證或相關設定有誤，即使規則正確命中 PROXY，連線仍可能失敗。因此需要分別確認兩件事：請求選用了預期策略，以及該策略使用的連線路徑可正常運作。把這兩項檢查混為一談，統稱為「規則沒生效」，會讓排查方向偏離問題所在。

Home 中選取的伺服器也應一併記錄。使用相同設定檔但更換伺服器，結果可能不同；這不代表 Rule 語法有所改變。使用自訂策略或群組時，應確認其名稱與實際指向，不要在範例中使用未定義的名稱。本文統一使用三種內建策略，避免設定片段依賴額外的群組定義。需要進一步檢查 Trojan 參數時，可參閱Trojan 參數說明，不要透過修改網域規則來修正協定參數。

DIRECT：使用目前網路直接連線

DIRECT 不表示停止 Shadowrocket，也不表示關閉系統中的 VPN 設定。它是在目前處理流程中選擇直接連線至目標。目標是否可連線，仍取決於目前網路、解析結果與服務本身的狀態。區域網路目標使用 DIRECT 通常符合存取需求，但裝置也必須位於相應網路；如果裝置不在同一個網路，或區域網路服務未監聽相應位址，DIRECT 規則本身無法建立原本不存在的網路連線。

REJECT：明確拒絕符合條件的請求

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

第一行拒絕指定名稱，第二行讓其他符合後綴的請求採用 PROXY，最後再處理剩餘流量。REJECT 適合用於明確不希望連線的目標，不應代替尚未想清楚的最終策略。如果被拒絕的名稱同時負責登入、驗證或載入內容，頁面可能出現部分異常。修改前請先了解該名稱的用途，修改後檢查頁面的重要操作，而不只是確認首頁能否顯示。

拒絕策略也不代表保證清除特定頁面內容。網頁內容與網路請求並非一一對應，單一網域也可能承擔多種功能。若為了阻擋某項資源而使用範圍過大的後綴或關鍵字規則，容易連正常請求也一併影響。請從精確目標開始，透過請求記錄確認條件，再考慮是否擴大範圍。若出現新問題，先撤回剛新增的拒絕規則，避免繼續疊加例外而掩蓋原有錯誤。

FINAL：指定未比對請求的處理方式

FINAL 是不含比對值的最終規則，常見寫法為 FINAL,PROXY 或 FINAL,DIRECT。它與全域模式是不同概念：FINAL 仍屬於 Config 下的規則設定，只處理前面都未命中的請求。選擇哪種策略取決於預期的預設行為，不能把某個值當成適用所有人的標準答案。採用 PROXY 時，請確認已有的伺服器可正常使用；採用 DIRECT 時，則須接受未列出的目標會直接連線。

若三種模式下的現象不同，請記錄差異，不要直接下結論。Direct 可用但 Proxy 失敗，可能需要檢查伺服器路徑；Proxy 可用但 Config 失敗，可能需要檢查命中策略及其他設定；三者都失敗，也可能是目標或目前網路有問題。具體判斷仍需搭配連線記錄，不能把切換模式的結果當成排除所有其他原因的唯一證據。

07 / HOST AND URL REWRITE

Host 與 URL Rewrite：分別處理位址對應與網址改寫

Host 處理名稱與位址的對應關係，URL Rewrite 處理符合運算式的網址，兩者都不等於選擇 PROXY 或 DIRECT。遇到存取失敗時，先釐清真正需要改變的是什麼：同一個網域是否應解析至另一個位址、舊網址是否需要轉址至新網址，或只是希望連線改走另一條路徑。前兩種需求才可能與本章有關；第三種應回到 Rule。為了分流而修改 Host，往往會帶來額外的位址與憑證問題。

Host 的最小範例與適用範圍

[Host]
localhost = 127.0.0.1

左側是名稱，右側是位址；localhost 與 127.0.0.1 是本機迴路範例。此處的「本機」是指發出連線的裝置本身，不是路由器，也不是選取的代理伺服器。不要將這個位址用於需要存取遠端伺服器的服務。設定對應只會提供位址資訊，不會讓該位址自動啟動所需服務。若目標連接埠沒有監聽、網路無法連線或服務設定不符，即使名稱已對應至位址，連線仍可能失敗。

為實際網域固定位址前，需確認由誰維護該位址、是否穩定，以及是否允許如此存取。許多服務會依地區與負載動態回傳位址；固定其中一次的結果，可能破壞原有的流量調度。位址對應也可能掩蓋正常 DNS 變化，讓後續排查誤以為解析服務持續回傳舊位址。因此，Host 適合用於明確且可控的對應需求，不適合無限期保存一次性的臨時解析結果。

Host 不會取代 TLS 驗證

HTTPS 連線也涉及請求網域與憑證等條件。將網域對應至某個位址，不代表該位址能提供符合此網域的服務，也不會自動修正憑證名稱不符的問題。遇到 TLS 錯誤時，請確認目標名稱、位址與伺服器設定，不要將停用驗證當成一般修正方式。測試結束後若不再需要此對應，請及時移除，並在重新連線時確認實際位址，避免舊設定影響其他診斷。

URL Rewrite 的三個組成部分

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

這一行依序包含比對運算式、替換目標與重新導向狀態碼。開頭的 ^ 表示從字串起始位置比對；example 後的反斜線用來將句點視為一般字元。如果省略，在正規表示式中句點通常代表任意字元，會擴大比對範圍。末尾的斜線也是條件的一部分。此處使用 302 示範暫時重新導向；這不代表它能修正所有 HTTP 存取問題，也不代表原網址的路徑與查詢參數會自動保留。

範例的替換目標是固定網址，沒有明確保留比對網址的其他部分。如果實際需求包含路徑或查詢參數，應先規劃擷取範圍與替換方式，再用少量可控目標進行測試。不能只因起始網域相同，就把登入回呼、介面請求與一般頁面全部重新導向至網站首頁。範圍過廣的改寫可能破壞請求語意，甚至造成頁面不斷循環轉址。若改寫後的目標又符合另一條改寫條件，也需要檢查兩者的交互影響。

HTTPS 的可見資訊限制

完整 HTTPS 路徑與請求內容通常位於加密連線中，不能假設只新增 URL Rewrite 就能套用至所有加密請求。本章不要求設定 HTTPS 解密，也不以安裝憑證作為規則分流的前提。如果目的只是依網域決定連線去向，請使用網域規則，不必為了取得完整 URL 而增加其他設定。功能是否適用，應依據目前實際可見的請求資訊與應用程式支援的處理條件判斷。

這兩種設定區段的測試都應包含還原步驟。先儲存原值，再新增單一對應或改寫，確認目標行為，最後撤銷並重新測試，觀察現象是否隨變更穩定改變。若撤銷後問題仍在，應考慮快取、既有連線或目標服務變化，而不是繼續疊加項目。若要從完整檔案角度重新檢視四個區段的關係，請參閱設定檔結構解讀；本章原則是將影響範圍限制在能夠說明並驗證的範圍內。

08 / CHANGE AND VERIFY

修改設定與問題排查：建立可重複的驗證流程

規則正確與成功存取是相關但不同的結論。正確的規則可能選到暫時無法使用的路徑；一次成功存取也可能來自快取或既有連線，不一定表示新規則曾參與判斷。可靠的驗證需要固定測試條件、保留原始設定、每次只修改一項因素，並記錄新請求的結果。本章將前述各類規則整理成可還原的流程，適合排查單一網域異常、修改後沒有變化，或設定更新後行為改變等情況。

第一步：記錄基準，不急著修改設定

先記錄目前的網路類型、Global Routing、啟用的檔案與選取的伺服器，再描述問題發生在哪個具體操作。不要只寫「不能用」，而應區分首頁無法開啟、圖片未顯示、登入失敗、介面請求失敗或區域網路裝置無法存取。找出一個可重複觸發的操作，並盡量固定相同目標。若問題本來就間歇發生，應先多次觀察基準狀態，否則修改後偶然成功，很容易被誤判為修正有效。

第二步：儲存副本，縮小修改範圍

在 Config 中保留原始檔案，再編輯副本。先查看相關區段是否已有同類規則、是否有重複條件，以及是否存在提前出現的 FINAL。若是單一網域問題，可先新增一條範圍最窄的 DOMAIN 例外，不要立刻加入範圍較廣的關鍵字。若要調整 DNS，先不要移動 Rule；若要調整 Host，先不要更換伺服器。如此一來，結果變化時才能將其與某一項明確修改連結。

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

這段局部範例用於驗證精確例外：api.example.com 使用 PROXY，其餘符合後綴的名稱使用 DIRECT，其他請求則採用最終策略。逐行理解後，再將自己的目標與預期策略對照。不要直接用範例網域測試實際連線，也不要把整段內容加在既有 FINAL 後面。若現有檔案結構複雜，請先在副本中建立最小重現案例，確認邏輯正確後，再合併回需要長期維護的設定。

第三步：儲存、啟用，再發出新請求

完成編輯後，確認內容已儲存，返回 Config 確認啟用的項目，再將 Global Routing 設為 Config。重新執行目標操作；必要時先中斷連線再重新連線，以減少沿用既有連線對觀察造成的影響。重新連線不代表所有應用程式快取都會清除，因此仍需搭配請求記錄，確認是否產生新的網路請求。測試時，不要直接將「頁面顯示沒有變化」等同於「規則沒有變化」；頁面可能根本沒有重新請求相關資源。

第四步：先確認命中，再檢查連線

若請求採用的策略不符預期，請回到 Rule 頂端檢查涵蓋關係、實際主機名稱、位址類型與 Global Routing。若策略符合預期但連線仍失敗，再檢查選取的伺服器、協定資料、DNS 與目標回應。若只有某個網路發生問題，請比較網路條件；若只有某台伺服器失敗，請比較伺服器連線結果。策略已正確時，不要繼續新增重複規則，因為重複項目無法修正驗證錯誤、位址無法連線或目標服務異常。

第五步：回歸測試相鄰目標，並保留還原記錄

目標恢復正常後，還要檢查相同後綴下的其他請求、一個不在該範圍內的目標，以及可能受影響的區域網路存取。修改最終策略時，回歸測試範圍應更廣，因為所有未命中請求的處理方式都可能改變。記錄應包含修改了哪一行、修改原因、驗證方式及還原方法，不需要保存完整的敏感請求內容。長期設定的價值，在於日後仍能看懂其用途，而不只是修改當天看起來可用。

若仍無法找出問題，可依照已開啟但無法連線的排查順序繼續檢查，或在疑難解答中查找相應分類。若要重新確認匯入與連線流程，請返回快速上手教學；購買與裝置相容性相關資訊，請參閱App Store 正版說明，系統需求與是否支援通用購買均以 App Store 頁面標示為準。不要把重新購買用戶端當成解決規則問題的方法。