Shadowrocket 規則與設定參考

一、設定檔結構與編輯範圍

先確認目前啟用的是哪一份設定，再修改欄位。Shadowrocket 可儲存多份設定檔，檔案出現在 Config 列表中，不代表連線目前正使用該檔案。進入 Config 確認目前選取的項目，記下檔名與來源，再開啟對應檔案檢查內容。若畫面上的規則與預期不同，應先排除選錯檔案的可能，而非繼續新增相似規則。使用遠端來源的檔案時，也要分清本機修改與重新更新後的內容。

區段名稱決定欄位的解讀方式

設定文字依方括號中的區段名稱分區。[General] 放置影響整體行為的選項，[Rule] 放置依序判斷的分流條件，[Host] 放置指定主機名稱的位址對應，[URL Rewrite] 放置 URL 改寫項目。同一行文字放在不同區段，意思可能不同；把網域規則誤貼到 General 下，不會因文字看起來正確就自動成為規則。檢查結構時，應從區段名稱一路讀到下一個區段名稱。

[General]
bypass-system = true

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

[Host]
example.com = 192.0.2.10

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

上方文字僅示範四個區段如何銜接，並非建議整份啟用。Host 中的位址是文件範例位址，URL Rewrite 也只示範明確的 HTTP 位址轉址。設定中的換行用來區隔項目，英文逗號用來分隔規則欄位，等號則用來連接部分設定的名稱與值。全形標點、複製時混入的不可見字元及錯誤的區段名稱，都應在測試連線前先排除，以免把文字錯誤誤認為網路故障。

本機副本與遠端更新

開始編輯前，先儲存一份可還原的副本。若使用遠端設定，先弄清楚更新會替換哪些內容；直接在來源檔案加入個人規則，之後重新整理可能會再次載入來源內容。較穩妥的做法是保留來源檔案作為參照，在明確的本機副本中測試，並記錄每次修改的目的。不要同時替換 General、重新排列 Rule、加入 Host，再只憑一次連線結果判斷所有修改是否正確。

Subscribe 與設定檔也應分開理解。既有訂閱通常用來維護伺服器項目，設定檔則描述如何處理連線；兩者可能在使用流程中彼此關聯，但更新其中一方，不代表另一方也已變更。若伺服器列表已更新、規則卻沒有變動，應回到 Config 查看實際使用的檔案，而不是反覆重新整理 Subscribe。反過來說，修改網域策略也不會自動補上伺服器位址、連接埠或驗證欄位。

小幅修改，建立可驗證的結果

每次只調整一個明確目標，例如將一個測試網域改為 DIRECT，或縮小一條範圍過廣的 REJECT 條件。修改前先記下預期命中的規則、預期採用的策略，以及查看新連線的方法。儲存並確認設定後，重新建立相關連線，觀察結果是否符合預期。舊連線可能沿用原本的處理路徑，因此不要只重新整理已開啟的頁面，就認定新規則已接管所有請求。

分享設定前，請移除個人連線資訊、訂閱網址與身分憑證。規則範例可以保留測試網域，故障描述也可以保留必要的欄位名稱，但完整設定檔往往包含遠多於問題本身的資訊。需要他人協助時，優先提供相關區段、規則的相對順序與去識別化後的連線記錄。這樣有助於重現問題，也能避免討論受到大量無關項目干擾，特別適合用來找出某個網域被錯誤分流的原因。

二、General：全域選項與 DNS 前提

General 影響設定的整體行為，不負責為個別網域選擇策略。查閱此區段時，應先看欄位名稱，再看值的類型，最後確認它是否與目前排查的問題有關。例如，網域解析失敗時要檢查 DNS 路徑；某個網域錯誤地使用 DIRECT，通常應先檢查 Rule 與目前的 Global Routing。把所有問題都歸因於 General，容易引入更多變數，也會掩蓋原本明確的規則順序問題。

依欄位類型填寫名稱與值

