Shadowrocket
規則與設定參考

先找出目前使用的檔案，再確認各區段負責的工作。

在 Config 確認目前使用的檔案

設定檔不是伺服器清單的另一種寫法。伺服器資訊描述連線至遠端所需的位址、連接埠、協定及驗證參數；設定檔則規定如何分類請求、選擇策略，以及部分解析與處理方式。開啟 Config 後，應先確認目前啟用的是哪個檔案，而不是看到檔案已匯入就認定它正在生效。檔案存在、內容已儲存、檔案已選取，以及 Global Routing 設為 Config，是四種需要分別確認的狀態。如果剛修改的規則沒有影響連線，先檢查這四項，通常比繼續新增同類規則更有效。

開始編輯前，請先備份目前可用的檔案，並記錄正在使用的伺服器與 Global Routing 狀態。初次查閱時，建議先看檔案中的區段標題，再閱讀各區段的欄位，不要逐行猜測整份設定的用途。方括號標題用來區分設定區段，後續內容則依所屬區段解讀；相同文字出現在不同區段時，意義不一定相同。範例中的網域僅用來說明語法，不代表可直接使用的連線服務。

四個常見區段的功能

General 中的設定會影響基本處理環境，不應在其中加入一般分流規則。Rule 中的每一行則描述一個比對條件及其結果，例如命中網域後選擇 DIRECT。Host 會變更特定主機名稱的解析對應，並不等於替該主機指定代理策略。URL Rewrite 處理可見的請求網址，不能取代 Rule 對一般連線的路由判斷。把這四件事混為一談，就可能產生「網域已對應到位址，為什麼仍走代理」的疑問：位址來源與策略來源原本就是兩項不同的判斷。

[General]
dns-server = system

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

這段最精簡的範例使用系統 DNS，將 example.com 及其子網域指定為 PROXY，將一個區域網路網段指定為 DIRECT，並由 FINAL 處理其他連線。範例不包含可用伺服器，也沒有涵蓋完整的網路需求，目的是清楚呈現區段邊界與規則結構。除非有相應需求，否則不要為了補齊目錄而加入空白的 Host 或 URL Rewrite 區段；精簡檔案更容易看出每次修改造成的影響。

編輯、儲存與匯入並非同一件事

從檔案匯入設定後，先檢查區段是否完整、換行是否保留，以及逗號是否為半形字元。從富文字內容複製的文字可能含有全形標點、不可見空格或被折疊的換行，外觀看似正確，解析結果卻可能不同。儲存後重新開啟編輯內容，確認實際儲存的文字符合預期，再回到 Config 確認已選取正確檔案。如果更新遠端來源的設定，應另外確認本機手動調整是否保留；不要把一次成功儲存視為日後更新都會自動合併的保證。

遇到來源較複雜的檔案時，先建立一份容易理解的基準設定，再逐項加入確實需要的選項。每加入一組內容就測試一次，不必一次複製所有進階欄位。檔名只能協助辨識，不能證明內容適用於目前裝置；同樣地，註解寫著「直連」也不能取代實際的策略名稱。最後應一併比對儲存後的文字、目前模式與連線記錄來確認結果，後續各章也會依此方式判斷。

Global Routing 決定路由模式，策略則決定命中後的處理方式。

Config、Proxy、Direct 的判斷入口

Global Routing 中的 Config、Proxy、Direct 是路由層級的選擇，不是某條規則的同義詞。Config 模式會依目前設定處理連線，是檢查 Rule 區段時首先應確認的入口。Proxy 模式適合暫時檢查代理路徑的連線情況，Direct 模式則適合對照本機網路路徑；但不能因此推定每個系統連線都會以相同方式處理。基本略過設定、系統保留連線及實際網路環境仍可能影響觀察範圍，判斷時應聚焦於正在測試的請求。

