Shadowrocket
規則與設定手冊

Global Routing 與規則生效條件

只有當請求進入相應的處理路徑時，規則才會生效。開始編輯前，請先確認 Shadowrocket 已選取可用伺服器、連線開關狀態符合預期，而且 Config 中啟用的是準備修改的設定。檔案出現在清單中，不代表目前正在使用；文字編輯器中有新內容，也不代表執行中的連線已依新內容重新建立。請分別確認「檔案存在」、「檔案已選取」和「請求使用新設定」，以免把生效問題誤判為語法錯誤。

分清 Config、Proxy 與 Direct

Global Routing 中的設定、代理、直連分別對應 Config、Proxy、Direct。Config 依目前設定中的規則決定請求策略，是本頁大部分範例的前提。Proxy 會讓通常透過代理處理的請求走代理路徑；Direct 則走直接連線路徑。兩者適合用來對照路徑，但不應視為仍在逐條測試自訂 Rule。系統略過項目、區域網路例外和既有連線也可能影響觀察結果，因此切換模式後仍須重新發出請求。

分清伺服器、訂閱與規則

伺服器資訊說明連線目的地，以及採用的協定與驗證參數；訂閱是批次維護伺服器資訊的一種輸入方式；規則則決定各項請求採用哪種策略。更新伺服器訂閱不等於同步修改 Rule，匯入設定檔也不代表其中涉及的伺服器已經存在。本文以使用者已有自己的訂閱或伺服器資訊為前提。用戶端一次買斷 ≠ 連線方案；購買 App 與具備可用的連線條件是兩回事。本網站不提供、不販售也不推薦節點或訂閱。

Shadowrocket 是 Apple 平台上的付費閉源商業 App，主要供 iPhone 與 iPad 使用，唯一取得管道為 App Store。取得方式請參閱App Store 正版購買與安裝說明；系統需求與購買適用性以 App Store 頁面標示為準。本頁的設定範例用於說明用戶端行為，不取代商店資訊，也不保證使用者既有伺服器可正常使用。先建立基本連線，再調整分流，較容易釐清故障範圍。

建立可重複的觀察條件

首次測試建議只選一個明確的目標網域，記錄目前的 Global Routing、所選伺服器、設定名稱與網路類型。先使用既有可用設定存取目標，確認目標本身能正常回應，再修改一條規則。不要同時更新訂閱、切換網路、修改 DNS 並調整規則順序；多個變數一起變動時，即使命中結果改變，也無法判斷是哪項設定造成。操作紀錄可保存在本機筆記中；分享時請移除伺服器位址、驗證參數與完整訂閱連結。

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

上例是局部規則片段：對精確網域 example.com 使用 PROXY，其餘未命中的請求使用 DIRECT。這不是通用的分流方案，也不會自動提供代理伺服器。如果目標頁面還會請求其他網域，那些請求可能落入 FINAL，因而出現部分內容載入成功、部分失敗的情況。這不是規則隨機生效，而是頁面包含多個獨立連線。驗證時應逐一核對實際請求的目標，不能只依網址列中的主網域下結論。

.conf 設定檔結構與編輯流程

設定檔以方括號中的區段名稱組織內容。General 放置全域參數，Rule 放置依序檢查的比對規則，Host 設定網域至位址的本機對應，URL Rewrite 則處理符合條件的 URL 改寫或拒絕。區段名稱不是裝飾用標題，而是解析器用來辨識後續各行用途的標記。同一段文字放在錯誤區段中，不會自動依原本意圖執行。編輯前請先確認所在區段，尤其不要把網域對應寫進 Rule，也不要把一般說明文字放進參數區段。

先看整體架構，再看局部範例

[General]
bypass-system = true

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

[Host]
test.example.com = 192.0.2.10

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

這裡的 example.com、example.net 與 test.example.com 僅用來說明語法；192.0.2.10 是文件範例位址，不應預期能連線成功。URL Rewrite 範例會將指定的 HTTP 位址重新導向至 HTTPS，是否適用於實際目標仍取決於該網站是否支援 HTTPS。整段程式碼展示各區段的排列方式，不建議直接用來取代現有設定。實際調整時，只複製需要的行，並確認每一行會影響哪些請求；保留目前檔案中已確認有效的其他設定。

在 Config 中確認目前使用的檔案

