Shadowrocket
規則與設定參考
依設定檔段落查閱欄位，依請求目標選擇規則，再根據命中記錄驗證結果。
本頁是 Shadowrocket 的系統參考手冊，適合已備妥自己的訂閱或伺服器資訊，並需要調整規則的使用者。首次匯入、授權與連線，請先依照入門指南操作，再回到本頁了解各項設定的用途。本頁範例是獨立的知識片段，不是包含伺服器憑證的完整連線設定。
01 / 設定檔
設定檔段落與生效範圍
先釐清伺服器、訂閱與設定檔的差異
伺服器記錄儲存連線目標與驗證參數；Subscribe 用於管理既有訂閱及其中的伺服器記錄；Config 中的設定檔則描述解析、規則與請求處理方式。三者彼此相關，但不能互相取代。訂閱更新成功，不代表目前使用的是哪一份規則檔；匯入規則檔，也不等於已備妥伺服器位址、連接埠與驗證資訊。查閱前，先在 Home 確認已有可用記錄，再到 Config 確認目前選用的檔案，避免將連線資料問題誤判為規則語法問題。
訂閱與規則設定的更新週期也可能不同。訂閱更新通常只處理其實際包含的內容，不應假設它會一併修改手動維護的規則。反過來說，遠端設定更新也可能變更先前編輯過的段落。修改前先保留副本，並記下哪些內容來自遠端、哪些由自己維護。訂閱資訊請向服務商取得；公開討論時，不應在設定檔截圖或文字中透露帳戶憑證與私人連結。
方括號標示段落，欄位只在所屬段落中解讀
Shadowrocket 設定檔以段落組織內容。[General] 放置一般設定，[Rule] 放置依序比對的項目，[Host] 指定網域的位址對應，[URL Rewrite] 則描述符合條件的 URL 如何改寫。段落名稱不是註解，不可任意翻譯；貼上規則項目前，也要確認已切換至 Rule 段落。以下展示基本格式，各段落處理不同問題，並非每份設定檔都必須包含所有欄位。
[General]
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY
[Host]
printer.example.com = 192.168.1.20
[URL Rewrite]
^http://example\.com/ https://example.com/ 302閱讀範例時，應分開理解段落邊界與規則順序。檔案中的 General 不會像 Rule 一樣逐條決定某個網域採用的策略；Host 的位址對應也不是 DIRECT 指令。若網域對應至區域網路位址，仍應確認該請求最後命中哪條規則。分別觀察「解析目標、選擇策略、建立連線」三個環節，比只確認檔案中是否出現某個網域，更能判斷實際行為。
編輯、儲存與選用是不同操作
在 Config 編輯後，先儲存，再確認儲存的是準備使用的檔案。若同時保留原檔與測試副本，請為副本取一個容易辨識用途的名稱，避免只依清單位置判斷。接著確認 Global Routing 設為 Config；如果仍是 Proxy 或 Direct，就無法依預期驗證 Rule 的分流效果。測試時重新發出請求；必要時結束既有連線後再開啟目標頁面，因為已建立的連線不會在文字儲存後自動重新進行完整比對。
對於來源明確的既有設定，建議小幅修改，不要刪除所有段落後重新組合。有些一般欄位彼此相關，移除一行可能同時影響 DNS、區域網路存取或連線方式。無法判斷用途的欄位先保留，並查閱 App 內的相關說明。每次只變更一項可驗證條件，測試通過後再繼續；發生異常時，還原副本比不斷新增例外規則更容易找出真正原因。
02 / 一般設定
General、Global Routing 與 DNS
路由模式會決定是否採用規則選擇
Global Routing 是排查規則前應先確認的設定。Config 依目前設定檔選擇策略；Proxy 會讓由用戶端處理的請求使用目前的代理選擇；Direct 則採用直連方式。這些是不同的處理模式，不是同一份規則檔的三種優先級。若請求在 Proxy 下可建立連線、在 Config 下卻失敗，應繼續查看實際命中的規則，而不是立刻認定伺服器失效。反之，在 Direct 下能存取，也不能證明代理連線路徑可用。
| 介面用語 | 查閱重點 | 適合驗證的問題 |
|---|---|---|
| Config | 目前設定檔與第一條命中的規則 | 特定目標為何採用某項策略 |
| Proxy | 目前的代理選擇與連線參數 | 代理路徑能否完成相同請求 |
| Direct | 本機網路與目標可連線性 | 直連路徑是否具備存取條件 |
「由用戶端處理」是重要的範圍界線：App 外部的系統行為、既有連線，以及設定中的特殊處理條件，都會影響實際觀察到的請求。切換模式後，請以同一個目標和相同的請求方式重新測試；不要拿網頁存取與 App 背景連線互相比較。如需逐步了解切換方式，可閱讀Global Routing 的 Config、Proxy、Direct 說明，再依本頁的規則章節判讀命中結果。
General 是一般條件設定，不是規則優先級開關
General 中常見欄位採用 key = value 格式，實際可用選項請以 App 內的設定編輯器與說明為準。不要將其他語法體系中的同名欄位直接移入檔案，也不要因欄位名稱相似就認定語意相同。以下僅列出最精簡的 DNS 範例：system 表示使用系統提供的解析設定，不是固定指定某個解析伺服器位址。修改 DNS 前，應先確認問題發生在名稱解析階段，還是建立連線階段。
[General]
dns-server = system
[Rule]
DOMAIN,api.example.org,DIRECT
FINAL,PROXYDNS 負責將名稱解析成位址，策略則決定請求採用哪條處理路徑；兩者需要配合，但不能混為一談。某網域命中 DIRECT 後仍可能解析失敗；網域成功取得位址，也可能因代理驗證、目標連接埠或遠端連線異常而失敗。排查時先確認是否取得網域與解析結果，再查看命中規則及連線錯誤。僅憑「切換 DNS 後暫時恢復」的現象，不能推斷原有規則全都正確。
位址規則可能需要先進行名稱解析
當請求以網域發出，而後續規則需要判斷目標 IP 或 GEOIP 時，比對流程可能必須先取得位址。這項解析作業不只影響耗時，也可能讓記錄中出現與目標請求相關的 DNS 項目。若將大量位址規則排在網域規則前面，原本可直接依網域決定的請求，也可能進入額外的位址判斷。通常先列出明確的網域例外，再處理需要位址資訊的範圍規則，能讓設定意圖更清楚。
位址規則中的 no-resolve 可限制為了比對該條規則而主動解析網域，但它不是「關閉所有 DNS」的開關。請求若已有目標 IP，仍可參與位址比對；只有網域而沒有可用位址的請求，則可能繼續比對後續規則。啟用後，應分別測試以網域和 IP 發出的請求，不能只測其中一種。具體寫法請參閱位址章節；不要只為了減少一筆記錄，就任意替所有 IP 規則加上這個參數。
也要區分 IPv4 與 IPv6 的實際連線目標。同一網域可能回傳多個位址，App 選用的位址不一定與手動查詢時看到的第一筆相同。只涵蓋 IPv4 私有網段的規則，不會自動涵蓋所有 IPv6 情況。遇到「同一網域偶爾走不同路徑」，先核對實際目標位址、解析快取與連線重用，再評估是否需要補上另一個位址族的規則。記錄這些觀察條件，才能得出可重現的結論。
03 / 網域比對
DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD
DOMAIN：只處理指定的主機名稱
DOMAIN 用於完整網域比對，適合為特定 API、登入入口或服務主機設定個別策略。例如 DOMAIN,api.example.org,DIRECT 只針對 api.example.org，不包含 example.org，也不包含另一個主機 static.example.org。填寫時只輸入主機名稱，不要加上通訊協定前綴、連接埠、路徑或查詢參數。若要處理的是特定 URL，應先確認需求是設定整個主機的路由，還是使用下文介紹的 URL 改寫。
[Rule]
DOMAIN,api.example.org,DIRECT
DOMAIN,static.example.org,PROXY
FINAL,PROXY瀏覽器網址列顯示的主機名稱，不一定涵蓋整個頁面的請求。頁面可能另外載入圖片、腳本、登入與 API 主機；主文件走 DIRECT，不表示這些請求也會走 DIRECT。驗證規則時，應以記錄中的實際請求網域為準。若頁面主體能開啟，但登入或資源載入失敗，先逐一確認出錯的主機，不要直接將範圍擴大到可能包含無關服務的關鍵字。
DOMAIN-SUFFIX：依網域層級涵蓋多個主機
DOMAIN-SUFFIX 用於比對網域後綴。以 example.com 為參數時，通常涵蓋 example.com 本身及 www.example.com、img.example.com 等子網域。這是依網域層級判定的後綴，不是任意字串包含關係；notexample.com 不會因此成為同一網域的子網域。當同一服務網域及其子主機應採用相同策略時適合使用；少數主機則可用排在前面的 DOMAIN 規則單獨處理。
[Rule]
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT這段範例中，local.example.com 先命中精確項目，其餘隸屬 example.com 的主機才由後綴規則處理。若交換兩行順序，精確項目不會因為名稱更具體就自動取得優先權。也要注意，服務使用的內容傳遞網域可能不屬於自己的主網域；只新增一條後綴規則，無法保證所有資源都採用同一策略。應依實際請求補充規則，而不是根據品牌名稱猜測網域範圍。
DOMAIN-KEYWORD：使用方便，但範圍較難控制
DOMAIN-KEYWORD 用來判斷網域是否包含指定關鍵字，適合確實需要跨多個命名空間處理同一特徵的情況。它的比對範圍比後綴更廣：參數 example 可能符合 example.com，也可能符合其他包含這段字串的網域。因此不宜使用過短、常見或意思模糊的詞作為大範圍分流條件。若已知明確主機或主網域，優先使用 DOMAIN 或 DOMAIN-SUFFIX，日後較容易說明規則涵蓋範圍。
| 類型 | 參數範例 | 範圍說明 |
|---|---|---|
| DOMAIN | api.example.org | 完整主機名稱 |
| DOMAIN-SUFFIX | example.org | 主網域及其子網域 |
| DOMAIN-KEYWORD | example | 網域包含指定關鍵字 |
網域規則仰賴用戶端在比對時取得目標名稱。如果 App 直接連線至 IP，或目前請求記錄只有位址、沒有可用網域，新增更多網域項目也未必有效。先確認記錄中有哪些可供判斷的資訊，再決定使用網域規則或位址規則。不要只根據「正在存取某個網站」的使用者描述，就假定每條底層連線都帶有該網站的完整名稱。
維護網域規則時，也要留意重新導向與快取。輸入的網址可能先跳轉至另一個主機，瀏覽器也可能重用先前建立的連線。修改後建議重新開啟目標並觀察新請求；仍有疑問時，可在條件允許下結束舊連線後再測試。含國際化字元的網域，應依用戶端實際記錄的名稱核對，避免將顯示名稱、編碼形式與 URL 路徑混為同一個比對參數。
04 / 位址與特徵
IP-CIDR、GEOIP、USER-AGENT 與 FINAL
IP-CIDR 與 IP-CIDR6：比對目標位址範圍
IP-CIDR 以位址和前綴長度表示 IPv4 網路範圍。192.168.0.0/16 涵蓋對應的私有位址區段，而 192.168.1.20/32 只代表一個 IPv4 位址。前綴越長，範圍越小；但「更具體」只描述位址集合，不會改變規則順序。IP-CIDR6 則用於 IPv6，例如 fd00::/8 表示相應的本機位址範圍。前綴填錯，可能讓例外涵蓋遠超預期的目標。
[Rule]
IP-CIDR,192.168.1.20/32,DIRECT,no-resolve
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fd00::/8,DIRECT,no-resolve
FINAL,PROXY以上片段只示範部分位址範圍，不是完整的區域網路處理清單。DIRECT 只表示不經代理伺服器傳送，不能保證目標裝置在線、路由存在或存取權限允許。若仍無法存取印表機或本機服務，請檢查裝置位址是否變更、目前網路是否允許裝置間通訊，以及存取所需的系統權限。不要只因規則已命中，就將後續所有錯誤都歸咎於 App。
no-resolve 是選用的比對修飾參數，表示不要為了該條位址比對而主動解析網域。請求本身帶有目標位址時，仍可能命中；若只有網域且沒有適用的位址資訊，則可能繼續檢查後續項目。如果透過網域存取區域網路服務，只靠附有此參數的私有位址規則未必符合預期；可先用精確 DOMAIN 處理已知主機，再視需要保留位址範圍規則。
GEOIP：依位址資料庫判斷區域
GEOIP,CN,DIRECT 表示目標位址依所使用的資料庫歸類為 CN 時，採用 DIRECT。它不是依網域後綴判斷，也不會辨識網頁語言、帳戶地區或服務所有者。中文頁面可能使用不同地區的基礎設施，同一網域也可能因解析條件不同而回傳不同位址。因此 GEOIP 較適合作為範圍較廣的位址分類條件，不應取代明確的業務網域例外。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY位址資料庫的分類結果與實際連線可達性是兩回事。命中某個區域，不代表直連速度理想或連線一定成功；不同網路觀察到的目標位址也可能不同。排查時應一併記錄實際目標 IP、命中項目與錯誤類型。若已知某項服務需要固定策略，優先新增能清楚界定服務範圍的網域項目，不要只因一次結果不如預期就全面替換 GEOIP 規則。
USER-AGENT：只有在請求特徵可見時才有用
USER-AGENT 依可取得的 User-Agent 特徵比對，例如 USER-AGENT,ExampleApp*,DIRECT 使用星號表示相應的萬用字元形式。它不等同於依 App 名稱或程序辨識流量，也不能假設每條加密連線都會揭露這項資訊。一般 HTTPS 連線的標頭位於加密內容中，用戶端不一定能取得。因此，這項規則只能在條件明確時作為補充，不能用來保證某個 App 的所有請求都走相同路徑。
FINAL：為尚未命中的請求指定結果
FINAL 不需要網域或位址參數，格式為 FINAL,PROXY 或 FINAL,DIRECT。應將它放在比對清單末尾，明確指定前面條件都未命中時的處理方式。若放在中間，後續一般規則通常就沒有比對機會。選擇預設策略時，須考量設定用途：PROXY 需要可用的代理；DIRECT 則仰賴本機網路可直接存取。兩者都不保證連線成功。
組合這些規則時，先確認目前請求有哪些可靠資訊。已知網域時，優先表達網域意圖；確實需要比對位址範圍時再使用 CIDR；區域分類放在較廣的範圍，最後以 FINAL 結尾。對於 USER-AGENT 等仰賴請求特徵可見性的規則，也要規劃資訊不可用時的後續處理。如此一來，設定不只說明「命中時如何處理」，也交代「未命中時會如何處理」。
05 / 策略結果
PROXY、DIRECT、REJECT 與 Proxy Group
策略代表處理方式，不等於可連線性的結論
規則中的最後一個主要欄位通常指定處理策略。PROXY 表示透過代理處理，DIRECT 表示直接傳送，REJECT 表示拒絕相應請求。這些名稱說明用戶端應如何處理，不代表目標狀態正常。記錄顯示 PROXY，只能證明請求進入相應路徑；後續仍可能因伺服器驗證、遠端連線或目標服務問題而失敗。顯示 DIRECT 也不代表請求不受系統網路條件影響，仍須視本機網路與目標狀態而定。
| 策略 | 處理方式 | 後續檢查 |
|---|---|---|
PROXY | 採用目前的代理路徑 | 實際選用的伺服器與連線參數 |
DIRECT | 不經代理伺服器傳送 | 本機網路、解析與目標可連線性 |
REJECT | 拒絕符合條件的請求 | 拒絕範圍是否涵蓋必要依賴 |
理解這一點可避免反覆改錯位置。例如已正確命中目標 DOMAIN 並採用 PROXY，卻出現驗證錯誤時，應先檢查既有伺服器資料，而不是把 DOMAIN 改成 DOMAIN-SUFFIX。反過來說，若記錄顯示目標被更前面的 DIRECT 項目接管，即使代理本身可用，也應先修正規則範圍或順序。先確認策略選擇正確，再判斷該策略下的連線是否成功。
PROXY 與自訂群組的關係
PROXY 是內建策略名稱，不是必須手動新增的伺服器名稱。使用自訂 Proxy Group 的設定檔，也可以讓規則引用已定義的群組名稱，將不同目標導向不同的選擇集合。引用前必須確認群組確實存在，且群組成員可由目前設定檔辨識。拼字、空格與名稱都應與定義一致；只在規則末尾填入新名稱，不會自動建立包含伺服器的可用群組。
[Rule]
DOMAIN,api.example.org,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,blocked.example.org,REJECT
FINAL,PROXY上例只使用內建策略，避免依賴未定義的群組。若既有設定使用自訂群組，排查時還要多檢查一層：先確認請求進入哪個群組，再確認該群組最後選用了哪個成員。群組名稱正確但成員不可用，與規則未命中是兩種不同問題。自動選擇類群組也可能因網路條件改變而選用不同成員，因此比較測試時應記錄實際使用的伺服器，而不只是群組顯示名稱。
依目標範圍使用 DIRECT 與 REJECT
DIRECT 常用於明確需要本機網路路徑的請求，例如已知的區域網路主機。不要只因某項服務「看起來是本機的」就大範圍直連，仍應確認實際網域與相關依賴。REJECT 適用於需要明確停止的請求，但範圍過廣的拒絕規則可能影響登入、資源載入或其他基本功能。將拒絕範圍限縮到可說明的主機，再透過記錄驗證，通常比使用意思模糊的關鍵字更容易控制。
目標遭拒絕後，App 的反應不一定相同。有些頁面會立即顯示錯誤，有些 App 會不斷重試，另一些介面則可能一直顯示等待中。這些現象不代表代理伺服器故障。新增 REJECT 後若出現異常，先還原該條規則，再執行相同操作，比較相關請求是否恢復，然後再決定是否縮小範圍。不要在拒絕規則後面新增相同目標的 DIRECT，並期待後者自動覆蓋前者；順序不變時，後者不會有比對機會。
用戶端購買與連線服務分開管理
Shadowrocket 是 Apple 平台的付費用戶端，一次買斷用戶端 ≠ 線路方案。規則中出現 PROXY，不會建立新的伺服器，也不會補上訂閱資訊。既有訂閱請向服務商取得；驗證資訊與到期狀態也由服務商管理。如需確認 App 取得管道，請參閱App Store 正版核對說明；購買 App 與準備連線資料應分開確認，避免將商店付款成功誤認為已完成連線設定。
維護群組與策略時，建議保留簡單且容易說明的基準設定。先用內建策略驗證目標路徑，再加入群組；先測試單一成員，再評估自動選擇行為。發生錯誤時便能逐層回復，不必同時排查規則、群組名稱、成員與連線參數等多項變因。若只是尚未完成首次連線，回到入門指南依主要步驟操作，會比預先建立複雜的策略結構更合適。
06 / 優先順序
由上而下比對，命中第一條即停止
不會自動採用「越具體越優先」
Rule 依檔案中的實際順序逐條檢查。目標一旦符合某項條件，就採用該項指定的策略；後續一般項目不會再重新選擇。DOMAIN 不會自然優先於 DOMAIN-SUFFIX，單一位址規則也不會自然優先於大型網段，REJECT 更不會因語意強烈而自動優先。所謂優先級，首先取決於設定位置。理解這項原則後，多數「規則已設定卻沒效果」的情況，都能從前面已有符合條件的項目找到原因。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY對 api.example.com，第一行已指定 DIRECT；對 www.example.com，第一行不符合，第二行指定 PROXY；其他網域才會繼續檢查 GEOIP，最後由 FINAL 處理。這是一條有明確停止點的判斷流程，不是替所有命中規則評分。即使 www.example.com 解析出的位址符合後面的 GEOIP，也不會因此改用 DIRECT，因為前面的後綴規則已完成策略選擇。
用反例說明順序衝突
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,api.example.com,DIRECT
FINAL,PROXY這個反例中，api.example.com 會先被後綴規則接管，下方的精確規則因此無法實現例外。修正方式是將精確例外移到範圍規則之前，而不是在檔案末尾重複新增相同項目。若有多條相同條件，通常由排在前面的項目決定結果。重複項目會增加閱讀負擔，也可能讓維護者誤以為後續新增的內容已覆蓋舊設定；整理時應檢查重複項目與彼此涵蓋的範圍。
先列局部例外，再列服務範圍，最後處理廣泛分類
一種方便維護的排列方式是：先列明確的允許或拒絕例外，再列服務網域範圍，接著處理目標位址與區域，最後放入 FINAL。這不是 App 強制要求的固定範本，而是讓規則意圖更容易閱讀的方式。若服務需求不同，可以調整順序，但每次調整都應能說明為何該項必須排在上一項之前。不要只為了「看起來整齊」就依字母順序排列整個 Rule，否則可能改變原有順序。
例外之間也可能重疊。例如，希望某個主網域使用 PROXY，但其中一個 API 使用 DIRECT，另一個特定主機則需要 REJECT；這兩個精確主機項目都應排在主網域後綴之前。若再加入包含相同字串的 DOMAIN-KEYWORD，必須確認它不會先接管原有例外。檢查時不只要確認單條規則是否正確，也要留意上方是否有更廣的條件，以及下方哪些項目會因此無法命中。
設定更新後重新檢查實際規則清單
遠端設定更新可能改變項目順序、刪除本機修改，或加入新的範圍規則。更新成功只代表內容已取得，不代表原有自訂設定仍然保留。更新後至少檢查重要例外、末尾的 FINAL 與自訂群組引用，再驗證常用目標。若需長期維護個人例外，應採用自己能穩定管理的設定方式，並保留修改說明；不要仰賴每次更新後憑記憶找回所有差異。
排查順序問題時，可先列出某項請求的預期判斷流程：目標名稱是什麼、是否已取得位址、最早可能命中哪條規則，以及預期策略為何。再逐項比對記錄結果。若結果不符，先確認是否選錯檔案、Global Routing 是否設為 Config，以及觀察到的是否為新連線。只有這些基本條件一致後，才需要進一步研究特定關鍵字的比對範圍。
也要兼顧效能與可讀性。將明確網域規則放在需要解析的位址判斷之前，通常能減少不必要的判斷依賴；但不要只為了減少行數，就把多個明確目標合併成範圍過廣的關鍵字。應優先維護可說明、可重現的行為，再清除確實重複的內容。設定檔較短，不代表更容易維護；稍長但職責清楚的設定檔可能更合適。
07 / 解析與改寫
Host 與 URL Rewrite 的職責界線
Host 修改位址對應，不會直接選擇策略
Host 用於明確指定網域對應的位址，例如將 printer.example.com 指向目前網路中的裝置。它處理的是「這個名稱對應哪個位址」，而不是「這個請求應走哪條策略」。因此，Host 與 Rule 可能需要同時設定：前者指定目標位址，後者決定處理方式。若只新增位址對應，卻仍讓請求走不適合存取該區域網路位址的代理路徑，存取仍可能失敗。
[Host]
printer.example.com = 192.168.1.20
[Rule]
DOMAIN,printer.example.com,DIRECT
FINAL,PROXY這段範例分別說明兩項設定意圖：將名稱對應到指定裝置，並讓該名稱的請求採用 DIRECT。實際使用前，請確認裝置位址固定、服務連接埠正確，而且本機網路允許存取。切換網路後，同一個私有位址可能對應不同裝置，也可能完全不存在，因此不宜將區域網路對應視為適用於所有網路的通用設定。遷移裝置或切換環境時，應一併檢查位址對應與規則。
固定位址對應也會取代服務原本仰賴的動態解析結果。公開服務可能透過 DNS 調整連入位址或區域，長期固定某個位址可能在一段時間後失效。HTTPS 存取仍會依請求名稱驗證憑證；指定位址不會讓憑證自動適用於其他名稱。若出現憑證錯誤，不應一味增加 Host 項目；應先確認目標服務與名稱是否確實相符。
URL Rewrite 比對 URL，不是網域路由
URL Rewrite 處理符合運算式的 URL，可用於明確的重新導向改寫。它與 Rule 的逗號分隔語法不同，通常由比對運算式、替換目標與處理方式組成。以下範例將指定主機的 HTTP 網址重新導向 HTTPS，狀態碼為 302。這只是受控示範，不應直接擴大為所有網站都使用的改寫，因為目標不一定支援相同的 HTTPS 路徑或服務。
[URL Rewrite]
^http://example\.com/ https://example.com/ 302運算式開頭的 ^ 限制從 URL 起始位置開始比對；網域中的句點寫成 \.，表示一般句點，而非正規表示式中的任意字元。網域後方的斜線也能明確界定主機範圍。若省略必要限制，原本只想處理 example.com 的運算式可能意外符合其他字串。撰寫時應同時準備應命中與不應命中的 URL，確認範圍沒有超出預期。
保留路徑時，使用明確的擷取關係
[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302這裡以擷取群組保留斜線後的內容，再透過 $1 放入替換目標，以保留後續路徑及符合的查詢部分。這與前面的固定目標範例是兩種替代寫法，不應不加判斷地同時保留。包含登入狀態、簽章或敏感查詢參數的 URL 尤其需要小心；改寫可能導致伺服器驗證失敗，也可能改變原有請求語意。先在自己能驗證的目標上測試，再決定適用範圍。
也要確認是否形成循環。如果原網址跳轉到新網址後，又被另一條規則改回原處，就可能不斷重新導向。避免循環的方法是將比對範圍限縮於舊通訊協定或舊路徑，並確保替換結果不再符合相同條件。除確認最後頁面能否開啟外，除錯時也應逐次查看實際跳轉目標；快取中的舊跳轉可能干擾測試，必要時請以新的請求條件重新驗證。
加密內容的可見性會影響改寫能否生效
一般 HTTPS 連線的完整 URL 路徑位於加密內容中，不能只因已看到網域，就認定用戶端能比對其中任意路徑。處理 HTTPS 內容的功能另有條件，也會影響信任設定；新增一條 URL Rewrite 並不會讓它自動生效。本頁不將變更系統信任設定列為一般分流步驟。若只想讓特定主機使用 PROXY 或 DIRECT，請回到 Rule 使用網域規則，不必加入內容改寫。
維護這兩個段落時，保留的項目應盡量精簡且用途明確。失效的臨時位址對應、範圍過廣的改寫運算式，以及不再需要的重新導向，都會增加排查成本。刪除前先儲存副本，刪除後重新測試受影響的目標。若只是某個頁面無法開啟，應先從請求、解析與策略的證據著手；不要同時新增 Host 與改寫規則，讓問題變成多項變更彼此影響。
08 / 驗證與維護
透過 Logs 定位問題，並以副本還原設定
先建立可重現的觀察條件
開始驗證前，記錄目前網路、Global Routing、正在使用的設定檔，以及實際的代理選擇。接著指定一個目標與一項操作，例如開啟某個頁面或請求某個 API，而不是籠統地說「整個 App 都不能用」。Connectivity Test 可協助觀察連線條件，但單次測試成功不能取代實際服務請求。代理連線能否建立、網域能否解析、目標 API 能否回應，是三項需要分別確認的結果。
測試時盡量維持其他條件不變。不要同時切換網路、更換伺服器，又修改 DNS 與規則，否則即使結果改善，也很難判斷是哪項變更發揮作用。規則儲存後重新發出請求，並留意連線重用與快取；必要時，在能安全結束目前工作流程的前提下重新建立連線。若問題只在特定網路發生，應分別記錄各網路的觀察結果，不要用一次成功取代先前的失敗紀錄。
依「請求、命中、連線」順序查看記錄
Logs 的實際顯示欄位請以 App 內為準。查閱時先找出請求目標，確認是否為本次測試的主機；接著檢查採用的策略與可見的規則資訊；最後查看連線錯誤或回應狀況。如果記錄只有 IP，不要立刻認定網域規則失效，應先確認請求是否提供可用名稱。若已確認命中 REJECT，就先檢查拒絕規則的範圍，而不是繼續調整伺服器連接埠。
| 觀察結果 | 優先檢查 | 暫勿同時修改 |
|---|---|---|
| 沒有對應的新請求 | 測試操作、既有連線、用戶端處理範圍 | 整份規則清單 |
| 命中非預期的策略 | Global Routing、目前設定檔、上方規則 | 伺服器驗證參數 |
| 策略正確，但連線失敗 | 解析、驗證、目標位址與可連線性 | 已驗證無誤的比對範圍 |
| 更新後行為改變 | 設定差異、群組引用、預設處理規則 | 所有網路設定 |
遇到「解析失敗」時，先確認記錄是否取得位址，並檢查 General 與 Host 中的相關設定。遇到「連線逾時」時，進一步判斷是代理路徑無法建立，還是目標服務沒有回應。遇到「驗證失敗」時，檢查既有伺服器資訊是否完整。不同錯誤不應套用同一種萬用修復方式。若無法從單筆記錄判斷，可依時間比對相鄰的解析與連線記錄，但不要將同一時刻的所有背景請求都歸因於本次測試。
縮減為最小設定，再逐項還原
可透過建立副本並縮減設定來排查複雜問題，但縮減時應保留建立連線所需的既有資訊。先移除與目標無關的臨時改寫與位址對應，再用一條精確網域規則和 FINAL 建立明確判斷。若最小副本運作符合預期，再分批還原原有項目，每還原一批就以同一目標重新測試。這樣能找出是哪一批條件改變結果，而不必在完整檔案中不斷新增修補規則。
[Rule]
DOMAIN,api.example.org,DIRECT
FINAL,PROXY這段範例僅用於驗證規則選擇，不應覆蓋尚未備份的完整檔案。預期結果是 api.example.org 命中 DIRECT，其他未命中的請求採用 PROXY。若結果仍不一致，先確認已選用副本、Global Routing 是否設為 Config，以及記錄是否對應新請求。若結果符合預期，但目標仍無法使用，應將排查重點移至連線路徑，而不是繼續擴大規則關鍵字的範圍。
記錄變更並留意隱私範圍
每次修改都保留簡短紀錄：修改目標、涉及項目、預期結果、實際結果與還原方式。匯出設定檔時，檢查是否包含伺服器位址、驗證資訊、私人訂閱連結或敏感的 Host 對應；用於討論時，只提供已去識別化的最小片段。Logs 也可能包含存取目標與查詢資訊，僅保留排查所需內容即可。常見匯入與連線問題可繼續參閱問答集；首次操作請返回入門指南。
更換裝置前，應分別確認 App 取得方式、伺服器資料與設定檔的還原方式。重新從 App Store 取得 App，不代表所有個人設定都一定已還原；系統需求與購買適用範圍請以 App Store 頁面標示為準。設定遷移方式請參閱設定備份與換機還原說明。還原後先核對檔案與憑證，再重新測試重要規則；不要只因檔名相同，就認定內容一致。
維護完成的標準，不是「不再修改」，而是重要目標能依預期命中、未命中的請求有明確的預設處理方式、設定中的每項例外都有清楚用途，且發生問題時能還原至可用副本。將規則選擇與連線結果分開驗證，將遠端內容與個人修改分開管理；日後遇到網路變更或設定更新時，就能沿用相同的觀察流程繼續排查。