Shadowrocket 規則手冊
設定結構與比對參考

01 設定檔結構與啟用範圍

設定與訂閱是同一份內容嗎？

不是。訂閱通常用來管理一組伺服器連線資訊；設定檔則描述如何處理請求，例如選擇哪種策略、使用哪些網域規則，以及是否需要特定的解析或重寫行為。匯入既有訂閱後，伺服器列表出現項目，不代表某份規則設定已啟用。排查時應分別確認 Home 中可選的伺服器、Config 中目前使用的設定，以及 Global Routing 的狀態，不能以其中一項取代其他項目的檢查。

應先看哪個部分？先辨認以方括號括住的分區名稱，再閱讀分區中的各行。不同分區使用不同語法：General 常見的是鍵值設定，Rule 是逐行排列的比對條件，Host 是網域與位址的對應，URL Rewrite 則使用比對運算式與動作。不要把一行網域規則貼到 General，也不要因為文字可以儲存，就認定它一定會執行預期功能。

[General]
dns-server = system

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

[Host]
portal.example.com = 192.0.2.10

這段最精簡的範例表達什麼？

它在 General 中使用系統 DNS 設定；在 Rule 中先處理範例網域後綴，再檢查位址歸屬，最後指定預設策略；Host 中的位址來自文件範例位址範圍，僅示範對應格式。這裡沒有伺服器連線憑證，也未列出所有可用設定。PROXY 能否實際建立連線，仍取決於目前選用的伺服器及其參數。複製範例時應連同所在分區一起理解，不要只看某個英文關鍵字。

如何建立可復原的編輯流程？在 Config 中找到目前使用的設定，先保留原始檔，再建立容易辨識的副本。記下修改前的 Global Routing、目前伺服器，以及準備驗證的目標網域。每次只修改一個邏輯項目，例如新增一條 DOMAIN 規則，而不是同時更換 DNS、伺服器與預設策略。儲存後再次確認目前使用的是副本，避免編輯了檔案甲，卻用檔案乙進行測試。

General 中的設定都要照抄嗎？

不需要。General 是基礎行為設定，應依具體問題逐項確認。現有設定可能已包含 DNS、連線處理或網路相關選項，整份替換會改變原本正常運作的部分。對不熟悉的鍵，先在 App 內的編輯介面確認名稱與允許值；無法確認用途時就保留原值。本手冊只提供能清楚說明的範例，不建議堆疊參數來尋找所謂的通用設定。

遠端設定更新會如何影響本機修改？如果目前檔案來自遠端來源，更新後是否保留編輯內容，應依 App 內的實際操作結果確認，不要預設所有修改都會自動合併。較穩妥的做法是保留原始來源與本機測試副本，更新後比對自己修改過的規則位置。若發現行為改變，先比較啟用中的檔案、規則順序與基礎設定，而不是立刻判定伺服器失效。

哪些內容適合寫在備註中？可以記錄規則用途、測試目標與復原方式，但不要把自己的訂閱網址、密碼或其他連線憑證寫進準備公開分享的範例。分享排查資訊時，保留分區名稱、關鍵字與先後順序即可；移除敏感欄位後，再檢查截圖或文字中是否仍包含查詢參數。設定是會執行的網路行為說明，不只是方便收藏的文字清單。

03 IP、GEOIP 與 USER-AGENT

IP-CIDR 中的斜線數字代表什麼？

它代表網路前綴長度，用來界定位址範圍，不是連接埠，也不是規則優先級。IPv4 中的 /32 代表單一位址，/24 常用來表示包含 256 個位址的網路區塊。範圍越大，可能涵蓋的目標越多。撰寫前應確認要處理的是單一主機還是整個網路，不要只因位址看起來相似就任意縮短前綴。範圍設定錯誤，可能讓無關請求也套用相同策略。

[Rule]
IP-CIDR,192.0.2.25/32,DIRECT
IP-CIDR,198.51.100.0/24,PROXY
IP-CIDR6,2001:db8::/32,DIRECT
FINAL,DIRECT

這些位址可以用來測試服務嗎？不可以，它們是文件範例位址。第一行說明單一位址規則，第二行說明 IPv4 網路範圍，第三行說明 IPv6 前綴。IP-CIDR6 與 IP-CIDR 分別處理不同的位址家族；設定 IPv4 規則不會自動涵蓋同一服務的 IPv6 位址。如果裝置同時取得兩種位址，測試時應檢查實際使用的目標，避免把位址家族變化誤認為規則隨機失效。

什麼時候該考慮 no-resolve？

IP 類規則可能需要先取得網域對應的位址，再判斷是否落在指定範圍。no-resolve 用來表示不因該規則而額外觸發網域解析；它不代表整個 App 停止使用 DNS，也不保證請求永遠不會出現位址資訊。若請求原本就是 IP，或已有可用位址，仍應依實際條件判斷是否命中。使用前先想清楚：這條規則只處理已知位址，還是也要涵蓋網域解析後取得的位址？