進入 Config 後，先查看目前選取的設定，再開啟相應檔案檢查。不同介面狀態可能提供檢視、編輯或其他操作，實際入口請以 App 畫面為準。不要只因檔名相似就認定內容相同；遠端來源儲存的檔案、本機副本與先前匯入的舊檔可能同時存在。建議替工作副本取一個容易辨識的名稱並記錄用途，修改後返回清單確認選取項目未變，再開始驗證請求。

整份取代與局部補充的風險不同。整份取代可能同時變更 DNS、略過設定、規則與改寫行為，適合已了解整份設定時使用；局部補充只新增明確需要的項目，更方便排查。即使採用局部補充，也應找到現有的對應區段，而不是不斷在檔案末尾追加相同區段名稱。不要依賴重複區段的合併或覆寫行為來維護設定。讓各區段職責集中、內容順序清楚，才能減少編輯內容與執行結果之間的歧義。

儲存時檢查字元與區段界線

Rule 中的逗號應使用英文半形字元，參數指派使用等號，方括號也必須成對。中文輸入法可能將逗號、空格或引號替換成外觀相似的字元；從富文字複製內容時，也可能帶入不可見字元。如果某一行看起來正確卻無法正常解析，可在純文字環境中重新輸入該行的區段名稱、分隔符號與關鍵字，再儲存測試。規則中的網域只填主機名稱，不要附加路徑、查詢參數或瀏覽器顯示的完整網址。

較長的設定應依用途排列，並保留簡短註解。可在獨立一行使用井字號說明一組規則的目的，例如寫明為何某個精確例外必須排在後綴規則之前；不要仰賴複雜的行尾註解解釋重要參數，以免複製時混入內容。註解應記錄決策原因，而非重複關鍵字的字面意義。過一段時間回頭檢查時，「測試某目標的直接連線」比「DIRECT 規則」更能協助判斷該行是否仍有必要。

修改後先確認能正常儲存並選取，再重新發起連線測試。儲存成功只代表檔案已寫入，不表示每條規則都會命中；某條內容即使語法正確，也可能一直被前面的規則攔截。建議保留修改前的副本，一次新增一項規則，驗證通過後再繼續。需要進一步了解各區段，可閱讀General、Rule、Host 與 URL Rewrite 區段說明，並對照本頁的優先順序章節。

General、DNS 與系統略過設定的範圍

General 中的參數會影響整體處理環境，不像 Rule 一樣逐項決定個別網域的策略。因此，請求未出現在預期的規則紀錄中時，不要只在 Rule 裡不斷新增更寬泛的比對條件。應先確認請求是否進入用戶端處理流程、系統略過設定是否介入、目標資訊是否可見，以及網域是否成功解析為 IP。釐清這些前置條件後再決定是否新增規則，通常比直接取代整份設定更容易找到問題。

bypass-system 的作用與限制

[General]
bypass-system = true

bypass-system 用於控制是否略過部分系統相關流量。它不等同於「所有本機位址都直接連線」，也不是讓網站成功開啟的通用開關。系統相關請求的處理可能早於一般規則的比對，因此啟用此參數後，不應預期能在 Rule 中找到所有流量的命中紀錄。如果現有設定使用這個選項，應先了解保留它的原因；不要為了讓紀錄看起來完整就直接關閉，也不要把它當成能改變所有 App 行為的保證。

排查略過設定時，先分清目標是公網服務、區域網路裝置還是系統元件。公網網域通常可透過精確 DOMAIN 規則觀察；區域網路裝置則可能同時受位址範圍、網路環境與系統行為影響。先記下存取位址與目前使用的 Wi-Fi 或行動網路，再進行一次有限度的修改。如果只有某個區域網路目標發生問題，應針對該目標驗證，不要藉由調整整體系統略過設定來掩蓋位址、連接埠或區域網路隔離問題。

解析結果與連線策略是兩回事

網域規則判斷目標名稱，IP 規則判斷目標位址；兩者之間通常會經過解析程序。DNS 成功回傳位址，不代表該位址一定可達；選取 PROXY，也不表示解析程序必然採用與代理完全相同的路徑。查看設定時，應分別確認 DNS 相關設定、是否已有快取，以及請求紀錄中實際使用的目標。只因解析位址改變就認定網域規則未生效，會混淆解析層與路由層。