例如，某個網域在 Proxy 模式下可以連線，切換回 Config 後卻失敗，只能將調查範圍縮小到設定路徑、解析差異或策略選擇，不能直接認定所有網域規則都有問題。應查看 Config 模式下該連線命中了哪一行，以及策略最後指向何處。反過來說，Direct 模式下可以連線、Proxy 模式下卻失敗，也應檢查既有伺服器的連線參數、遠端可連通性與協定要求，而不是立刻將該網域加入更多 DIRECT 清單。

PROXY、DIRECT、REJECT 的執行意義

規則行中的 PROXY 表示採用代理路徑，但本身不包含伺服器位址。實際使用哪個連線項目，還須搭配目前選取的伺服器及設定中的策略參照。DIRECT 表示直接連線至目標，不經過該規則指定的代理路徑；但這不代表不會進行 DNS 查詢，也不保證目標一定能連線。REJECT 用來拒絕符合條件的連線，適合用於明確需要阻擋的目標。成功阻擋規則與頁面能否正常使用是兩回事；拒絕某些頁面所需的資源後，相關功能也可能無法運作。

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

這三個網域分別示範三種策略，不適合直接套用為完整的實際設定。將 DIRECT 改成 PROXY，只會改變連線路徑，不會自動修正目標位址、憑證或驗證參數。將失敗的連線改為 REJECT，也不是修復問題，而是主動終止連線。維護設定時，註解應說明「為何需要這項策略」，而不是只重述英文詞的意思；如此一來，網路環境改變後才知道哪些規則需要重新評估。

策略名稱、選取項目與失敗後備

如果檔案使用自訂策略名稱，必須確認目前設定中有對應定義，大小寫與空格也應和實際內容一致。不要只複製參照行，卻漏掉被參照的策略。對於包含選取或探測邏輯的策略，規則命中只完成第一層分類，最終連線仍可能受所選項目的狀態影響。因此，即使記錄中出現預期的策略名稱，仍須繼續檢查實際使用的連線項目。規則正確與伺服器無法使用，可能同時發生，應分別處理。

也要區分「未命中前面的規則」與「命中後連線失敗」。前者會由後續規則或 FINAL 繼續處理；後者通常不會因為連線失敗，就讓同一請求回到 Rule 區段尋找下一條能連線的規則。是否會重試或在策略內切換，取決於相關設定與功能，不能把 Rule 的排列順序當成備用伺服器清單。這個差異能解釋許多「第二條明明可用，為什麼沒有繼續嘗試」的疑問。

調整模式或策略後，應重新建立測試連線，並記錄調整前後的模式、命中行與連線項目。不要只根據連線開關的外觀判斷成功，也不要一次變更模式、伺服器及 DNS 三個變數。維持其他條件不變，才能判斷變化的原因。若目的是學習規則，建議先在 Config 模式下以少量明確規則建立可重複的測試結果，再逐步擴充至日常設定。

完整網域、網域後綴與字串包含的涵蓋範圍各不相同。

DOMAIN：只比對完整網域

DOMAIN 用來比對完整網域，適合為單一服務入口設定明確例外。規則 DOMAIN,api.example.com,PROXY 的目標是 api.example.com，不應理解為涵蓋 example.com 底下所有主機。網域欄位不應填入協定前綴、路徑或連接埠，也不要直接貼上瀏覽器網址列中的完整 URL。如果需要區分同一主機上的不同路徑，一般 DOMAIN 規則無法提供這種比對粒度；必須先確認需求是網域路由，還是請求網址處理。

精確規則的優點是影響範圍容易控制，也方便在記錄中找到對應項目。為某個 API 新增例外時，先確認實際請求的主機，不要只看頁面網址。一個頁面可能會請求登入網域、靜態資源網域及 API 網域；只修改主頁的規則，其他請求可能仍採用原本的策略。若頁面部分正常、部分失敗，應分別檢查失敗連線的目標，不要把整個頁面視為只有一個網域的一次請求。

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 會先命中第一行，其他屬於該後綴的目標才會套用 DIRECT。