[Rule]
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

為什麼不在每條位址規則後都加上相同選項？因為這會改變網域請求抵達該規則時的處理條件。若希望透過解析結果辨識目標，限制額外解析可能讓後續 FINAL 更常被套用；若只處理已有 IP 的例外，則可能符合需求。應針對單一目標比較修改前後的記錄，不要抱持「選項越多越完整」的想法來撰寫設定。可用語法也應在目前的 App 中核對。

GEOIP 代表網站屬於哪個地區嗎？

不是。GEOIP 依據目標 IP 的地理歸屬資料判斷，不能從網頁文字、註冊資訊或頁面內容推導結果。使用 CDN 的網域可能解析到不同位址，切換網路後歸屬結果也可能改變。GEOIP,CN,DIRECT 的意思是讓符合該位址歸屬條件的請求使用 DIRECT，不是「所有中文網站都直連」，也不是「某個網域之後永遠採用同一策略」。

什麼時候應讓網域規則排在 GEOIP 前面？如果某個網域需要採用固定策略，不希望解析位址變化左右判斷，就應將明確的網域例外放在較前面。GEOIP 適合用來處理較廣泛的位址分類，不適合取代所有精細規則。如果同一服務在不同網路上的表現不一致，先比較解析位址與命中規則，再決定是否新增網域例外，避免不斷調整地理範圍。

USER-AGENT 能可靠地依 App 分流嗎？

不能將它視為通用的 App 身分識別方式。USER-AGENT 比對的是請求中可見的對應欄位，而不是系統中的 App 名稱。加密連線中是否看得到該欄位，以及特定請求是否帶有該欄位，都會影響規則能否運作。此外，不同 App 可能使用相同字串，同一個 App 也可能產生不同字串。應先確認實際欄位，再決定比對運算式。

[Rule]
USER-AGENT,ExampleClient*,DIRECT
FINAL,PROXY

這條範例只說明 USER-AGENT 的位置與萬用字元寫法，不代表實際存在名為 ExampleClient 的請求。如果記錄中沒有可核對的欄位，應優先使用已確認的網域或位址條件。不要只為了讓這種規則命中，就擴大對加密流量的處理範圍；規則條件不可見與伺服器無法使用是兩種不同問題，應分開驗證。

05 比對順序、例外與 FINAL

規則會依類型自動排序嗎？

不會。理解 Rule 的核心是由上而下檢查，命中後採用對應策略。DOMAIN 不會只因為比較精確，就自動排到 DOMAIN-SUFFIX 前面；某條規則寫在後面，也不會自然覆蓋前面的規則。編輯時應把檔案視為有順序的判斷流程，而不是一組會自動計算最佳結果的標籤。要解釋任何命中結果，都應先由上而下找出第一條符合條件的規則。

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

應如何逐行閱讀這段範例？先確認目標是否為 api.example.com；若是，就使用 PROXY，不再由後面的後綴規則改變結果。否則檢查目標是否屬於 example.com 的網域範圍，再考慮位址例外與 GEOIP。前面都沒有命中時，才由 FINAL 接手。這個閱讀流程也說明了維護方式：先列出特殊例外，再處理範圍分類，最後設定預設策略；每一層都應能說明為何放在該位置。

為什麼必須謹慎決定 FINAL？

FINAL 是前面的規則都未命中時採用的最終策略，不是註解，也不是只在出錯時使用的備用項目。設定涵蓋不完整時，大量請求可能會落到這裡。FINAL,DIRECT 與 FINAL,PROXY 代表兩種不同的預設選擇，沒有適用所有情境的標準答案。選擇前應先確認規則主要列出哪一類目標，並判斷未列出的請求應採用哪條路徑，而不是照抄看起來熟悉的結尾。

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

這份極簡設定採用什麼思路？只有列出的範例網域使用代理，其餘交由 DIRECT 處理。如果需求改成「只有明確允許的目標才能直接連線」，就需要重新安排前面的規則並選擇相應的預設策略，而不是只修改 FINAL 就假設整體行為仍符合預期。變更預設策略會影響所有尚未列出的目標，測試範圍也應擴大，至少涵蓋一個例外目標與一個未列出的目標。

重複規則會讓比對更可靠嗎？

不會。前面已有相同條件的規則時，後面的重複行通常無法修正問題；若策略不同，反而會讓維護者誤以為後面的設定有效。刪除重複項目前，應先確認兩行條件是否真的相同，例如 DOMAIN 與 DOMAIN-SUFFIX 並不重複。可以依用途將規則分組，記錄「精確例外」、「網域範圍」、「位址範圍」與「最終策略」，但不要只為了排版整齊而改變已驗證的優先順序。

