官方手冊 設定與規則參考

Shadowrocket 規則手冊

依設定區段查語法，依請求流程查比對結果。本頁適合已備妥自己的訂閱或伺服器資訊、需要維護規則檔的使用者；範例網域與 IP 僅供說明語法，不代表可用服務。

首次新增伺服器、匯入訂閱及啟用連線，請先依使用教學完成操作；本頁說明這些步驟背後的設定關係，以及修改後如何驗證。教學帶你完成入門流程，規則手冊則供系統查閱，兩者可交互參照。

  • 設定檔：.conf
  • Rule：由上而下比對
  • 修改前先保留原始檔
先釐清購買、伺服器與設定

Shadowrocket 是 Apple 平台的付費用戶端，購買用戶端 ≠ 購買連線方案。本網站不提供、不販售、不推薦節點或訂閱。取得 App 的唯一管道是 App Store，正版確認步驟請參閱下載與購買說明。

本頁目錄

先確認檔案與模式，再查詢特定關鍵字。遇到異常時，從最後一章依據證據回溯，不必一次替換整份設定。

01 / 檔案組織

設定檔結構與生效範圍

Shadowrocket 的設定檔不是伺服器清單的另一種名稱。伺服器資訊描述連線目標、驗證參數與傳輸設定；設定檔則描述流量如何處理、名稱如何解析，以及哪些請求需要特殊處理。訂閱更新了伺服器，不代表目前的規則檔也一併更新；反過來說，匯入規則檔也不代表已備妥可連線的伺服器。排查前先區分這兩個部分，才能避免在錯誤的位置反覆修改。

辨識設定區段與行格式

常見設定區段包括 [General]、[Rule]、[Host] 與 [URL Rewrite]。方括號標示後續內容所屬的設定區段，直到出現下一個區段名稱為止。各區段的語法不盡相同：General 常用鍵值對，Rule 使用逗號分隔欄位，Host 則使用名稱與 IP 的對應。某一行單獨看起來正確，不代表可以放進任意區段；放錯區段同樣會造成無法解析，或導致行為不如預期。

[General]
dns-server = system

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

[Host]
printer.example.com = 192.0.2.20

這段範例展示的是區段編排方式，不是可直接連線的完整服務設定。example.com 是文件範例網域，192.0.2.20 是文件範例 IP，實際操作時應替換為自己有權管理的目標。範例中的 PROXY 也不會建立伺服器，必須使用目前已有的代理選擇。先確認已有伺服器運作正常，再討論某個網域是否交由 PROXY 處理，驗證才有明確前提。

在 Config 確認目前使用的檔案

先在 Config 查看目前選取的設定檔，再開啟內容編輯。儲存檔案與選取檔案是兩個不同動作：儲存到清單中的檔案，不一定就是連線目前使用的檔案。測試新版本時，可保留原始檔，另存一份名稱清楚的副本，再將副本設為目前設定。切換後返回 Home 檢查 Global Routing，確認使用的是 Config，而非仍停留在 Proxy 或 Direct。

遠端設定與本機副本也應分開理解。遠端內容再次更新時，原有的本機修改可能不會保留，實際情況取決於使用的檔案與更新方式。需要長期維護的個人規則，應先確認自己編輯的是遠端檔案的本機內容，還是獨立副本。不要把「這次儲存成功」當成「以後每次更新都會保留」。每次更新後重新檢查重要規則，比猜測合併方式更可靠。

先讀懂結構，再修改內容

首次接手較長的檔案時，先搜尋區段名稱，記下 Rule 的起訖位置與 FINAL 所在行，再確認是否有外部規則引用或其他策略定義。不要只截取搜尋結果中的一行就判斷行為，因為該行上方可能已有範圍更廣的比對條件。不同來源的設定即使使用相同關鍵字，也可能依賴不同的策略名稱；合併前應確認目前檔案或執行環境中有相對應的目標。

編輯器自動替換的中文逗號、全形方括號與彎引號都不是範例語法的一部分。建議直接在設定編輯區輸入半形標點，欄位之間不要插入說明性文字。註解另起一行較易閱讀，也能避免被誤認為策略名稱的一部分。空白行可用來分組，但不會結束比對；規則實際順序仍由它們在 Rule 中的位置決定。

每份設定只保留一個明確的最終出口

維護時將 FINAL 放在 Rule 結尾，並在前面安排例外、網域與 IP 規則。一般規則放在 FINAL 後面，將無法參與本次規則比對。