同一網域可能回傳多個 IPv4 或 IPv6 位址，位址也可能隨網路與時間改變。如果規則只涵蓋某個 IPv4 位址，下次解析選到 IPv6 時，可能就會採用不同策略。這時應先確認是否該用網域規則表達需求，而不是把每次看到的位址都加進清單。只有在確實要控制固定網段或明確位址時，才使用 IP-CIDR 或 IP-CIDR6。規則的比對對象應符合實際需求，維護時才不會依賴偶然的解析結果。

no-resolve 是規則選項，不是 DNS 開關

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

no-resolve 通常用於 IP 類規則，表示不會只為了檢查這條規則而額外觸發網域解析。這不代表整個用戶端停止 DNS，也不保證之後的連線不需要解析。如果目前已有可供比對的目標 IP，規則仍可能命中；如果只有網域名稱而沒有適用的位址，這條規則可能無法據此判斷，請求便會繼續往下比對。若將它理解為「禁止任何解析」或「讓所有網域自動依位址比對」，都會產生錯誤預期。

如果某個目標只有在移除 no-resolve 後才改變行為，應確認變化是否來自新增的解析程序，而不是直接判定這個選項好或不好。記錄解析前後取得的位址、命中的規則與最終策略，再決定是否保留該行為。尤其同時存在網域規則與 GEOIP 規則時，前面的網域規則可能已結束比對，後面的解析選項根本沒有參與。驗證選項前，必須先確認執行流程確實到達該條規則。

處理 DNS 問題時，先以已知可存取的目標作為對照，再確認問題是否只影響單一網域、是否只在特定網路發生，以及是否伴隨 IPv6 路徑變化。每次只調整一項明確參數，測試後保留結果。不要隨意用網路上的整段 General 取代目前設定；其中的解析、略過設定與其他全域選項可能互相影響。如需先恢復基本連線，可參閱FAQ 的連線問題排查說明，分別檢查解析與連線兩個層次。

DOMAIN、後綴、關鍵字與 USER-AGENT

選擇網域規則時，應依要控制的範圍決定，不要一律使用最寬泛的寫法。DOMAIN 適用於精確主機名稱，DOMAIN-SUFFIX 適用於網域及其子網域，DOMAIN-KEYWORD 則用來搜尋網域中的指定字串。這三種規則都不會比對完整 URL：路徑、查詢參數、頁面標題與瀏覽器顯示的文字，都不在比對範圍內。先確認目標主機，再選擇涵蓋範圍最小的規則，可減少誤比對與難以解釋的存取變化。

精確比對與後綴比對

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

DOMAIN,api.example.com,DIRECT 只會精確比對這個主機名稱，不會自動涵蓋 www.example.com，也不包含 api.example.com 之下的其他子網域。DOMAIN-SUFFIX,example.com,PROXY 則適用於 example.com 及其子網域。上例中，api.example.com 先命中精確規則，因此使用 DIRECT；其他屬於 example.com 範圍的主機則由後綴規則處理。如果把後綴規則移到前面，精確例外就沒有機會執行，這正是規則順序重要的原因。

後綴比對有網域邊界的意義，不應視為任意字串搜尋。要涵蓋 example.com 時，請將該網域作為後綴，不要在開頭加上瀏覽器網址中的通訊協定，也不要在結尾加上斜線。DOMAIN-SUFFIX,example.com 不會比對所有包含「example.com」字元的任意名稱；若需求確實是比對字串是否包含指定內容，應明確使用 DOMAIN-KEYWORD，並另外確認涵蓋範圍是否過廣。

使用關鍵字規則前，先評估誤命中風險

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

DOMAIN-KEYWORD,example,PROXY 會檢查網域是否包含 example 字串，涵蓋範圍比 example.com 的後綴規則更廣。它可能同時涵蓋不同後綴、不同擁有者的網域，因此不適合只為了少寫幾行，就取代一組已知的精確網域。如果需求是完整使用某個網站的功能，請先從實際請求紀錄找出必要主機，逐一確認用途，再決定是否以後綴規則合併。過寬的規則通常不會造成語法錯誤，而是悄悄改變無關請求的策略。

USER-AGENT 的可見性限制

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