General 常見的寫法是欄位名稱、等號和值。布林選項使用 true 或 false，位址類選項則依該欄位允許的格式填寫。不要直接把中文說明寫成值，也不要因為看到別人的設定包含某個選項，就認定它適合目前的網路。若不確定欄位用途，先在 App 內的設定編輯說明確認其意義與可用值；保留原值通常比憑欄位名稱猜測更容易得到可解釋的結果。

[General]
bypass-system = true
dns-server = system

bypass-system 用來控制系統相關流量的略過行為，不等於「所有連線都直接存取」，也不能取代 Global Routing 的 Direct。變更此項時，應留意受影響的是系統流量路徑，而不是假設所有業務請求都會有相同變化。排查一般網頁存取時，若問題與系統服務無關，可以先保留原設定，避免為了修復一個網域而擴大調整範圍。

DNS 解析與規則判斷並非同一個步驟

dns-server = system 表示使用系統 DNS 路徑；自訂解析位址則須依目前網路的可達性與設定說明確認。規則需要可供判斷的請求資訊：有些條件使用網域，有些條件使用目標 IP。DNS 負責將網域解析為位址，Rule 負責選擇處理策略；兩者會互相影響，但不能彼此取代。新增 PROXY 規則，不代表無法連線的解析端點就會因此恢復。

使用 DNS over HTTPS 時，也要區分解析請求的傳輸方式與最終網站連線的策略。解析請求透過 HTTPS 傳輸，不代表之後所有網站流量都使用相同策略；網站是否走 PROXY，仍取決於目前模式與命中的規則。若解析端點本身也需要先解析主機名稱，還應考慮其初始解析路徑。不要一次填入許多不同來源的位址，再只憑某次成功存取就認定每個位址都正常運作。

從可供比對的基本設定開始

調整 DNS 前，先保留可還原的原設定，選擇一個能穩定重現問題的測試網域，並記錄當時的網路類型。在同一網路、同一伺服器與同一規則下，只變更解析設定，觀察解析結果與連線記錄是否有變化。若同時切換行動網路、伺服器與 DNS，就無法判斷是哪個項目造成差異。切換網路後也可能受到快取影響，因此驗證時應建立新請求，不要只查看舊分頁。

延遲測試有數值但網頁無法開啟，只能表示某種測試請求收到回應，不能直接證明網域解析、目標連線與頁面所有資源都正常。網頁可能同時請求多個主機名稱，其中一個解析失敗就足以影響顯示。應先找出實際失敗的網域，再確認它是否取得位址、使用何種策略，以及連線在哪個步驟中斷。遇到這種情況，可接著閱讀DNS 解析失敗的排查順序。

若 App 內顯示的欄位與範例不同，請以 App 內的說明為準，不要勉強加入未知選項。General 不適合靠大量複製來「補齊」，精簡且能清楚說明用途的設定更容易維護。每個保留欄位都應能回答三個問題：它會改變什麼行為、為何需要變更，以及如何還原。更完整的解析方式討論請參閱系統 DNS、自訂 DNS 與 DNS over HTTPS；本頁則著重於分流判斷所需的前提。

三、網域規則與 USER-AGENT 條件

網域規則適合描述「某個主機名稱或一組相關主機名稱應採用哪種策略」。基本規則由類型、比對值與策略組成，欄位之間以英文逗號分隔。比對值通常填寫主機名稱，不是完整網頁網址，因此不包含通訊協定、連接埠或路徑。若需求是讓某個網站的特定頁面採用不同策略，首先要確認網域規則是否有足夠資訊；它無法只靠路徑區分同一主機上的不同頁面。

DOMAIN 與 DOMAIN-SUFFIX 的比對範圍

DOMAIN 用來精確比對主機名稱，適合單獨處理明確的目標。DOMAIN-SUFFIX 用來比對指定網域及其子網域，適合將同一網域體系下的請求一併處理。後者並非任意比對字串結尾，判斷時會考慮網域邊界；不要以為只要字元結尾相同就會命中。選擇類型前，先列出預計涵蓋的主機名稱，有助於確認規則範圍是否過廣。

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