易於維護的檔案，應讓讀者能回答三個問題：目前選用哪個檔案、規則依賴哪些已存在的策略，以及修改失敗時如何還原。先做好這些紀錄，再新增功能，比堆疊大量未驗證的區段更有用。匯出與換機保留檔案的操作，請接著閱讀設定備份與換機移轉；還原檔案後，仍須重新確認目前的設定與伺服器選擇。

02 / 執行前提

General、DNS 與 Global Routing

General 中的設定提供連線與名稱解析的基礎條件，Rule 則在這些條件下決定請求策略。遇到「規則正確但無法連線」時，不能只檢查 Rule：網域是否成功解析、伺服器本身是否可連線，以及系統是否已將連線交由 Shadowrocket 處理，都可能先於目標規則影響結果。了解這些前提，才能區分規則問題與網路問題，避免用更多規則掩蓋真正原因。

三種執行模式各自要檢查什麼

Global Routing 中的 Config、Proxy、Direct 是執行模式，不是可同時啟用的三個規則區段。設定模式 Config 依目前設定進行分流；代理模式 Proxy 將一般轉送流量交由代理路徑處理；直連模式 Direct 則使用直連路徑。系統路由、排除項目與個別連線限制仍可能影響實際流量，因此模式名稱不能取代請求記錄。測試 Rule 時應明確選擇 Config，再觀察目標請求的處理結果。

介面用語中文說明適合的檢查項目
Config設定模式驗證目前 Rule 的分流結果
Proxy代理模式確認已有的代理路徑是否可用
Direct直連模式確認目前網路的直連狀況

例如，同一個目標在 Proxy 模式下可連線，在 Config 模式下卻失敗，應優先檢查命中策略、策略所使用的伺服器，以及解析結果是否不同。若兩種模式都失敗，先確認已有伺服器資訊與基本連線，不宜直接認定是 DOMAIN-SUFFIX 寫錯。Direct 模式連線成功，只能說明當時直連路徑可用，不代表某條代理規則已正確生效，也不代表所有相關資源都使用相同路徑。

DNS 設定不能取代策略

[General]
dns-server = system

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

dns-server = system 表示使用系統提供的解析設定，是理解設定結構的簡單起點，並非適用於所有網路的通用建議。實際解析行為也與其他 DNS 選項、請求類型和目前的連線環境有關。維護現有設定時，不應為了複製這段範例而刪除原有 DNS 設定；應先記下目前值，再一次只修改一項，比較結果，必要時還原。若同時修改 DNS、規則與伺服器，便無從判斷原因。

網域規則比對名稱，IP 規則比對 IP，兩者之間可能涉及解析流程。如果記錄只顯示 IP，不能據此認定用戶端始終掌握原始網域；如果記錄顯示網域，也不能因此認為後續連線一定成功。應分別記錄解析結果與連線結果。網域無法解析時，先檢查解析流程；解析正常但連線逾時時，再檢查策略出口與目標是否可連線。

繞過項目與隨需連線的適用範圍

現有檔案中的繞過或排除設定，可能讓部分流量不進入預期的規則路徑。這類設定與 Rule 中的 DIRECT 並不完全相同：DIRECT 是規則命中後採取的策略，排除則可能在規則處理之前生效。修改前應閱讀相關選項的 App 內說明，確認它控制的是系統路由、代理例外，還是其他範圍。不要只因選項名稱相似，就把其中一項當成另一項的替代。

On Demand 主要管理何時建立或恢復連線，不能取代 Rule 來決定某個網域使用哪種策略。使用者可能看到連線自動開啟，卻發現請求仍是直連；此時應先確認目前的 Global Routing 和命中記錄，而不是反覆修改 On Demand。反過來說，規則檔完整但連線尚未建立，也不能期待 Rule 自動接手流量。連線時機與連線後的分流，是兩個獨立問題。

調整 General 時，優先記錄足以說明原因的最小修改：原值為何、改成哪一項、用什麼請求驗證，以及結果有何變化。連線恢復後，再測試依賴區域網路或其他名稱解析的目標，避免只驗證一個網站。General 參數的影響範圍通常比單一網域規則更廣；判斷修改成功時，應涵蓋一般情境與例外情境，而非只看首頁能否開啟。

先確認模式，再判斷規則

本手冊的 Rule 範例以 Config 為測試前提。若目前使用 Proxy 或 Direct，請先切回此前提，再比較規則結果。

03 / 名稱比對

DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD

網域規則適合依據名稱表達連線需求，而非追隨經常變動的伺服器 IP。撰寫時先確認要比對的是完整主機名稱、整個網域及其子網域，還是包含特定文字的名稱，再選擇關鍵字。範圍越廣，誤命中的機會越高。維護個人設定時，通常應從精確比對開始；確認請求記錄中確實有共同需求後，再將多條精確規則整併為後綴規則。

DOMAIN：只處理指定主機名稱

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

DOMAIN 用於比對完整網域名稱。第一條規則處理 login.example.com，不應將它理解為也會處理 api.login.example.com 或整個 example.com。規則欄位填寫主機名稱，不含通訊協定、連接埠或 URL 路徑；例如瀏覽器網址列中的完整網址，須先取出名稱部分。若只想處理特定路徑，DOMAIN 本身無法表達這項條件。

同一個頁面可能會連線到登入、圖片、API 與統計等不同主機。為頁面網址新增精確規則，只能涵蓋其中一個名稱。若頁面文字正常顯示但圖片缺失，應查看失敗請求實際連線的主機，而不是立刻擴大規則至所有名稱。逐一檢查開啟頁面時產生的連線，通常就能找出需要補充的資源網域，也能避免不必要地影響其他服務的策略。

DOMAIN-SUFFIX：網域及其子網域

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

DOMAIN-SUFFIX 用於比對指定網域及其子網域。範例先為 local.example.com 設定直連例外，再讓其他屬於 example.com 的名稱使用 PROXY。此處填寫 example.com 即可，不必在前面加星號，也不要將 *.example.com 視為相同寫法。網域邊界很重要，不能把後綴比對理解為名稱中任意位置出現相同文字。

例外規則必須放在範圍較廣的規則之前。如果將範例前兩行的順序對調，後綴規則會先命中，後面的精確直連規則便無法改變此次結果。這不是 DOMAIN 的優先順序較低，而是 Rule 依序處理。較精確的條件不會自動獲得較高優先順序；檔案作者必須透過排列位置表達意圖。新增例外時，先找出可能提前涵蓋它的所有廣泛規則，再決定插入位置。

DOMAIN-KEYWORD：範圍較廣，先確認界線

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

DOMAIN-KEYWORD 用來檢查網域名稱是否包含指定關鍵字，匹配範圍不受單一網域家族限制。範例用來說明語法，並不適合作為未經檢查的日常規則，因為名稱中包含 example，不代表它們屬於同一個組織或服務。關鍵字越短、含義越常見，誤命中的風險越高。若需求可用精確網域或後綴表達，應優先採用範圍明確的條件。

關鍵字比對範圍常見錯誤寫法
DOMAIN完整主機名稱將完整 URL 填入名稱欄位
DOMAIN-SUFFIX網域及其子網域多加了不必要的星號前綴
DOMAIN-KEYWORD名稱中包含關鍵字把關鍵字當成組織界線

驗證網域規則時，至少準備一個應命中的名稱，以及一個不應命中的名稱。使用後綴規則時，還應測試根網域與子網域；使用關鍵字規則時，則額外檢查一個包含相同文字、但不屬於目標範圍的名稱。這類反向測試能揭露規則範圍過廣的問題。只確認「目標可以開啟」，無法判斷是否也把原本應直連的其他請求送進代理路徑。

網域包含國際化字元時，應核對請求記錄中實際顯示的名稱格式，再依用戶端接受的格式填寫。不要直接照抄含空格的顯示標題，也不要把瀏覽器為方便閱讀而顯示的文字當成最終比對值。另一個常見問題是修改規則後不斷重新整理同一頁面：App 可能重用既有連線，因此應建立新請求，並確認新連線使用修改後的策略。

規則增加後，可將「精確例外、服務網域後綴、謹慎使用的關鍵字」分成連續的小組，但不要按關鍵字機械式排序。排序應依服務例外關係，而非字母順序。若只想讓指定網站使用代理，可參考指定網站分流寫法，先建立範圍較小的清單，再依實際資源請求補齊，不必一次涵蓋大量無關名稱。

04 / IP 與請求特徵

GEOIP、IP-CIDR、IP-CIDR6 與 USER-AGENT

IP 規則處理的是「目標 IP 屬於哪個範圍」，而不是「使用者正在使用哪個 App」。當請求直接連線至 IP、網域資訊無法取得，或需要為明確的內部網段設定例外時，IP 規則便很實用。不過，不同服務可能共用 IP，解析結果也可能變動，因此不宜僅憑單次觀察，就長期將大型 IP 網段固定交由某種策略處理。先確認 IP 的來源與管理責任，再決定是否加入設定。