新增規則後如何檢查是否被前面的規則遮蔽？從第一行開始，以目標網域逐條模擬，找出新增規則之前是否已有範圍較廣的條件會命中。若有，判斷應將新規則上移，還是縮小舊規則的範圍。不要把所有新規則一律放在檔案末尾，尤其不要放在 FINAL 之後，還期待它能參與正常的預設判斷。對於範圍重疊的規則，應在修改說明中寫清楚哪條是例外，以及為何優先處理。

為什麼調整順序後，舊連線沒有立即改變？

規則判斷與建立連線有關；已建立的長連線或重用中的連線，可能沿用先前的處理結果。儲存設定後，應重新發出測試請求；必要時，在確認不會影響重要工作後重新連線。不要只重新整理仍在重用連線的頁面，就判定儲存失敗。比較時應保持請求、網路與伺服器不變，同時區分「舊連線仍在使用」與「新連線仍命中錯誤規則」。

如何確認調整沒有影響到其他流量？除了驗證目標例外，也要測試同一後綴下的另一個子網域、一個無關網域，以及一個位址目標。只驗證最關心的單一請求，很容易漏掉廣泛規則造成的變化。維護記錄應保留修改前後的片段，而非整份包含敏感資訊的設定；下次出現差異時，才能直接判斷是範圍、順序還是環境改變。

07 URL Rewrite 的用途與限制

URL Rewrite 與 Rule 分別會改變什麼？

Rule 主要決定連線採用哪種策略；URL Rewrite 則對符合條件的 URL 執行相應的重寫動作。將請求從一個網址重新導向至另一個網址，不等於指定它使用 PROXY；為網域指定 DIRECT，也不等於修改頁面路徑。若要依路徑處理，應先確認是否真的需要重寫，而不是把完整 URL 填進 DOMAIN。兩種分區可以同時使用，但應分別驗證效果。

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

這段範例表達什麼？開頭是比對運算式，中間是目標位址，最後是重新導向狀態碼。它示範將以 http://example.com/ 開頭的可見請求，重新導向至指定的 HTTPS 位址。點號前的反斜線讓運算式依字面上的網域點號比對，開頭的 ^ 則限定從 URL 起始位置檢查。此範例只用來說明結構，不應據此推斷它是適用於所有網站的通用規則。

為什麼運算式必須控制範圍？

正規運算式中的點號、星號、括號等符號各有其意義，不一定代表畫面上看到的字元本身。未跳脫的點號可能比對任意字元；缺少起始界線則可能在意料之外的位置命中。撰寫前應列出應命中與不應命中的範例，逐一檢查。網域看起來相近，不代表運算式只會作用於該網域；範圍越廣，對登入、API 與資源載入造成的影響就越難追蹤。

為什麼也要仔細檢查目標位址？重新導向會改變請求接下來前往的位置，目標網域、路徑與查詢參數都可能影響頁面行為。若規則將某個路徑一律導向首頁，原本的頁面位置與參數可能不會保留。只有確實需要保留擷取內容時，才進一步使用 App 支援的替換語法，並在小範圍的副本中驗證。不要將不理解的運算式整段貼進長期使用的設定。

一般規則可以直接讀取 HTTPS 路徑嗎？

不能預設可以。HTTPS 會加密請求內容，通常可用的網域路由資訊不等於看得到完整 URL 路徑。針對路徑的重寫沒有生效時，首先應確認目前請求是否符合可見性條件，而不是不斷擴大網域比對範圍。不同請求的處理條件應在 App 內確認；本頁不將解密相關設定視為一般分流的必要步驟，也不建議為了單次重寫任意變更系統信任設定。

如果只想讓某個網域使用代理，該怎麼做？回到 Rule，使用明確的 DOMAIN 或 DOMAIN-SUFFIX 即可，不必加入 URL Rewrite。只有確實需要變更請求 URL，且能驗證請求可見性與目標行為時，才考慮使用相應分區。功能越接近請求內容，就越需要謹慎控制影響範圍；簡單的路由需求應優先使用簡單的路由規則表達。

如何排查重新導向循環與路徑變化？

先暫時移除新加入的重寫行，並在設定副本中確認原始請求是否恢復。如果重寫目標再次符合同一運算式，就可能造成反覆重新導向；即使運算式本身沒有循環，伺服器也可能依自己的規則跳回原始位址。不要只看頁面最後顯示的內容，還應記錄起始 URL、重新導向目標與失敗位置。每次只保留一條待測重寫規則，才能方便確認影響來源。

為什麼把 HTTP 改成 HTTPS 不一定成功？目標服務必須確實支援對應網域與路徑的 HTTPS，且憑證和服務設定都正確。重寫無法讓原本不支援 HTTPS 的服務自動具備這項能力。重新導向後若連線失敗，應分別測試目標位址本身，再判斷運算式是否有誤。不要透過修改 FINAL 或 GEOIP 來掩蓋這類失敗，因為網址修改與連線策略是兩條獨立的驗證流程。