USER-AGENT 會依照可取得的 User-Agent 內容進行比對；上例中的 ExampleClient 是用來說明萬用字元模式的範例值。這不是依 App 名稱選擇流量，也不會自動辨識裝置上的所有 App。加密請求中的 HTTP 標頭通常無法只靠一般連線資訊直接讀取，因此這類規則是否適用，取決於請求類型與可取得的資訊。不要因為某個 App 的網頁請求曾命中，就推斷該 App 的所有連線都會以相同方式處理；更不要為了提高命中率而任意擴大解密範圍。

驗證網域規則時，應一併查看重新導向後的目標與頁面所依賴的網域。開啟頁面時可能先連到主網域，再轉往登入網域，接著請求圖片、介面與靜態資源；這些連線各自比對。如果只有登入失敗，應優先檢查登入流程實際使用的主機，而不是反覆修改首頁規則。如果請求紀錄只顯示 IP，也應先確認能否取得網域資訊，不要強行認定某條 DOMAIN 規則失效。

建議先用精確規則建立一組可驗證的最小清單，再依實際觀察合併為後綴規則。每新增一項，至少檢查目標是否可存取，並選一個無關目標作對照，確認既解決預期請求，又沒有擴大影響。刪除舊規則前，先記錄原本的命中位置，避免連同依賴它的例外一起移除。經常變動的服務網域仍應依實際請求維護，不要根據名稱相似就推測彼此相關；名稱相近不代表應採用相同策略。

IP-CIDR、IP-CIDR6 與 GEOIP

IP 類規則用來判斷目標位址，不負責辨識網站營運者，也不保證位址所對應的服務性質。IP-CIDR 處理 IPv4 網段，IP-CIDR6 處理 IPv6 網段，GEOIP 則依位址資料庫進行地區分類。這些規則適合表達明確的位址範圍，或作為網域規則之後的補充條件。如果需求原本是「某個網域採用某種策略」，通常用網域規則更直接；若把目前解析到的一兩個 IP 當成網站永久位址，規則很快就可能失效。

了解 CIDR 的前綴長度

[Rule]
IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR6,2001:db8::10/128,DIRECT,no-resolve
FINAL,PROXY

IPv4 的 /32 代表單一位址，/16 代表依前 16 位元決定的位址範圍；IPv6 的 /128 代表單一位址。前綴長度越短，通常涵蓋的位址越多。範例中的 192.0.2.10 與 2001:db8::10 屬於文件專用範例範圍，不是可用的目標。實際填寫時，應確認位址與前綴合起來代表的範圍，不要只看前半段是否像目標位址。錯誤的寬廣網段可能影響大量無關連線，而且不會因涵蓋範圍過大而自動提示。

設定區域網路規則時，也應先確認目前使用的實際網段。192.168.0.0/16 只是常見私有位址範圍的一部分，不代表所有區域網路位址；IPv6 本機位址範圍也有不同用途。如果裝置無法存取，除了用戶端策略，還應檢查 Wi-Fi 是否允許裝置互相連線、目標服務連接埠是否開放，以及目標是否只監聽特定介面。DIRECT 只會選擇直接連線路徑，不能取代區域網路授權，也無法讓原本不存在的服務開始回應。

GEOIP 是位址分類，不是網域標籤

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

GEOIP,CN,DIRECT 表示將資料庫分類為 CN 的目標位址交給 DIRECT。這不等於依網域後綴判斷，也不等於依頁面語言判斷。某個網域可能使用分布在多個地區的服務位址，資料庫也可能更新延遲，因此不能根據組織所在地推斷每次連線都會命中相同的 GEOIP 條件。如果某項服務必須採用固定策略，應在 GEOIP 之前加入明確的網域規則，避免依賴位址分類的間接結果。

判斷 GEOIP 與解析的關係時，須結合目前請求資訊。目標只有網域名稱時，位址判斷可能需要可用的解析結果；App 直接連到 IP 時，則可能已有可供比對的對象。替 IP 類規則加上 no-resolve 後，行為可能改變，因為該規則不再為了自身判斷額外觸發解析。請同時記錄目標名稱、目標位址與命中規則，不能只看最終策略就判定 GEOIP 資料庫是否正確。如果前面的網域規則已命中，GEOIP 根本不會參與。

分別為 IPv4 與 IPv6 設計驗證

同一服務可能同時提供 IPv4 與 IPv6 位址，App 和系統會依網路條件選擇其中一種。只設定 IP-CIDR 不會自然涵蓋相應的 IPv6 目標；只測試一次成功，也無法證明另一種位址家族的行為相同。排查「切換網路後策略改變」時，應查看實際連線使用的位址家族，再確認是否有相應的 IP-CIDR6 項目。不要把停用某種位址家族當成通用解法，先確認故障是出在規則涵蓋範圍還是網路路徑。