IP-CIDR：IP 與前綴長度共同決定範圍

[Rule]
IP-CIDR,192.0.2.20/32,DIRECT,no-resolve
IP-CIDR,198.51.100.0/24,PROXY,no-resolve
FINAL,DIRECT

IPv4 的 IP-CIDR 欄位由網路位址與前綴長度組成。/32 表示單一 IP，/24 則表示一段 IP 範圍；數字不是連接埠，也不是優先順序。範例使用文件專用 IP，不能用來判斷真實網路是否可連線。實際維護時，應確認填寫的範圍符合預定網路邊界；若任意將較短的前綴加在單一目標 IP 後，可能涵蓋許多無關目標。

no-resolve 是 IP 規則的選用參數，用來避免僅為檢查這條規則而觸發網域解析。它不代表關閉所有 DNS，也不表示規則一定會命中。請求已具備可供比對的 IP 時，仍可進行 IP 比對；若只有網域資訊而沒有相應 IP，則不能期待它主動解析後再命中。排查這類規則時，應同時記錄請求帶有的是名稱還是 IP。

IP-CIDR6：分別檢查 IPv6 路徑

[Rule]
IP-CIDR6,2001:db8::20/128,DIRECT,no-resolve
IP-CIDR6,2001:db8:1::/48,PROXY,no-resolve
FINAL,DIRECT

IP-CIDR6 使用 IPv6 網路前綴，/128 可表示單一 IPv6 位址。範例中的 2001:db8:: 僅供文件示範。只設定 IPv4 規則，不代表同一網域透過 IPv6 連線時也會命中；若網路與目標同時提供兩種 IP，測試應涵蓋實際使用的 IP 版本。不要因為 IPv4 測試成功，就認定整個目標的 IP 分流已設定完整。

若同一目標在不同網路下採用的策略不同，先檢查解析結果與實際連線 IP，再確認設定中是否只包含其中一種 IP 規則。直接停用某種 IP 功能或許能暫時改變狀況，卻不能證明規則範圍合理。若需求本質上針對穩定的網域家族，優先考慮網域規則；若需求針對自己管理的明確網段，再使用相應的 IP 規則，通常更容易控制維護成本。

GEOIP：依 IP 資料庫分類

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

GEOIP 會依據 IP 資料庫分類目標 IP。GEOIP,CN,DIRECT 表示符合資料庫中歸類為 CN 的 IP 時採用 DIRECT，並非依網頁語言、網域後綴或使用者所在地判斷。資料庫分類與服務實際所屬地區未必一致，使用分散式基礎設施的目標尤其如此。明確的服務例外應放在 GEOIP 前面，不宜依靠 IP 分類推測網域應採用哪條路徑。

GEOIP 也需要可用的 IP 資訊。某次請求未命中預期的地區條件時，應檢查實際目標 IP、資料庫分類與前置規則，而不是只修改國家或地區代碼。將 GEOIP 與 FINAL 搭配使用時，也要確認未命中的請求會走哪條路徑：範例將其他請求交由 PROXY，與 FINAL,DIRECT 的預設方向相反。複製範例前應讀完最後一行。

USER-AGENT：請求特徵不等於 App 身分

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

USER-AGENT 依據可取得的 User-Agent 資訊比對請求，範例中的 ExampleClient* 表示以該文字開頭的特徵。它不是通用的 App 名稱分流方式：多個 App 可能使用相同識別字，同一個 App 也可能在不同請求中使用不同識別字。若加密請求中沒有可讀取的標頭資訊，就不能期待僅靠這條規則辨識內部的 User-Agent。

使用 USER-AGENT 前，先確認記錄中確實能看到相應特徵，再以明確的測試請求驗證。不要為了讓這條規則生效而任意擴大解密範圍，也不要把標頭比對失敗誤判為代理伺服器故障。名稱、IP、請求標頭屬於不同層次的證據；只有確認目前請求提供哪一種資訊後，才適合選用相應關鍵字。

05 / 決策順序

PROXY、DIRECT、REJECT 與比對優先順序

規則由條件與動作組成：前面的欄位說明要比對什麼，策略欄位則說明命中後如何處理。PROXY、DIRECT、REJECT 是常見的策略關鍵字，須與 Global Routing 介面中的 Proxy、Direct 區分大小寫與使用位置。讀取規則時，應同時解讀條件與動作，不能只看是否出現某個網域。同一網域搭配不同策略，行為可能完全不同。

三種策略各自的用途