如果將上述兩行順序顛倒，涵蓋範圍較廣的規則會先攔截 api.example.com；即使後面的精確規則寫得更詳細，也不會自動取得較高優先權。檢查設定時，不只要看規則描述什麼，也要查看前面是否有涵蓋範圍更大的規則。後綴規則適合表示同一網域體系的共同策略，但不代表該體系的所有相依服務都在該後綴內；外部資源與重新導向的目標仍可能需要分別判斷。

DOMAIN-KEYWORD：謹慎使用廣泛包含比對

DOMAIN-KEYWORD 會依網域中的關鍵字字串進行比對，適用於確實需要從多個網域體系中找出共同字串的情況。它不會依品牌意義辨識目標，也不會驗證網域歸屬。例如，關鍵字 example 可能會比對到多個包含此字串的主機，涵蓋範圍通常比明確的網域後綴更大。若目標只是 example.com 及其子網域，優先考慮 DOMAIN-SUFFIX；使用範圍較廣的關鍵字前，應先列出可能誤納的目標，再決定是否接受這種涵蓋範圍。

這三種規則沒有天生的「精確類型優先於廣泛類型」順序，仍依照 Rule 區段中的排列順序執行。因此，可先放最小範圍的例外，再放共同後綴，最後才考慮確實需要的關鍵字。這種安排是為了提升可讀性，並非設定解析器強制規定的格式。如果一條關鍵字規則已涵蓋多個後綴，再新增套用相同策略的後綴規則，可能只會增加維護負擔。

無法看到網域時，不要勉強推定原因

如果 App 直接使用 IP 位址連線、使用自身的解析機制，或記錄中沒有網域資訊，就不能假設 DOMAIN 系列規則一定能取得完整主機名稱。此時應先檢查記錄中可見的目標，再決定是否需要 IP 規則。不要因為瀏覽器顯示了網域，就推定所有底層連線都具有相同資訊。網域規則是否參與比對，取決於連線進入處理流程時能取得哪些資訊，而不是使用者在其他介面看見了什麼。

整理網域清單時，建議為每組規則註明用途與例外，並移除已被前面的同策略規則完整涵蓋的重複項目。測試至少包括目標網域、一個子網域，以及一個相似但不應命中的網域。如此既能確認規則涵蓋了需要的連線，也能檢查範圍是否過廣；只測試一個成功目標，無法證明規則範圍正確。

不同規則讀取的資訊各異，先確認連線實際提供了哪些資訊。

IP-CIDR 與 IP-CIDR6 的網段表示法

IP-CIDR 使用網路位址及前綴長度描述 IPv4 位址範圍；IP-CIDR6 則用於 IPv6。前綴長度越大，涵蓋範圍越小；單一 IPv4 位址可用 /32 表示，單一 IPv6 位址則可用 /128 表示。新增網段前，應確認該範圍確實是需要處理的目標。不要只因其中一個位址無法連線，就將整個大型位址區塊改用相同策略。目標若使用共用基礎架構，過大的網段可能影響與原本需求無關的服務。

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

前兩行示範常見的私有 IPv4 範圍，第三行示範 IPv6 唯一本機位址範圍；不能因此認為所有本機網路都已涵蓋。實際區域網路可能使用其他私有網段，也可能採用不同的位址規劃，應依裝置目前使用的網路檢查。IPv6 不會自動沿用 IPv4 規則；設定了 IPv4 網段，不代表相關服務的 IPv6 連線也會採用相同策略。如果相同網域的連線結果不時不同，應另外核對記錄中的位址類型。

no-resolve 可避免額外解析，但不會產生目標位址

IP 規則後面的 no-resolve 用來避免為了比對該規則而主動進行網域解析。它適用於本來就已知目標位址的連線，或希望避免在一組 IP 規則中提前觸發不必要解析的情況。它不代表完全關閉 DNS，也不代表所有網域都會略過後續位址判斷。如果目前連線只有網域名稱，沒有可用的目標位址，這條帶有 no-resolve 的 IP 規則可能無法據此完成比對，最後仍須由其他規則決定策略。