這組規則中，api.example.com 先命中 DOMAIN，採用 DIRECT；www.example.com 未命中第一行，接著命中 DOMAIN-SUFFIX，採用 PROXY。若將前兩行對調，精確網域也會先被後綴規則攔截。這不是精確比對類型失效，而是比對已在前一行結束。若要保留例外，應將範圍較窄的條件放在範圍較廣的條件前，而不是期待類型名稱自動決定優先順序。

DOMAIN-KEYWORD 的命中範圍

DOMAIN-KEYWORD 會檢查網域中是否包含指定關鍵字，適用範圍不限於單一組織或網域體系。關鍵字越短，意外涵蓋其他項目的可能性越高。只有確實需要字串條件時才適合使用，不應以常見詞彙取代一長串已明確列出的網域。設為 REJECT 時尤其要謹慎，因為誤命中的正常請求也會遭到攔截，之後可能出現圖片未載入、登入失敗或頁面持續等待等情形。

[Rule]
DOMAIN,downloads.example.com,PROXY
DOMAIN-KEYWORD,ads,REJECT
FINAL,PROXY

範例先為明確的主機名稱設定例外，再進行關鍵字攔截。downloads.example.com 也包含 ads 這幾個字元，因此例外所在的位置會直接影響結果。實際排查時，不能只憑「這是不是廣告網域」的主觀判斷，應核對實際參與比對的主機名稱與規則文字。若命中範圍超出預期，優先改用 DOMAIN 或 DOMAIN-SUFFIX，而非不斷增加例外來補救範圍過廣的條件。

USER-AGENT 的適用限制

USER-AGENT 依據請求中可取得的 User-Agent 欄位進行比對，條件值可依支援的萬用字元格式填寫。它不是 App 身分識別，也無法可靠代表特定處理程序。請求可能不包含此欄位，不同 App 也可能使用相近的欄位值；對於無法查看欄位內容的加密流量，更不能期待規則讀取到它。因此，需要長期穩定分流時，通常應優先考慮明確的網域或目標位址，再評估此條件是否適用。

[Rule]
USER-AGENT,ExampleClient*,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

表格中的 ExampleClient 只是範例欄位前綴，不代表任何實際 App。驗證 USER-AGENT 規則時，應先確認請求確實帶有此欄位，而且 App 能夠取得它；不要只為了命中一條規則，就直接加入額外的流量解密設定。加密流量的可見性應與一般網域分流分開評估。若無法確認欄位內容，使用可觀察的網域規則更容易建立明確的測試條件與還原方式。

四、IP-CIDR、IP-CIDR6 與 GEOIP

IP 類規則比對的是目標位址，而非網站文字名稱。單一網域可能解析到多個位址，同一個位址也可能承載多個網域，因此位址條件與網域條件並不相同。若需求是穩定指定某個網站的策略，應先判斷網域規則是否更合適；若要處理明確的內部網路網段、單一目標位址或位址歸屬範圍，再使用 IP 條件。選擇依據應是實際需要表達的範圍，而不是哪種寫法比較短。

以前綴長度表示位址範圍

IP-CIDR 用於 IPv4 位址範圍，斜線後的數字代表網路前綴長度，不是連接埠，也不是可用位址數量。例如 192.168.0.0/16 表示一個私有位址範圍，192.0.2.10/32 表示單一 IPv4 位址。填寫時應使用明確的網路位址與前綴，避免直接把裝置目前取得的位址當成整個網段。網段邊界填錯，規則可能涵蓋遠超預期的目標。

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

IP-CIDR6 對應 IPv6 位址範圍。範例中的 2001:db8::/32 是文件專用範圍，不代表實際網路。若目標同時提供 IPv4 與 IPv6，只設定 IPv4 條件並不代表另一種連線也會受到相同處理。查看連線記錄時，應確認目標位址類型；同一網頁出現不同結果，可能是因為選用了不同位址，不一定是規則執行順序隨機變動。

no-resolve 不等於關閉 DNS

no-resolve 是部分位址規則可加入的選項，用來避免為判斷這條規則而主動觸發網域解析。它不代表整份設定停止解析，也不表示目標永遠沒有位址。如果請求本身使用 IP，或判斷時已有可用位址，仍可依位址條件進行比對。對內網位址規則而言，此選項常用來減少為判斷網段而額外解析的情況，但是否加入仍應視實際比對目標而定。