PROXY 會將命中的流量交給相應的代理選擇，前提是使用者已有可用伺服器與正確的連線參數。命中 PROXY 只決定出口方向，不保證伺服器可連線，也不保證目標會接受請求。DIRECT 表示直連目標，仍須仰賴正常解析與可用的網路路徑。REJECT 用來拒絕符合條件的請求，適合範圍明確且確認可以封鎖的目標，不應將它視為「失敗後改走其他路徑」的指令。

策略處理方式驗證重點
PROXY交由代理路徑處理命中結果與已有伺服器的連線狀況
DIRECT使用直連路徑解析結果與目前網路的連線狀況
REJECT拒絕該請求是否只影響預定目標

DIRECT 不等於離開 Shadowrocket，也不是停止連線的開關。它可以是 Config 模式下某條規則的處理結果，同時其他請求仍使用 PROXY。類似地，REJECT 不會讓整台裝置中斷網路，只會影響符合條件的請求。但若封鎖了共用 API、驗證服務或多個頁面都需要的資源，使用者受到的影響可能很大，因此應採用精確條件並保留復原方法。

先命中的規則決定本次策略

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

範例先拒絕一個明確主機，再為另一個主機保留直連例外，接著讓其餘屬於該後綴的名稱使用 PROXY，之後才檢查 GEOIP，最後由 FINAL 處理未命中的請求。此處的優先順序取決於規則位置，而非關鍵字的「精確程度排名」。若將後綴規則移到最前面，兩條精確規則就會被提前涵蓋；若將 FINAL 放在最前面，其餘一般規則便無法參與此次判斷。

命中後停止比對，指的是此次 Rule 策略選擇不再往後尋找其他一般規則，不代表整個請求只會執行一項設定功能。DNS、建立連線與其他處理機制仍有各自的階段。也不要以為連線失敗後會自動繼續比對下一行：規則命中 PROXY 後若伺服器連線失敗，後面的 DIRECT 通常不會自動成為備用出口。需要復原時，應修復策略所依賴的路徑，而不是等待後續規則接手。

FINAL：明確指定其餘請求的去向

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

FINAL 不需要網域或 IP 參數，用來為前面沒有命中的請求指定最終策略。範例表示「列出的網域使用代理，其餘直連」。若改成 FINAL,PROXY，預設方向也會隨之改變，所有未列出的請求都可能進入代理路徑。許多看似局部的異常，實際上是複製設定時忽略了 FINAL。修改最終策略前，應先列出登入、區域網路存取與常用服務等需要保留的例外。

維護時建議只保留一條放在結尾的 FINAL。多條 FINAL 不會形成依序嘗試的備援鏈；第一條已接手處理其餘請求，後面的同類條件便沒有機會參與。若編輯工具讓檔案中出現重複的結尾規則，應先確認哪一段屬於目前的 Rule，再清理多餘內容。不要只刪除看似重複的行，卻未確認是否意外合併了兩個不同來源的設定區段。

自訂策略引用必須能正確解析

較複雜的檔案可能在策略欄位使用自訂名稱，而非直接填寫 PROXY。此時必須確認目前設定與 App 支援的機制中有定義該名稱，並且能找到可用目標。若複製了引用外部策略的規則，卻沒有一併複製或建立對應定義，就會留下無法解釋的依賴。本手冊使用內建策略說明核心語法，避免將特定設定檔的命名習慣誤認為固定關鍵字。

判斷規則衝突時要查看上方，不只看相鄰兩行

確認規則涵蓋關係時，從 Rule 第一行開始往下追蹤，直到首次命中為止。較早出現的關鍵字、IP 規則或外部規則引用，都可能比眼前的精確規則更早決定結果。

整理順序的目標是清楚呈現例外關係，而不是讓檔案看起來整齊。將每條規則的用途寫成獨立註解，並記錄為何需要比下一組規則更早處理。日後增刪時，先確認這項原因是否依然成立。能說明規則位置，才有條件安全合併；用途不明的規則，應先隔離測試，不宜直接放進長期使用的檔案。

06 / 名稱對應與請求處理

Host 與 URL Rewrite 的用途範圍

Host 與 URL Rewrite 都可能改變使用者看到的存取結果，但解決的問題不同。Host 主要負責名稱與 IP 的對應；URL Rewrite 則依可見的 URL 進行比對與處理。前者不是代理策略，後者也不能取代網域分流規則。判斷需要哪項功能時，先用一句話說明目標：指定解析 IP、選擇連線路徑，還是將某種網址格式改成另一種格式。

Host：固定對應不等於固定出口