因此，若要為本機網域設定 DIRECT，只新增私有網段加上 no-resolve 未必足夠。如果主機名稱只在本機 DNS 中有效，還應檢查主機如何解析、解析結果是否可見，以及前面的網域規則是否已攔截該請求。不要把 no-resolve 當成通用的效能提升選項。它改變的是比對過程中是否進行額外解析，應依需求控制查詢行為，而不是機械式地加在所有規則後面。

GEOIP 是位址分類，不是業務歸屬判斷

GEOIP,CN,DIRECT 表示依位址資料庫對目標 IP 的分類套用 DIRECT。它不會辨識網站使用的語言、不依網域後綴判斷，也無法證明營運者或內容的存放位置。資料庫、目標實際位址與解析結果都會影響命中。單一網域可能對應多處基礎設施，後續解析結果改變也可能影響位址分類。因此，對於需要穩定策略的特定服務，通常適合先以明確網域規則表達需求，再將 GEOIP 作為較廣泛的後續分類。

排查 GEOIP 時，先記下這次連線實際使用的位址，再檢查前面的網域規則是否已結束比對。即使看到目標位址屬於預期範圍，也不代表 GEOIP 規則一定會執行；反過來說，未命中 GEOIP 也不能立刻歸因於資料庫錯誤，連線也可能根本沒有進入這項判斷流程。不要把地理分類當成精確的安全界線，尤其不可用它取代身分驗證、存取控制或伺服器憑證核對。

USER-AGENT 的可見性範圍

[Rule]
# 僅在請求資訊可供比對時評估此條件
USER-AGENT,ExampleApp*,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

USER-AGENT 會比對請求中可取得的 User-Agent 資訊；範例中的星號表示模式中的萬用字元。它不會依裝置上安裝的 App 名稱辨識程序，也不能保證識別某個 App 的所有連線。加密請求或未攜帶相應欄位的連線，可能沒有可供此規則比對的資訊。排錯時，應區分「App 發出了連線」與「該連線提供了可比對的 User-Agent」，不能只憑 App 名稱就推定規則應該命中。

同時使用多種條件的檔案，可依序檢視「明確的網域例外、確實需要的請求資訊條件、特定網段、範圍較廣的位址分類、FINAL」，但最終順序仍應依實際需求決定。每新增一項條件，都應說明它依賴哪種資訊，以及資訊不足時由哪條規則處理。這類記錄比單純統計規則數量更有助於維護，也能避免誤以為不同規則只是同一條件的重複寫法。

由上而下比對，命中即停止；規則較精確不代表會自動取得較高優先權。

依序推演，不要只看規則名稱判斷

閱讀 Rule 區段的基本方法，是將一個具體請求逐行代入規則，從第一行開始檢查。遇到符合條件的規則，就使用該行指定的策略，不會再由後面的普通規則重新分類。因此，較早出現的廣泛條件可能涵蓋後面許多精確條件。所謂「例外優先」，不是隱藏機制，而是維護者將例外放在共同規則之前所形成的結果。檢視檔案時，應先整理涵蓋關係，再判斷是否需要調整順序。

[Rule]
# 先保留單一主機的例外
DOMAIN,api.example.com,PROXY

# 再處理整個網域體系
DOMAIN-SUFFIX,example.com,DIRECT

# 已知的區域網路目標
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

# 涵蓋範圍較廣的位址分類
GEOIP,CN,DIRECT

# 其餘連線的最終策略
FINAL,PROXY

對 api.example.com 而言，第一行已比對成功，後綴規則不會再改變它的策略。對 static.example.com 而言，第一行不符合，後綴規則會將其導向 DIRECT。對已知的區域網路 IP，前兩條網域條件可能不適用，接著由網段條件處理。只有前面所有條件都未命中的連線，才會使用 FINAL。每一步都是條件比對，不是在多條線路之間逐一測試連線；命中策略後發生的網路錯誤屬於後續執行階段。

FINAL 用來處理剩餘連線