若沒有可用 IP，附帶 no-resolve 的規則便無法只憑網域文字判斷目標屬於哪個網段。反過來說，不含此選項的位址條件可能涉及解析，使 DNS 路徑也參與判斷。若將許多位址規則排在網域規則前，解析行為也會更難解釋。若要讓處理路徑清楚易查，先用明確的網域條件處理已知目標，再讓位址條件處理其他連線，通常較容易檢查。

GEOIP 是位址歸屬判斷

GEOIP,CN,DIRECT 表示依據 IP 地理資料庫，將歸屬標記為 CN 的目標交由 DIRECT 處理。它不是依網頁語言、網域後綴、公司註冊地或使用者所在位置判斷。使用中文內容的網站可能連到其他地區的位址，同一網域也可能因解析結果改變而得到不同歸屬。解讀 GEOIP 結果時，應一併查看實際目標 IP，不能只憑網站名稱就認定規則比對錯誤。

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

這組規則先處理 example.com 網域體系，再讓 GEOIP 判斷其餘請求。若將 GEOIP 移到前面，某個已解析的位址可能先命中 GEOIP，導致後面的網域規則沒有執行機會。位址歸屬資料庫也有更新頻率與識別範圍的限制，不能把歸屬判斷當成精確的業務分類。少數重要網域若必須使用固定策略，加入明確的前置條件，比依賴其所有位址長期維持相同歸屬更容易掌控。

排查區域網路目標時，還要區分「規則選擇 DIRECT」與「裝置能否連到該目標」。DIRECT 只代表選擇直接連線，無法補上區域網路路由、修正目標連接埠或改變存取權限。若規則命中正確但仍無法存取，應檢查目前的 Wi-Fi、目標裝置狀態，以及位址是否已變更。先確認請求實際送往哪個位址，再檢查網段規則，以免把位址過期或服務未監聽誤認為 IP-CIDR 語法問題。

五、PROXY、DIRECT、REJECT 與 Global Routing

規則最後一個主要欄位通常是處理策略。條件回答「哪些請求」，策略回答「命中後如何處理」。PROXY、DIRECT、REJECT 代表不同處理結果，不是三種速度等級，也不代表連線品質。閱讀設定檔時，可以先整理出各種策略，確認每種結果是否符合用途，再檢查各條件是否將請求導向正確位置。

策略名稱對應實際處理方式

PROXY 會將請求交由代理路徑處理，但仍仰賴目前有效的伺服器資訊與相關選擇。它不會根據規則中的測試網域產生伺服器，也無法修復訂閱中已失效的項目。DIRECT 使用直接連往目標的路徑，但仍取決於本機網路、解析結果與目標服務狀態。REJECT 則會攔截符合條件的請求，適用於確認應阻擋的目標；若用於範圍不明確的條件，容易造成零星的頁面故障。

若設定支援並使用自訂策略名稱，必須確認該名稱已在目前設定中定義，而且引用文字完全一致。不要直接貼上別人檔案中的策略群組名稱，再期待它自動對應到自己的伺服器。空格、大小寫與名稱變更也應逐一核對。初次排查時，先使用容易理解的基本策略建立比較基準，再採用更複雜的策略組織方式，通常更容易找出錯誤。

Global Routing 決定設定的套用方式

Global Routing 的 Config、Proxy、Direct 分別代表設定、代理與直連三種模式。若要依 Rule 逐條分流，應確認目前使用 Config。Proxy 與 Direct 可用來整體比較連線路徑，但不能用來檢查每條規則是否正確；模式已變更時，連線結果不能直接證明某一行 Rule 已生效。記錄故障時，應同時註明模式與設定檔，缺少其中一項都可能導致重現條件不完整。

透過模式比較縮小排查範圍