也要留意共用位址與動態解析。多個網域可能共用同一位址，針對該位址設定規則會一併影響它們；某個網域也可能頻繁更換位址，導致舊規則不再命中。如果只想控制單一網站，網域條件通常更能清楚界定範圍。只有在確定能接受共用位址的影響，或目標確實以 IP 位址存取時，才以位址規則作為主要依據。維護時記錄網段來源與用途，避免長期保留已失去依據的項目。

建議依序檢查：先確認實際目標位址，再計算規則涵蓋範圍，接著檢查 no-resolve 與前置規則，最後觀察連線結果。如果規則命中正確但仍無法存取，應繼續排查目標可達性、連接埠與所選路徑，而不是盲目擴大網段。IP 規則解決的是分類問題，不是連線本身。若要恢復穩定狀態，請移除最近新增的位址規則，並用原有網域規則作對照；這比一次清空所有設定更容易釐清原因。

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

Rule 通常依照由上而下的順序檢查；一旦命中並取得相應策略，就不會繼續比對後面的普通規則。關鍵字的「精確程度」不會自動提高優先順序：排在後面的 DOMAIN 不會因為比 DOMAIN-SUFFIX 更精確，就越過已命中的前一行。維護時應先排列明確例外，再放較大的涵蓋範圍，最後放 FINAL。所謂優先順序，首先取決於檔案中的排列，而不是網域長度、關鍵字名稱或編輯時間。

三種策略的用途

PROXY 會將命中的請求交由代理路徑處理，通常需要目前選取的有效伺服器，或設定中明確引用的相應策略。DIRECT 使用直接連線路徑，仍取決於本機網路和目標是否可達。REJECT 用來拒絕命中的請求，不會將請求轉交給其他備用路徑，也不負責以其他內容取代網頁。三者代表處理結果，不是服務品質等級；將失敗請求改為 PROXY 或 DIRECT，只會改變路徑，無法自動修復驗證資訊、目標服務或協定參數問題。

用一個例外說明規則順序

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

上例先處理登入主機與 metrics 主機，再處理其餘 example.com 範圍，接著檢查 GEOIP，最後由 FINAL 作為預設處理。如果把 DOMAIN-SUFFIX 移到最前面，兩個精確主機都會先命中後綴規則，DIRECT 與 REJECT 就不會生效。閱讀長設定檔時，應從目標請求回頭檢查所有可能涵蓋它的條件，而不只是搜尋自己剛加入的那一行。看到規則存在，只能證明文字中有這一行，不能證明執行流程會到達它。

FINAL 的位置決定預設範圍

FINAL 不包含網域或位址條件，寫法是 FINAL,策略。它用來處理之前都未命中的請求，因此通常放在 Rule 區段末尾。如果在中間放置 FINAL，後面的普通規則可能無法執行；如果放置多個 FINAL，後面的預設規則也無法如預期發揮作用。選擇 FINAL,PROXY 或 FINAL,DIRECT，應依目前需求與可用路徑決定，不要認為其中一種才是唯一正確答案。範例中的選擇僅用來說明結構，不能取代對實際服務的判斷。

使用 REJECT 時更要謹慎控制範圍。看起來像統計用途的網域，也可能負責設定、登入狀態或其他必要請求；只憑名稱猜測後予以拒絕，可能導致頁面載入不完整或 App 間歇性失敗。新增拒絕規則前，先確認命中對象與影響範圍，並準備好復原方式。驗證時不只要確認目標請求遭拒，也要檢查正常功能是否受影響。如果功能異常，應先移除最近新增的 REJECT 項目再觀察，不要用更多例外掩蓋最初的誤判。

分清策略名稱與實際連線目的地

本頁使用 PROXY、DIRECT、REJECT 這些基本策略關鍵字，方便直接理解。如果現有設定還使用自訂策略名稱，應確認對應定義確實存在，並檢查其最終指向的伺服器或選擇方式。名稱看起來像某個地區或用途，不代表實際目的地就是如此。伺服器遭刪除、訂閱更新後項目有所變動，或目前選項與預期不同，都可能讓同一條規則產生不同的連線結果。請先核對策略引用，再檢查伺服器，不要只依顯示名稱推斷。