FINAL 不是「最重要的網域規則」，而是負責處理未被前面條件分類的其餘連線。FINAL,PROXY 表示預設採用代理路徑；FINAL,DIRECT 則表示預設直接連線。兩者沒有脫離情境的絕對優劣，應依前面的例外範圍與實際需求選擇。修改 FINAL 的影響通常大於新增精確網域規則，因為它改變的是整個未涵蓋範圍，而非單一目標。

FINAL 應放在規則清單末尾，並避免在其後新增預期要生效的一般規則。如果維護者只在檔案最後追加內容，卻忽略前面已有 FINAL，新規則可能永遠不會執行。合併檔案時尤其要檢查重複的 FINAL：不能直接串接兩份各自完整的 Rule 區段，並期待第二份設定仍照原樣運作。應先確定統一的預設策略，再將兩份檔案中有效的例外重新整理到 FINAL 之前。

重複、衝突與無法命中的規則

同一條件重複出現且策略相同，通常只會增加閱讀負擔；若相同條件指定不同策略，則由較早出現的規則決定。較不易察覺的衝突則來自涵蓋關係，例如前面的 DOMAIN-SUFFIX 涵蓋後面的 DOMAIN，或較大的網段涵蓋較小網段。檢視時不要只搜尋完全相同的文字，也要比較目標範圍是否重疊。如果確實需要小範圍例外，就應將該條件移到前面，並在註解中說明它與後續規則的關係。

如果設定中還參照外部規則集合，也應將參照行視為目前順序中的一個比對入口，而不是完全獨立的另一套優先順序。外部內容改變可能擴大或縮小比對範圍，導致後續本機規則不再收到原本的請求。更新後若出現差異，應同時檢查本機參照位置與外部內容的變化；只確認本機檔案是否修改，可能會漏掉真正改變比對結果的部分。

建立可重複的測試矩陣

調整順序前，至少選取四類測試目標：精確例外、共同後綴、已知的本機位址，以及應由 FINAL 處理的目標。為每個目標記下預期命中的規則與策略，再逐一建立新連線驗證。測試不必記錄大量數據，重點是在相同模式下，對同一目標取得可解釋的結果。若新規則修復了一個目標，卻改變了另一個原本正常的目標，應重新檢查涵蓋關係，而不是繼續在檔案末尾追加修補規則。

最後，請在相鄰的註解中記下規則順序的原因，尤其標記必須放在廣泛規則之前的例外。日後重新排序或合併檔案時，這些說明能避免為了按類型整理得更整齊，反而破壞實際行為。規則清單的目的不是視覺上的分類，而是讓預期請求在正確的位置停止比對，並為未涵蓋的目標明確指定最終處理方式。

解析、路由與請求重寫彼此相關，但不能互相取代。

先區分網域解析與連線路徑

DNS 負責將主機名稱解析為位址，Rule 則負責決定連線採用哪種策略。兩者會相互影響觀察結果，但不是同一個開關。網域可先透過某種解析路徑取得位址，再由規則決定直接連線或使用代理；某些連線方式也可能在不同位置進行解析。排錯時應分別記錄「取得了什麼位址」與「連線採用了什麼策略」，不要看到 PROXY 就推定解析一定在遠端進行，也不要看到 DIRECT 就推定所有解析都使用相同的本機路徑。

[General]
dns-server = system

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

dns-server = system 表示使用系統提供的 DNS 設定，是說明基本行為的簡單起點，並非所有網路環境都適用的固定答案。如果系統 DNS 無法解析某個內部主機，只為該主機設定 DIRECT 並不會憑空產生正確位址。應先確認該名稱是否需要特定網路才能解析，再檢查裝置是否處於相應環境。反過來說，網域能正常解析，也不代表目標連接埠可連線；解析成功只完成連線前的一部分工作。

Host 對應的用途與維護成本

[Host]
# 文件範例位址，不代表可連線的業務主機
lab.example.com = 192.0.2.10

[Rule]
DOMAIN,lab.example.com,DIRECT
FINAL,PROXY