假設某個目標在 Proxy 下可以存取、在 Config 下卻失敗，不應立刻認定整份設定無法使用。先回到 Config 查看該目標命中的規則：可能被 REJECT 攔截、被導向無法連線的 DIRECT 路徑，也可能使用了不同的自訂策略。若目標在兩種模式下都失敗，再進一步檢查伺服器、DNS 與目標服務。模式比較只能提供線索，不能直接判定某個欄位一定有錯。

切換 Global Routing 後，應查看新連線。已建立的連線可能持續傳輸，App 也可能重用原有連線，因此連續切換模式後立刻重新整理同一頁面，測試結果未必準確。測試時應維持其他條件不變，重新發出可明確識別的請求，並以連線記錄確認目前路徑。若只看網頁是否顯示內容，也會受到快取影響：顯示舊頁面不代表剛才的網路請求已成功。

請將客戶端購買與連線服務分開理解。Shadowrocket 是 Apple 平台的付費客戶端，客戶端一次買斷 ≠ 線路方案；使用者仍須具備自己的訂閱或伺服器資訊。取得 App、核對正版圖示與開發者資訊，請參閱App Store 正版下載說明；裝置相容性與系統需求以 App Store 頁面標示為準。設定欄位用來管理既有連線行為，不會提供額外的連線資源。

六、比對順序、例外規則與 FINAL

Rule 的核心原則是由上而下逐條比對，命中後採用對應策略，不會繼續往下尋找更符合直覺的條件。規則類型本身沒有「精確網域永遠優先於網段」這種自動優先順序。所謂優先級，首先取決於規則在檔案中的位置。判斷某條規則為何未生效，應從它上方的項目開始檢查，而不是只反覆確認該規則本身的語法。

先處理例外，再處理範圍

建議依需求安排條件：明確例外在前、範圍較廣的網域或位址條件在後，最後放置兜底規則。這種排列方式較容易維護，但不代表每份檔案都必須採用相同分類順序。真正決定結果的，仍是每個目標首次命中的位置。例如，某個區域網路服務需要單獨處理，就要確認前面的廣泛網域或位址條件不會先接手，不能只因它屬於內網便假設它會自動優先。

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

以這份範例來說，api.example.com 在第一條規則命中，不會繼續比對後綴；ads.example.com 在第二條規則遭到攔截；其他 example.com 子網域則使用 PROXY。接著才處理尚未命中的位址範圍與 GEOIP。閱讀規則時，可以選出三個具體目標，分別從第一行開始手動推演，標出第一個成立的條件。這樣能直接找出例外順序錯誤、條件重疊及兜底位置過早等問題。

FINAL 是無條件兜底規則

FINAL 用來處理前面所有條件都未命中的連線，常見寫法有 FINAL,PROXY 或 FINAL,DIRECT。它沒有網域或位址比對值，因此欄位數量與一般網域規則不同。應將它放在 Rule 區段最後一條有效規則的位置。若在它後面繼續新增 DOMAIN 項目，這些項目不會因為條件更具體就重新獲得比對機會，反而容易讓人誤以為「明明寫了卻始終不生效」。

選擇 FINAL 的策略前，先確認預設路徑。FINAL,PROXY 表示未個別分類的連線會走代理路徑；FINAL,DIRECT 則讓這些連線直接連線。評估兩種選擇時，都不能忽略現有規則；相同的前置條件搭配不同兜底策略，會產生不同的涵蓋範圍。變更兜底通常影響範圍很大，應先確認幾個重要目標實際命中的位置，避免為了修復一個網站而改變所有未分類流量的路徑。

整理重複規則與遠端內容

重複項目不一定會造成語法錯誤，但會增加閱讀負擔。兩條條件完全相同、策略卻不同時，後面的項目通常會被前面的規則遮蔽；條件相似但範圍不同，則要逐一判斷目標。整理時不要只依字母排序，因為排序可能破壞原本刻意安排的例外順序。可以先標註各組規則的用途，再刪除確認多餘的項目，並在每次整理後重新驗證重要網域。

合併不同來源的片段時，最常見的問題是重複區段名稱、重複 FINAL，以及將整段內容直接插在既有兜底規則之後。正確做法是先辨識片段屬於哪個區段，移除不需要重複的區段標頭，再將規則放到預期位置。若片段引用自訂策略，也要先確認相關定義存在。片段能貼進文字，不代表它與目前設定的結構、策略及預設路徑相容。