調整順序時，建議依「精確例外、後綴範圍、位址補充、最終預設」排列，再用至少三個目標驗證：一個應命中例外、一個應命中較大範圍，另一個應落入 FINAL。這樣能同時找出例外遭遮蔽或預設規則放得太前面的問題。若要比較兩份設定，不必先比對行數，應比較相同目標在兩份檔案中遇到的第一條有效規則。規則較長不代表更精確；每條規則都有明確目的，才方便長期維護與復原。

Host 與 URL Rewrite 的職責範圍

Host 會改變網域解析使用的位址對應，Rule 決定請求採用的策略，URL Rewrite 則處理符合條件的 URL。三者位於不同層次，不應互相取代。將網域對應至某個位址，不等於讓它採用 DIRECT；將 HTTP 位址重新導向 HTTPS，也不等於讓目標採用 PROXY。排查時應沿著「目標名稱、解析位址、規則策略、請求處理」逐層檢查，避免其中一層變更後，卻錯改另一層的設定。

Host 對應只處理名稱與位址

[Host]
test.example.com = 192.0.2.10

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

範例將 test.example.com 對應至文件範例位址，並另外使用 DOMAIN 規則選擇 DIRECT。兩行的職責不同，不能省略其中一行，卻仍期待行為完全相同。實際使用時，應將位址替換為自己明確管理或已確認有效的目標，並確認該服務能接受這個網域。Host 不是讓任意網域指向任意位址後就能正常存取的工具；伺服器是否正在監聽、網站如何辨識網域、憑證是否相符，仍由目標服務決定。

HTTPS 特別需要留意憑證與主機名稱的關係。即使解析位址已依預期變更，用戶端仍會根據請求中的網域進行相關驗證；對應設定不會讓憑證自動相符。如果出現憑證錯誤，不應透過關閉驗證來掩蓋問題，而應確認目標位址是否正確、服務是否提供對應網域，以及是否受到網路驗證頁面等因素干擾。即使直接存取 IP 能取得內容，也不能因此判定使用原網域的 HTTPS 請求一定成功。

設定 URL Rewrite 前，先確認可觀察的對象

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

上例使用正規表示式比對以 http://example.com/ 開頭的 URL，再以 302 方式重新導向至 HTTPS。開頭的插入符用來限定起始位置，網域中的句點則以反斜線跳脫，避免被正規表示式解讀成任意字元。目標網站必須實際支援 HTTPS，否則重新導向只是把請求送往另一個仍無法使用的位址。此範例用於展示語法，不代表所有網站都應如此改寫，也不表示一般情況下都能檢視加密流量的內部路徑。

URL Rewrite 可使用的輸入取決於用戶端能取得哪些請求資訊。一般加密連線中，完整路徑與請求標頭不會自然地提供給所有規則使用。不要把能比對明文 HTTP 的範例直接套用到任何 HTTPS 請求，再據此判定設定無效。若要進行更深入的請求處理，必須了解額外條件與安全影響；基本分流不需要啟用這些功能。若只是想改變某個網域的連線路徑，通常使用 Rule 中的網域條件更合適。

正規表示式範圍與重新導向迴圈

正規表示式比網域後綴比對更有彈性，也更容易設定得過於寬泛。缺少起點限制、未跳脫的句點，以及跨越網域邊界的萬用字元，都可能讓無關 URL 受到處理。建議先限定通訊協定與明確主機，再考慮路徑範圍；每次擴大範圍，都用一個應比對和一個不應比對的請求作對照。如果不確定表示式的含義，先使用精確範例，不要把看不懂的長表示式加入現有設定，也不要只根據複製來源的說明推斷實際涵蓋範圍。

重新導向後，網站也可能再次重新導向。如果本機規則將一個位址改至目標位址，而網站又把請求送回原處，就會形成迴圈，表現為頁面反覆跳轉或瀏覽器提示重新導向次數過多。此時應暫時移除相關改寫，觀察網站原本的行為，再判斷是否需要縮小規則範圍或直接取消。不要不斷新增重新導向來壓制舊迴圈；先釐清每一步的來源與目標，才能找出問題發生在哪一跳。