Host 區段可為指定主機名稱設定明確的位址對應。範例中的 192.0.2.10 是文件用途的位址，僅用來呈現欄位結構。上述對應不包含 DIRECT 的意思，實際策略仍由 Rule 說明。使用真實對應時，應確認位址屬於預期目標，並考量憑證、伺服器主機名稱辨識及業務更新。將網域固定對應到舊位址，看似能讓解析結果穩定，卻可能導致業務遷移後的請求持續送往失效位置。

臨時診斷時可利用位址對應排除解析因素，但驗證完成後應決定是否保留，並記錄保留原因。如果目標使用動態位址或負載平衡，長期保留靜態對應可能破壞原有的流量調度。不要只因一次解析結果就複製位址，並將它當成永久正確的業務位址。遇到憑證名稱不符時，也不要隨意關閉驗證來掩蓋問題；應檢查目標位址、主機名稱與伺服器憑證是否原本就相符。

URL Rewrite 處理可見的請求網址

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

這個範例使用正規表示式限定完整網址，並以 302 重新導向至另一個網址。開頭的 ^ 與結尾的 $ 用來限定比對範圍；網域中的句點則以反斜線跳脫，避免被解讀為任意字元。如果請求帶有查詢參數或結尾斜線，就可能不符合這個完整運算式；這不代表重寫失效，而是條件原本就未涵蓋該形式。編寫運算式時，應先列出需要比對的網址形式，再決定是否放寬範圍。

重新導向不等於替原始連線選擇 PROXY 或 DIRECT。瀏覽器收到重新導向後可能會發出新請求，而新請求仍須依自己的目標進入路由判斷。如果重寫後形成循環，應檢查新網址是否再次符合同一條或其他運算式。測試時先使用範圍小、結果容易觀察的規則；不要一開始就對整個網域體系使用廣泛運算式，否則很難找出是哪次跳轉改變了請求。

遵守加密請求的可見性限制

HTTPS 的完整路徑通常不會直接提供給一般網路路由處理。設定中加入 URL Rewrite，不代表所有加密請求都會自動提供完整 URL 供比對；能否處理仍取決於請求的可見性及相關設定。一般網域分流不需要為了讀取路徑而擴大處理範圍。本頁的重寫範例僅用來說明區段語法，不要求為了學習規則而啟用額外的憑證相關功能，也不應將這類設定當成解決所有連線問題的第一步。

維護這些區段時，也要考量快取與既有連線。系統、App 或瀏覽器可能保留解析結果、跳轉結果或連線狀態；修改後應以新請求重新測試，並區分快取現象與設定未生效。如果不同 App 的結果不同，先比較它們實際請求的網域、位址與協定，不要直接歸因於某個區段的優先順序不同。最後仍應依據本次可見記錄解讀本次連線。

先將需求寫成小範圍條件，再逐步合併，並確保可以復原。

先用一句話說明預設行為

編寫設定前，先回答兩個問題：未明確列出的連線應如何處理？哪些目標需要採用不同於預設值的行為？第一個問題對應 FINAL，第二個問題則形成例外清單。如果無法用一句話說明預設行為，通常也很難判斷新增規則是否必要。不要先蒐集大量網域，再回頭猜測整份檔案的用途。規則越多，涵蓋關係就越複雜；內容來自不同檔案，也不代表維護成本會自動降低。

[Rule]
# 預設使用代理，僅將明確指定的目標設為直接連線
DOMAIN,printer.example.com,DIRECT
DOMAIN-SUFFIX,home.example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY

這組範例呈現預設使用代理、明確指定目標直接連線的結構。其中 printer.example.com 與 home.example.com 都是範例名稱，應依實際環境判斷，不能直接視為本機服務。如果需求是預設直連、僅讓部分網域使用代理，則應反向設定少量 PROXY 條件，並將 FINAL 改為 DIRECT。不要直接疊加兩種預設行為不同的設定檔，否則一份檔案中的例外可能在另一份檔案中變成重複或衝突的規則。