[Host]
printer.example.com = 192.0.2.20

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

範例將一個名稱對應到文件示範 IP，同時透過 Rule 為這個名稱選擇 DIRECT。這兩行分別負責解析與路徑決策，不能互相取代。實際使用時，IP 必須是自己有權使用且目前網路能連線的目標。將網域指向某個 IP，不會讓原本無法連線的網路突然可用，也不會自動建立驗證、連接埠轉送或伺服器端的虛擬主機設定。

固定對應也可能讓原有的動態解析失效。如果目標依賴 IP 變更、就近調度或故障切換，長期保留過時對應可能造成連線逾時。新增前應確認是否確實需要固定 IP，並記錄撤銷方式。測試時不只要確認名稱解析出預期 IP，還應確認存取的服務、連接埠與憑證身分符合預期；不能只因 IP 有回應就判定服務正常。

Host 不會取代瀏覽器目前存取的主機身分。存取 HTTPS 網域時，伺服器憑證仍須通過該網域的驗證。若將名稱對應到不提供相應服務的 IP，可能出現憑證錯誤或錯誤網站，不應以忽略驗證的方式處理。正確做法是確認目標服務支援該名稱，並確認對應是用於經授權的測試環境。恢復正常解析後，再確認相關快取已更新。

URL Rewrite：正規表示式、目標與動作

[URL Rewrite]
^http://legacy\.example\.com/(.*)$ https://www.example.com/$1 302

範例以正規表示式比對舊網址，將擷取到的路徑帶入新網址，並回傳 302 重新導向。句點前的反斜線表示比對實際句點，前後的錨點限制比對範圍，括號擷取的內容則以 $1 引用。這裡的兩個網域都是範例；套用到自己的設定前，應替換為有權測試的目標，並先確認查詢參數與編碼是否依需求保留。

正規表示式中的句點預設有特殊意義，若忘記跳脫，可能比對到非目標名稱；省略主機邊界，也可能涵蓋看似相似的其他網址。維護 URL Rewrite 時，至少準備一個應命中的範例、一個相似但不應命中的範例，以及一個包含路徑與查詢參數的範例。不要只用首頁網址測試：首頁沒有路徑時能正常運作，不代表較長網址也能正確處理。

加密內容的可見性限制與處理階段

完整 HTTPS URL 的路徑位於加密內容中，一般連線分流無法直接讀取其中所有欄位。URL Rewrite 是否能套用到目標，取決於請求資訊是否可見及相關處理條件。不能把「已經寫好正規表示式」當成「已具備讀取路徑的條件」。也不應為了驗證重新導向規則就直接擴大解密範圍；涉及憑證與加密處理的設定，應另行評估授權、隱私與 App 相容性。

Rule 由上而下比對的原則，不能簡化成「整份設定檔從上到下只執行一次」。不同設定區段負責不同功能；檔案中 Host 排在 Rule 前面，不代表它必定依文字順序先執行。排查改寫問題時，應沿著請求流程觀察：原始網址為何、是否發生重新導向、重新導向後的目標為何，以及後續連線採用什麼策略。如此才能區分改寫未觸發、重新導向目標失敗與後續分流錯誤。

發生重複重新導向時，先停用這次新增的規則

若新目標再次符合舊規則，或網站將請求導回原網址，就可能形成循環。先還原原設定並確認恢復正常，再縮小正規表示式的範圍，不要繼續疊加方向相反的重新導向。

瀏覽器可能會快取重新導向結果，服務 App 也可能快取解析與連線。撤銷規則後仍出現舊行為，不一定代表檔案未儲存；應先確認目前設定，再以新請求或獨立測試工作階段複查。長期維護的改寫規則，應記錄用途、適用主機、預期動作與刪除條件，避免目標網站已調整網址結構，本機規則卻仍強制沿用過時流程。

Host 與 URL Rewrite 最適合處理範圍小、用途明確的需求，不宜用來解決所有存取異常。若只是希望某個網站使用 PROXY，應回到網域規則；若解析結果錯誤，先確認 DNS 與既有對應；若請求遭網站拒絕，則還要檢查身分驗證與服務回應。先判斷問題所在層級，再選擇設定區段，檔案會更精簡，故障也更容易重現。

07 / 組合範例

常見分流寫法與修改步驟

組合範例應從需求出發，而不是從規則數量開始。先決定預設策略，再列出必須設為例外的目標，最後選擇精確網域、後綴或 IP 條件。以下每段範例各自代表一種獨立做法，不應連續貼入同一個 Rule。合併多種方案時，必須重新檢查 FINAL、例外順序與重複條件，否則後貼上的內容可能完全不會參與判斷。