維護較長的列表時，變更紀錄應說明「為什麼放在這裡」，而不只是「新增了什麼」。例如，某個精確網域排在後綴規則之前，是為了保留直接連線的例外；某條關鍵字規則被移除，是因為它涵蓋了正常資源。日後排查問題時，這些背景資訊比項目數量更有幫助。若出現非預期的命中，先縮小到相關規則進行驗證，確認後再合併回完整檔案，不要不斷新增相反規則碰運氣。

七、Host 與 URL Rewrite 的作用範圍

Host、URL Rewrite 與 Rule 分別負責位址對應、請求網址改寫與策略選擇，不應混為一談。設定包含這幾個區段，不代表每次排查都需要同時調整它們。若目的只是讓某個網域走 PROXY，優先使用 Rule；若要為明確的主機名稱指定位址，再考慮 Host；只有需要改變符合條件的 URL 時，才檢查 URL Rewrite。釐清功能範圍，可以減少看似有效、卻難以解釋的修補。

Host 指定主機名稱的位址對應

Host 的基本寫法是主機名稱、等號與目標位址，不填寫完整網頁網址。它會改變該主機名稱對應的位址資訊，不會直接指定 PROXY 或 DIRECT。即使 Host 為網域指定了位址，連線仍須依目前模式與相關規則處理。不要在 Host 行末隨意加上策略欄位，期待它同時負責網域分流；位址對應與策略條件應分別寫在各自對應的區段中。

[Host]
service.example.com = 192.0.2.10

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

範例位址僅供文件說明，無法用於實際存取。設定實際對應前，應確認位址由目標服務的可靠設定提供，並清楚知道何時需要還原。網站可能使用動態位址、多個服務入口，或以不同位址提供不同內容；長期固定使用曾經可用的位址，可能在服務調整後失效。臨時使用 Host 進行診斷時，應記錄原始狀態，測試完成後即還原，避免讓診斷條件變成長期依賴。

Host 無法將任意伺服器變成目標網站。HTTPS 連線仍會涉及主機名稱、憑證與伺服器端處理邏輯；位址能建立連線，不代表憑證與內容就一定相符。若變更對應後出現憑證錯誤，不應直接降低驗證要求來維持存取，而應確認網域與位址是否確實屬於同一項服務。若目標原本使用多個位址，也要留意固定對應可能改變可用性與連線選擇方式。

URL Rewrite 依明確條件改寫網址

URL Rewrite 項目通常包含比對運算式、替換目標與處理方式。以下示範將明確主機名稱的 HTTP 網址重新導向 HTTPS，並使用 302 表示暫時重新導向。正規表示式中的句點需要跳脫，否則會代表任意字元；開頭的錨點則用來限定從網址起始處比對。此範例僅示範基本結構，啟用前必須先針對受控目標檢查比對範圍與實際回應，不應直接套用至所有網域。

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

改寫規則無法保證目標提供 HTTPS 服務，也無法保證登入、路徑或請求方法在重新導向後仍符合原本的業務需求。若需要保留路徑，應先了解擷取群組與替換參照的關係，並透過多個網址驗證，而非只測試網站首頁。也要避免改寫後的目標再次符合另一條反向規則，否則可能形成重新導向迴圈。若瀏覽器提示重新導向次數過多，應先檢查條件與目標是否彼此重疊。

分開評估資訊可見性與額外設定

對於加密請求，能否執行某種 URL 層級的處理，取決於 App 可取得哪些請求資訊，以及相關功能是否符合使用前提。不要因網域分流可正常運作，就認為所有 URL 路徑都能讀取；也不要為了一條範例改寫規則，順帶啟用自己不了解的流量解密設定。憑證與加密處理涉及額外的信任範圍，應在確有需求並了解影響時另行設定；本頁不將它列為一般規則分流的前置步驟。