例外、共同規則與阻擋目標

[Rule]
# 單一主機的規則應排在共同後綴之前
DOMAIN,api.example.com,PROXY
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

這個組合包含代理例外、拒絕例外與共同後綴策略。兩個精確主機必須放在後綴規則之前，才能保留各自不同的處理方式。REJECT 應用於明確希望停止連線的目標，不宜只因某次連線較慢就加入。如果加入拒絕規則後頁面功能減少，先檢查是否阻擋了必要的 API，而不是繼續修改 DNS。規則正確命中，不代表規則所表達的業務決策一定合適；驗證時必須同時檢查路由結果與功能是否正常。

為本機裝置設定直連時，也不要把所有曾出現的位址都列為永久規則。先確認裝置是否使用固定位址、主機名稱是否穩定，以及存取是否需要位於同一個區域網路。規則只能決定連線路徑，無法讓不在目前網路中的裝置自動變得可連線。如果需求依賴特定本機網段，切換 Wi-Fi 後應重新確認位址規劃，避免將另一個網路中用途不同的相同位址範圍，誤認為原本的裝置環境。

分開管理訂閱資料與規則檔案

透過 Subscribe 匯入的連線資訊與 Config 中的規則設定，負責不同工作。更新既有訂閱後，伺服器名稱、數量或參數可能改變；若設定透過名稱參照連線項目，就要確認這些參照仍然有效。不要認為更新訂閱會自動修正所有本機策略參照，也不要把規則檔案備份當成已完整保存所有連線憑證。遷移時應分別核對連線資訊、目前設定與模式狀態，確認三者可以重新搭配運作。

使用者既有的訂閱網址、驗證參數與私鑰都屬於敏感資訊。向他人說明問題時，應隱藏這些內容，只保留必要的規則條件、策略名稱及錯誤階段。範例檔案也不應包含真實憑證。若要了解 WireGuard 欄位與路由規則的分工，請參閱WireGuard 設定參數說明：協定參數決定如何建立連線，Rule 則決定哪些目標使用該路徑，兩層設定不能互相取代。

合併、更新與復原的操作順序

合併設定時，先備份目前可用的檔案，再列出準備新增的實際需求。檢查新內容是否加入新的 General 設定、Host 覆寫、URL Rewrite 或策略參照，而不只是比較 Rule 行數。接著移除重複的 FINAL，將例外放在相關廣泛規則之前，並確認被參照的名稱確實存在。每次只合併一組相關規則，儲存並啟用後測試具代表性的目標；一旦出現異常，就能明確復原到對應的修改點。

遠端來源的設定更新應視為一次變更檢視，而不只是確認更新動作是否完成。比較規則順序、預設策略與位址覆寫的變化，尤其要留意原本保留在本機的例外是否仍然存在。若需要長期手動維護，應盡量減少用途不明的進階欄位，並為重要規則留下原因。檔案越容易理解，發生問題時就越容易復原；可維護性來自明確的範圍與驗證記錄，而非規則數量。

最後保留一份精簡的基準設定，用來區分網路問題與複雜設定問題。基準設定仍須搭配使用者既有的伺服器，並非獨立的連線服務。日常設定發生異常時，切換至基準設定測試相同目標；若基準設定正常，再逐組還原較複雜的規則。如此取得的證據比反覆匯入整份檔案更清楚，也能避免排查過程中遺失原本有效的設定。

先確認處理流程，再用相同目標交叉比對；不要以單次成功作為結論。

第一層：確認目前狀態並建立新連線

出現「規則沒有生效」時，先記下裝置目前的網路、Global Routing、選取的設定檔及連線項目，再重新發出目標明確的請求。舊連線可能仍沿用建立時的狀態，不能只修改檔案後重新整理一個仍在重用連線的頁面，就直接下結論。連線開關開啟，只表示用戶端進入相應的工作狀態，不代表目標已由預期規則處理。應檢查的是本次請求的實際記錄，而不是按鈕看起來是否位於正確位置。