指定網站使用代理，其餘直連

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

這種設定適合需求範圍明確、只希望清單內目標使用代理的情境。先列出需要直連的帳戶主機，再列出兩個範例網域家族，其餘請求交由 DIRECT。實際新增時，先用一個目標確認伺服器與規則都正常，再逐步補上該服務需要的其他主機。不要因頁面缺少某項資源就將 FINAL 改成 PROXY；這會改變所有未列出的請求，不再是原本的小範圍方案。

維護清單時，應分開記錄使用者輸入的頁面網址與實際資源請求。服務可能將靜態檔案、API 與登入流程放在其他網域，後綴規則無法自動推斷這些關係。補充時只加入實際觀察到且確實需要的目標，同時確認清單外的常用網站仍然直連。詳細操作可參閱僅讓指定網站使用代理的規則說明。

明確例外直連，其餘使用代理

[Rule]
DOMAIN,portal.example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
FINAL,PROXY

這段範例採用相反的預設方向：將明確主機與常見私有 IPv4 網段設為直連例外，其餘請求交由代理。私有 IP 規則只涵蓋相應的 IP 條件，不能保證所有區域網路探索、廣播或特殊網路功能都能正常運作。如果目前網路使用其他網段或 IPv6，還需依實際情況另行分析。不要把幾條私有 IP 規則當成完整系統網路設定的替代品。

使用 FINAL,PROXY 前，應確認已有代理路徑能處理日常需求，並檢查身分驗證、區域網路服務與必要的直連例外。某項服務需要直連時，先為它設定範圍明確的條件，再測試是否影響共用基礎設施上的其他請求。若某項服務使用大量動態網域，應持續依據記錄維護，而不是猜測寬泛的關鍵字，期待它長期準確。

封鎖明確主機，保留同網域的其他請求

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

此處只封鎖一個精確主機，不會拒絕整個後綴。首次測試 REJECT 時，最好選擇用途明確且不影響重要流程的目標，再檢查頁面、登入與 API 是否仍正常。請求失敗是這條規則預期的結果之一，但使用者不一定能判斷失敗原因，因此應保留清楚註解。若造成誤擋，撤銷這條規則比繼續新增多個補丁更容易還原。

若遭封鎖的主機也承載其他必要服務，規則無法只憑網域辨別其內部用途。此時應重新評估需求，不要以擴大封鎖範圍作為補救。某個請求被 REJECT 後，App 可能改用其他目標或重新嘗試；記錄中出現新請求，不代表原規則失效。應逐一比較各次請求的實際名稱與策略，確認是同一目標重試，還是服務另行建立了連線。

安全地將新規則併入現有檔案

先複製原設定，再找出現有的 Rule 與結尾的 FINAL。將新例外放在可能涵蓋它的廣泛規則之前，不要另開第二個 Rule 區段來猜測合併效果。若現有檔案包含規則引用，先了解其範圍，再決定插入位置。儲存後選取這份副本，確認 Global Routing 設為 Config，最後建立新請求並核對命中結果。驗證失敗時，回到原始副本，避免在狀況未明時繼續疊加修改。

  1. 以文字寫下目標、預設策略與需要保留的例外。
  2. 記錄目前設定、伺服器選擇與 Global Routing。
  3. 只加入這次必要的規則，並檢查欄位、策略名稱與 FINAL 位置。
  4. 分別測試應命中、應排除與日常依賴的請求。
  5. 確認結果後儲存備註；未達預期就還原原始檔並繼續排查。

訂閱更新可能會變更現有伺服器清單，但不能取代上述規則驗證。若目前策略依賴的伺服器有變動，應重新檢查代理路徑；若只是伺服器顯示名稱改變，也不能據此推斷規則內容已變。管理多個訂閱時，可參考多個訂閱的分組與整理，將來源管理與規則維護分開，避免把重複伺服器誤寫成規則例外。

08 / 檢查與還原

驗證命中、排查故障與還原設定

驗證規則的目的，不是讓某次存取碰巧成功，而是證明指定請求依預定條件採用預定策略，同時沒有破壞應保留的行為。完整紀錄應包含測試時間、目前設定名稱、Global Routing、目標名稱或 IP、實際命中結果與連線狀況。時間只用於對照此次測試，不代表 App 更新資訊。證據越具體，下次網路狀況改變時就越容易和舊結果比較。