維護 Host 與 URL Rewrite 時，最好分開測試：先恢復正常解析並停用改寫，確認基本連線；接著只啟用一條對應設定，最後再驗證一條改寫。移除 Host 後要重新發出請求，並考慮既有快取；停用改寫後，也應避免沿用瀏覽器已記錄的跳轉結果。每次記錄實際目標與第一條命中規則，才能確認變化來自哪個層次。若對規則分流沒有必要，就應精簡對應或改寫設定，減少隱藏依賴與後續排查成本。

設定驗證、常見誤判與復原流程

驗證設定應分成「檔案、命中、連線、服務」四個層次。檔案層確認選取項目與語法；命中層確認請求是否符合預期規則；連線層確認所選路徑能否建立通訊；服務層確認登入、介面與頁面內容是否完整。前一層成功不代表後一層必然成功。例如 DOMAIN 如預期命中 PROXY，但伺服器驗證失敗，問題仍在連線層；網頁主文件可存取但介面請求失敗，則須繼續檢查其他請求，不能只看瀏覽器是否開啟頁面。

用最小測試組確認規則

準備一個應命中精確例外的網域、一個應命中後綴範圍的網域，以及一個應落入 FINAL 的對照網域。儲存設定後，確認 Global Routing 為 Config，重新發出目標請求，再查看 App 提供的連線或請求紀錄。介面顯示哪些欄位，請以實際情況為準；重點是記錄可取得的目標、策略、伺服器與錯誤資訊。如果紀錄未顯示所有細節，應承認觀察上的限制，而不是把缺少欄位當成規則未執行的證據。

測試時盡量建立新連線。已建立的長連線、頁面快取與 App 背景工作階段，可能沿用舊狀態，讓剛修改的規則看起來沒有生效。可先停止相關 App 中的活動請求，再視需要重新建立連線，同時保持其他設定不變。不要因為一次測試結果沒有變化，就立刻重新排列所有規則；先確認確實發出了新請求，並檢查目標是否經過重新導向。維持可重複的測試條件，比頻繁切換開關更有助於判斷。

依症狀縮小排查範圍

如果所有目標都無法使用，請先檢查連線開關、系統 VPN 設定狀態、目前伺服器與基本網路，不要從單一網域規則開始排查。Connectivity Test 可協助了解受測連線的狀況，但一次測試成功不代表所有服務、協定或目標都能正常運作。首次連線的操作步驟請參閱預設伺服器選擇與 Connectivity Test 驗證。如果只有一個網站異常，再依其實際請求與規則命中情況繼續排查。

如果只有某條規則看起來沒有生效，先檢查上方是否有涵蓋範圍更廣的 DOMAIN-SUFFIX、DOMAIN-KEYWORD、位址規則，或更早出現的 FINAL。接著檢查關鍵字、半形逗號、目標名稱與策略引用。如果命中正確但結果不符，應分開處理「規則選擇正確」與「連線能否成功」這兩個問題。不要為了修復連線失敗而不斷新增同義規則；多條規則指向同一條失敗路徑，只會讓設定更複雜，不會改變根本原因。

確保復原後能回到明確狀態

開始修改前，先保留目前可用檔案的副本，並記錄目前選取的伺服器與 Global Routing。發現異常後，先撤回最近一次修改；若變更範圍太大，就切換至已確認可用的設定，再以相同目標測試。復原後仍然失敗，表示問題可能不只來自規則，例如網路條件已改變、伺服器資訊已失效，或目標服務本身異常。此時應繼續從連線層排查，而不是認定備份檔也遭到修改。

從遠端來源更新設定前，先確認本機修改是否會被覆蓋。將自己的精確例外與修改原因另外記錄，更新後逐項核對，不要假設新檔一定保留舊內容。更新訂閱與更新設定也應分開進行，並分別驗證伺服器清單與規則結果。若要了解匯入方式，可參閱Subscribe、Add Server、掃描 QR Code 與從剪貼簿匯入說明，避免把連線資訊匯入問題誤認為 Rule 解析問題。

最後整理一份可供分享的精簡問題描述：裝置目前的網路類型、Global Routing 模式、發生問題的公開目標、預期策略、實際觀察結果，以及少量相關規則。請刪除密碼、完整訂閱連結、驗證欄位與個人存取紀錄；說明順序問題不需要公開整份設定。仍有疑問時，可依照FAQ逐項核對；尚未完成基本流程則返回教學。可靠的設定應讓每條規則目的明確、結果可驗證，發生問題時也能準確復原。