接著確認測試目標是否單一。瀏覽器網址列中的頁面可能會發出多種資源請求；圖片載入成功不代表 API 連線成功，單一 API 失敗也不代表整個網域體系都無法使用。選定一個可以明確辨識的失敗主機，記下網域或 IP、命中規則、策略及錯誤情況。如果目前介面沒有提供某項資訊，應明確記為未知，不要根據頁面現象推測不存在的比對記錄。

第二層：區分未命中、策略錯誤與執行失敗

如果命中 FINAL，先從第一行開始推演同一個目標，檢查是否將完整 URL 填入 DOMAIN 欄位、是否只有 IP 而沒有網域，或是否因為 no-resolve 而未進行預期的位址判斷。如果命中錯誤策略，優先查找前面是否有涵蓋範圍較廣的規則。如果命中正確策略卻仍連線失敗，表示分類與執行必須分開分析；接著應檢查實際選取的連線項目，而不是不斷將精確規則往前移。

第三層：對照本機網路與既有伺服器

Connectivity Test 可協助觀察既有伺服器的連線情況，但單次測試成功不代表所有目標、協定與實際服務都正常。測試失敗也不能單獨證明 Rule 有問題，因為測試流程可能與特定服務請求的目標及處理路徑不同。應將測試結果視為輔助證據，並依實際請求所處的階段判斷：是目標無法解析、遠端無法建立連線，還是連線建立後服務回應異常。各階段需要檢查的欄位都不同。

如果 Config 與 Proxy 的結果不同，固定使用同一個既有連線項目，再比較目標的解析結果與命中記錄；如果 Direct 模式也失敗，應檢查本機網路是否能正常存取目標，尤其留意區域網路主機與內部名稱的環境限制。如果只是速度變慢，而非完全無法連線，應分別檢查本機 Wi-Fi 或行動網路、傳輸參數與實際路徑；請參閱連線速度的逐步排查方式，不要以不斷擴大 PROXY 規則範圍取代問題定位。

第四層：復原變更並重新測試代表性目標

每次只復原一組最近的變更，並以相同目標重新建立連線。如果移除某條廣泛規則後恢復正常，應進一步查明該規則涵蓋了哪些目標，而不是永久刪除所有同類規則。如果撤回 URL Rewrite 後跳轉恢復正常，就應檢查運算式與重新導向循環，而不是繼續修改伺服器。如果切回精簡設定後問題依然存在，複雜規則可能不是主要原因，調查重點應移回網路、解析與既有連線參數。

[Rule]
# 暫時驗證單一目標的分類結果，不代表完整的日常設定
DOMAIN,api.example.com,PROXY
FINAL,DIRECT

這類精簡範例適合驗證已知目標是否套用預期策略，但須替換為實際測試的網域，並保留可還原的原始設定。驗證後別忘了切回日常使用的檔案，否則其他連線都會依測試檔案中的 FINAL 處理。臨時設定也應清楚標示名稱與用途，避免幾天後忘記目前使用的是哪個檔案。測試成功後，再逐組還原原有規則並重新測試，直到找出造成差異的最小變更。

如果問題發生在購買、重新安裝或還原已購項目時，請先閱讀已購項目還原說明；這些步驟與 Rule 比對無關。Shadowrocket 僅透過 App Store 取得，主要使用裝置為 iPhone 與 iPad；系統需求及相容性請以 App Store 頁面標示為準。完成還原後，仍須檢查自己的連線資訊與設定；購買記錄本身無法還原所有服務環境。

最後的結論應寫成可驗證的事實，例如「該網域命中前面的後綴規則，移至精確例外後改為 PROXY」，而不是籠統地寫「設定修好了」。保留這類因果記錄，下次遇到類似情況時，就能快速判斷是否為相同問題。需要重新整理完整操作流程時，請回到快速入門教學；需要了解特定規則時，則依本頁目錄返回相關章節，並始終以實際輸入、實際命中與實際執行結果為依據。