逐層排查，不要從規則數量猜測原因

先確認連線是否建立，以及目前選用的檔案是否正確，再檢查請求是否進入預期的處理範圍。接著核對名稱解析與實際目標，再查看第一條命中的條件，最後確認策略出口是否可用。若前一層已經失敗，修改後一層通常沒有幫助。例如名稱解析失敗時，新增更多網域後綴未必有用；命中 PROXY 但伺服器連線失敗時，調整 FINAL 也不是針對性的修復。

觀察到的狀況優先檢查項目下一步
所有新規則都沒有作用目前設定與 Config 模式確認已選取檔案，並建立新連線
目標先命中了較前面的規則上方規則的涵蓋關係將必要例外移到廣泛規則之前
命中 PROXY 但連線失敗已有伺服器與目標連線狀況對照 Proxy 模式與具體錯誤
只有部分資源失敗失敗資源的實際主機逐一核對相關請求，而非頁面標題
撤銷後仍出現舊行為快取、持續連線與目前檔案建立新的測試請求後再比較

Connectivity Test 可協助觀察已有伺服器的測試結果，但不能證明所有網站、通訊協定與服務請求都可使用。測試成功後，實際存取仍可能遇到名稱解析、目標拒絕或服務驗證問題。應將測試結果視為證據之一，而非最終結論。同樣地，網頁成功開啟也不能證明流量經過 PROXY，必須搭配該請求的策略記錄判斷。

建立正向、反向與回歸測試範例

正向測試用來確認目標應命中，反向測試用來確認範圍沒有擴大，回歸測試則用來確認原本正常的功能仍可使用。例如新增 DOMAIN-SUFFIX 後，測試根網域與一個子網域，再測試不屬於該後綴的名稱，最後檢查登入與區域網路存取。不要為了測試而存取用途不明的目標；使用自己有權存取且用途清楚的服務即可，範例網域只用於示範語法。

測試時盡量一次只變更一個變數。保持伺服器、網路與執行模式不變，只修改一條規則，比較結果後再進行下一項。若必須切換網路，應單獨記錄，避免把網路變動造成的解析差異歸因於規則修改。若頁面會重用連線，請關閉相關測試工作階段並重新發出請求；新規則通常需要透過新連線觀察，不能只依據舊連線的延續狀況判斷。

分享記錄與敏感資訊處理

若排查時需要分享記錄，只保留重現問題所需的目標、規則、策略與錯誤資訊。訂閱連結中的驗證參數、伺服器密碼、私人請求路徑、帳戶識別資訊，以及完整設定中的驗證內容，都應先移除。截圖也可能包含這些資訊，不能因為只是圖片就省略檢查。將敏感內容替換為明確的範例值，並註明已替換的欄位，才能兼顧問題重現與資訊保護。

若要縮小問題範圍，可建立最小測試設定：保留必要的 General 設定、目標的一條規則與一條 FINAL，繼續使用自己已有的伺服器。若最小設定正常，再逐組恢復原有規則，直到找到造成差異的部分。還原時維持每組原有順序，不要同時重新排列整份檔案。如此便能判斷問題來自某項條件、外部引用，或多個例外之間的先後關係。

還原後也要重新確認執行狀態

還原不只是把文字改回原樣。應重新選取原設定，確認 Global Routing 與已有伺服器的選擇，必要時重新建立連線，再對照先前正常的測試範例。若還原原設定後仍有異常，應考慮網路、伺服器或目標服務可能已變動，不要把所有問題都歸因於這次編輯。保留修改前後的兩份檔案與簡短紀錄，可避免日後憑記憶還原時引入新的差異。

判斷修改完成的標準

目標正確命中、例外未受影響、日常請求通過回歸測試，且能還原至修改前的狀態。四項都確認後，再將測試副本作為長期使用的設定。

換機還原時，先確認 App 來自 App Store，再還原自己保存的伺服器資訊與設定檔，最後重新檢查目前設定與系統連線授權。系統要求以 App Store 頁面標示為準。購買與重新取得 App 的問題，請參閱已購項目還原說明及該頁的購買常見問題；首次連線步驟請回到使用教學，規則含義則依本頁目錄逐項確認。

長期維護時，可保留一份穩定版本與一份測試版本：穩定版本只納入已驗證的修改，測試版本則用於新增條件與重現問題。定期移除不再使用的例外，確認固定 IP 仍然有效，並在遠端設定更新後重新檢查個人規則。規則檔的價值不在長度，而在於每個條件都有依據、每次結果都能核對、每次修改都能還原。