若 Host、URL Rewrite 與 Rule 同時存在，排查時一次只停用其中一類變更。先還原原本的位址對應並建立新請求，查看目標 IP；再檢查 URL 是否依預期改寫，最後核對策略命中結果。如此一來，就能區分「存取了錯誤位址」、「導向錯誤位置」與「選擇錯誤路徑」。不要只靠新增 DOMAIN-SUFFIX 解決這三類問題，因為正確的策略選擇無法抵銷錯誤的位址對應或重新導向迴圈。

八、設定驗證、故障定位與還原

驗證設定的目的，不是讓測試頁面偶爾開啟，而是確認結果可重現、原因可說明、修改可還原。開始前記錄目前的網路、Global Routing、設定檔與使用中的伺服器，並選擇一個能穩定重現問題的目標。接著確認設定已儲存且正在使用，再發起新連線。若未先確認這些項目，後續結果可能來自舊檔案、舊連線或頁面快取，無法用來判斷剛修改的規則。

依連線流程拆解問題

一次存取可拆成網域解析、條件判斷、策略選擇、目標連線與內容回應等檢查點。先找出故障發生在哪個環節：沒有解析結果時檢查 DNS；命中錯誤規則時檢查順序；PROXY 連線失敗時檢查既有伺服器資訊與可達性；目標回應異常時再檢查網站服務。這個順序並非要概括所有網路實作的內部流程，而是讓排查時一次排除一個變數，避免同時修改無關欄位。

1. 確認目前選取的 Config 與 Global Routing，排除檔案和模式不一致。
2. 核對實際請求的主機名稱、目標 IP 與位址類型，不要只看網址列。
3. 查看命中的規則與策略，依檔案順序逐一核對。
4. 維持其他條件不變，只調整一個欄位，再建立新連線。
5. 重新測試重要服務，確認恢復後記錄變更原因並保留可還原副本。

網頁通常包含主頁、圖片、介面與驗證等多種請求。首頁能顯示但無法登入，可能是相關網域被 REJECT 或使用了不同的連線路徑，不能只根據網址列中的主機名稱判斷所有流量。檢查時應找出實際失敗的請求，再核對其符合的條件。若一條關鍵字規則命中多個資源，先縮小規則範圍進行比較，通常比將整個網站及所有子網域都改為相同策略，更容易找出根本原因。

依照現象選擇下一步

Connectivity Test 可協助比較伺服器回應，但其測量對象與方式和實際服務請求並不完全相同。某個數值正常，不代表所有目標、協定與資源都能成功；某種測試沒有回應，也不應脫離服務狀態就判定所有連線都已失效。應將測試結果作為線索，並與實際連線記錄相互比對。需要檢查既有伺服器欄位時，回到匯入來源逐項確認，不要透過更換規則掩蓋位址或驗證資訊錯誤。

建立最小重現案例，再合併回完整設定

完整檔案很長時，可複製一份專用測試檔，只保留理解目前問題所需的 General 設定、一條明確目標條件與 FINAL。先驗證基本路徑，再分組加入原有規則，直到問題再次出現。每次加入時都保留原本的相對順序，並記錄新增範圍。這樣便能找出造成遮蔽的具體項目，而不是在數百行內容中反覆猜測。測試完成後，回到正式檔案合併已驗證的修改，並確認沒有誤選測試檔長期使用。

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

此片段僅用來說明「將指定目標與其他連線分開」的驗證方式，不包含建立連線所需的所有資訊。重現說明應包含預期策略、實際策略與對應規則位置，並隱藏訂閱網址、驗證資訊及個人識別資料。若設定更新後問題再次出現，請比較更新前後的相關區段，確認是來源內容覆寫了修改，還是實際伺服器、DNS 或目標位址發生變化；不要直接將所有更新都歸因於同一種原因。

還原後，應再次確認原本的重要目標能夠存取，再結束排查。保留簡短紀錄，註明問題現象、最先命中的條件、最後的修改及還原方式。一般疑問可繼續查看常見問題；首次連線流程請參閱使用教學；購買、恢復購買與商店資訊核對請參閱正版核對說明。完成規則維護的標準，是下次遇到類似問題時能依相同步驟驗證，而不是憑記憶再次嘗試修改。