Shadowrocket 規則手冊
設定結構與比對順序

設定檔與訂閱是不同的項目

設定檔描述如何處理要求，訂閱主要用於匯入及維護使用者已有的伺服器項目。兩者可以共同參與一次連線，但不能互相取代。訂閱更新成功，只能表示相關內容已讀取，不能證明目前規則正確；設定檔可以儲存，也不代表其中引用的代理已可使用。排錯前請先分別確認這兩個項目，避免把伺服器參數問題誤當成規則例外。

在 Config 中確認目前選用的設定，再進入相應的編輯畫面。需要測試時，先複製檔案，為副本取一個容易辨識的名稱，並保留原檔。只修改副本卻沒有選用副本，連線結果通常不會反映修改。反之，若編輯的是目前使用中的檔案，儲存後也應依 App 提示重新載入；驗證時請重新發出要求，不要沿用修改前已建立的連線。

方括號決定設定的適用範圍

Shadowrocket 常見的文字設定會以章節標題整理內容。[General] 放一般設定，[Rule] 放分流規則，[Host] 放主機名稱對應，[URL Rewrite] 放要求網址改寫規則。章節不是裝飾：同一行文字位於不同章節時，解讀方式可能不同。複製片段時，必須一併確認所屬章節，不能只因檔案中出現關鍵字，就認定設定已生效。

[General]
dns-server = system

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

這段範例僅展示結構。第一條規則精確處理根網域，第二條處理相同後綴的其他網域，最後處理其餘要求。dns-server = system 表示使用系統 DNS 設定，不保證在所有環境中的解析結果都相同。不要因為範例可以儲存，就推定伺服器選擇、連線授權或所有網路設定都已完成；仍須在 App 中逐項確認。

修改設定時保留可追溯的最小差異

閱讀較長的檔案時，先找章節標題，再找與目前問題相關的段落。重複章節、重複的兜底規則，以及散落在檔案末尾的臨時項目，都會增加判讀難度。建議將同類的本機例外集中放在一起，並用獨立註解行說明用途。註解應說明加入規則的原因，而非重複規則內容；準備分享的註解中不要寫入真實訂閱網址或認證參數。

匯入設定前也應先閱讀內容，不要只憑檔名判斷是否適用。請優先查看最終策略、DNS 設定、主機對應與改寫區段，再確認是否引用目前環境中不存在的策略名稱。設定即使包含許多規則，也可能只適用於原本的伺服器架構。遇到不熟悉的選項，先保留原值並在 App 中確認支援情況，不要把其他格式的設定名稱直接拼進目前的檔案。

自動更新內容與手動維護內容應分開管理。如果設定來源更新時會覆蓋本機編輯，修改可能在下次更新後消失。請先確認更新對象是訂閱還是整份設定，再決定本機例外應放在哪裡。若無法確認覆蓋範圍，保留獨立副本並記錄差異，比持續修改同一份遠端內容更容易還原，也更容易判斷故障是來自更新還是本機操作。

以下程式碼區塊有些包含章節標題，有些只有規則行。只有規則行的片段應放入現有的 [Rule] 章節，不必為每段範例另建同名章節。若要從購買與首次開啟開始重新確認環境，請前往App Store 正版驗證頁；本手冊不會將取得用戶端與設定流量混為同一套操作。

先確認 Config、Proxy、Direct

需要依設定檔分流時，Global Routing 應選擇 Config。Proxy 與 Direct 是不同的全域處理模式，不是附加到設定規則中的兩條一般規則。如果目前處於 Proxy，就不能藉由修改網域規則來證明 Config 中的分流正確；如果處於 Direct，即使目標可以連線，也不代表代理伺服器已接收這次要求。排錯時應優先確認模式。

表格說明三種模式的主要用途，不代表設定中的其他選項都會被完整取代。DNS、既有連線以及 App 本身的網路行為，仍可能影響觀察結果。切換模式是用來對照，不是證明某個環節絕對正常的檢測方式。測試時請記錄目前模式與選用的設定，完成後恢復預期設定，避免後續調整建立在錯誤前提上。

模式、規則與伺服器分屬三個判斷層次

排錯可分為三個層次：先確認是否進入設定分流，再確認要求符合哪條規則，最後確認策略所依賴的連線資源是否可用。規則選擇 PROXY，表達的是處理方向，不會補上伺服器位址、連接埠或認證資訊。使用者已有的訂閱中若沒有可用項目，再精細的網域規則也無法取代連線參數。請先檢查自己的伺服器資訊，再判斷是否需要增加例外。

請勿混淆介面中的 Proxy 與規則中的 PROXY。前者是 Global Routing 的選項，後者是設定文字中的策略關鍵字。兩者都與代理路徑有關，但所屬層級不同。同樣地，介面中的 Direct 與規則中的 DIRECT 也應依上下文區分。編輯文字時保留大寫關鍵字，有助於避免把模式名稱誤認為規則參數。

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

這段規則預期的效果是：在 Config 參與處理的前提下，符合指定網域後綴的要求使用 PROXY，其餘要求使用 DIRECT。驗證時應同時檢查一個應符合規則的要求，以及一個不應符合的要求。只確認目標網站能否開啟，無法判斷是規則正確、全域模式覆蓋預期，還是目標原本就能直接連線。

用對照測試縮小範圍，避免反覆切換

若 Proxy 模式可連線、Config 模式卻失敗，請優先檢查 Config 使用的檔案、策略引用與比對順序。這表示兩種處理方式有差異，但不能立刻斷定網域規則寫錯；主機對應、解析設定或較早出現的拒絕規則，也可能造成差異。若兩種模式都失敗，應先確認伺服器參數與基本網路，不要繼續擴增規則清單。

若 Direct 模式成功、Proxy 模式失敗，應沿著代理路徑排查，不要立刻將整個目標後綴改為 DIRECT。暫時改用直連可作為對照，但同時也改變了要求路徑，可能只是避開原本的問題。請記錄失敗發生在建立連線、名稱解析，還是後續存取階段，再決定要修改哪一層。每次只改變一個條件，結果才容易解讀。

切換後請重新開啟目標或重新操作，必要時結束既有連線再測。長連線可能繼續沿用建立時的處理方式；快取頁面也可能讓人誤以為剛才又發出了網路要求。測試時請選擇確實會產生要求的操作，並參考 App 中實際可見的連線記錄。詳細操作路徑請見教學中的 Global Routing 說明。

DOMAIN：只比對指定主機名稱

DOMAIN 用於精確比對網域。寫入 example.com 時，比對對象只有這個主機名稱本身，不會自動包含所有子網域。因此，目標僅涉及一個明確主機時，精確規則通常更容易驗證；若要同時處理根網域與子網域，再考慮使用後綴規則。精確網域參數中不要加入通訊協定前綴、路徑或頁面查詢參數，這些都不屬於網域。

DOMAIN,example.com,DIRECT
DOMAIN,www.example.com,PROXY
DOMAIN,api.example.com,PROXY

這三行分別處理三個完整名稱。第二行不會比對第一行，也不會自動涵蓋第三行。一個網站可能將頁面、登入、圖片與 API 分散在不同主機上，瀏覽器網址列只會顯示其中一部分。若首頁正常但登入失敗，請先查看實際失敗要求的主機名稱，再決定是否補上規則；不要只憑網址列中的根網域，就推定整個服務都已符合規則。

DOMAIN-SUFFIX：比對網域邊界上的後綴

DOMAIN-SUFFIX,example.com,PROXY 表示比對網域後綴，通常涵蓋根網域及其子網域，例如 www.example.com。這不是任意字串包含比對，notexample.com 不會因為字面結尾相似，就被視為相同的網域後綴。閱讀規則時應留意網域標籤的邊界，不要將後綴規則理解為搜尋整個網址。

常見錯誤是將 *.example.com 當成後綴規則的必要寫法。這裡直接寫 example.com 就能表示該後綴，不需要額外加上萬用字元。規則參數末尾也不必加斜線。複製目標網址時，請先從完整網址中擷取主機名稱，移除通訊協定、連接埠、路徑與查詢部分，再判斷應使用精確規則或後綴規則。

DOMAIN-KEYWORD：比對範圍較廣，須留意誤判

DOMAIN-KEYWORD 會檢查網域中是否包含指定字串。它不以完整網域標籤為邊界，因此影響範圍通常不如後綴規則容易判斷。除非確實需要依共同字串處理多個網域，否則優先使用可列舉的精確名稱或明確後綴。關鍵字越短，越容易一併比對無關要求，日後維護時也更難解釋某個主機為何走代理路徑。

DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,REJECT
FINAL,DIRECT

依此順序，精確主機先使用 DIRECT；相同後綴下的其他要求再使用 PROXY；包含關鍵字但未被前兩行處理的網域，才可能進入 REJECT。此範例用於說明三種範圍的差異，不代表建議以寬泛關鍵字拒絕所有相關名稱。若將第三行移到前面，原本希望保留的例外可能就沒有機會生效。

網域規則必須依賴用戶端取得可供比對的網域資訊。若要求直接連線至某個位址，不應預期用戶端一定能反推出原始主機名稱。反之，網域解析出多個位址，也不表示需要為每個位址手動撰寫規則。請依實際要求形式選擇比對方式：能穩定識別主機名稱時使用網域規則；確實需要處理網路位址範圍時，再使用位址規則。

新增網域規則後，至少核對根網域、一個子網域，以及一個相似但無關的網域應如何處理。可以先在紙上推演，不必把所有範例都當成實際可連線的服務。逐一說明規則基本語法的內容，請見DOMAIN、DOMAIN-SUFFIX 與其他規則類型詳解；後文會繼續說明位址規則與網域規則交叉時的判斷方式。

IP-CIDR 與 IP-CIDR6 用於描述位址範圍

IP-CIDR 用於 IPv4 位址範圍，IP-CIDR6 用於 IPv6 位址範圍。斜線後的數字是前綴長度，不是連接埠，也不是萬用字元數量。單一 IPv4 位址可用 /32 表示，單一 IPv6 位址可用 /128 表示。擴大網段會一併擴大影響範圍，不能因為某個位址連線失敗，就將相鄰的大段位址全部指定為相同策略。

IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR,192.0.2.0/24,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve

這裡使用文件範例位址，不代表真實服務端。第一行是單一位址的精確例外，第二行是範圍較大的位址段；順序會決定例外能否生效。IPv6 範例展示另一種位址家族的語法，不能取代 IPv4 規則。若實際目標可能回傳兩種位址，應分別了解處理結果，不要只檢查其中一種位址家族，就認定整次存取都符合預期。

no-resolve 控制規則比對時是否額外進行解析

位址規則處理網域要求時，可能需要先取得位址才能判斷。no-resolve 用於避免僅為比對這條規則而主動觸發網域解析；若已有可用的位址資訊，仍應依實際處理流程判斷結果。它不代表整個用戶端停止 DNS，也不保證要求永遠不會經由其他解析路徑。若將此參數當成通用的解析故障修復開關，排查方向就會偏離問題本身。

需要依網域穩定分流的服務，通常先以網域規則表達意圖；確實需要處理特定位址範圍時，才使用位址規則。原因是同一位址可能承載多個主機，而同一主機也可能因網路、解析器與時間不同而回傳不同位址。將單次解析結果設為長期規則，可能漏掉後續位址變化，也可能影響共用該位址的其他服務。

GEOIP 是位址分類，不是網站身分識別

GEOIP,CN,DIRECT 表示依位址資料庫中的地區分類選擇策略。它判斷的是位址歸屬資訊，不是經營者或頁面內容。服務採用分散式基礎架構時，網域身分與連線位址的分類可能不同。資料庫也可能更新，且分類存在邊界，因此不能將一次地區比對視為服務實際部署位置的永久結論。

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

範例先為明確網域指定路徑，再由位址分類處理其他要求，最後交給兜底。這樣的順序讓意圖明確的網域規則優先於範圍較廣的位址判斷。若將 GEOIP 移到前面，解析到相關位址範圍的網域可能先被處理，後面的網域規則便沒有機會生效。重點不在於哪種類型天生優先，而是哪條規則先符合條件。

USER-AGENT 受要求資訊可見性限制

USER-AGENT 依據可觀察到的要求標頭特徵進行比對，適用於能取得相應要求資訊的情境，但不能當成可靠識別所有 App 身分的方法。不同 App 可能使用相同識別字，同一個 App 也可能在不同要求中使用不同識別字。尤其是加密流量，普通網路轉送不代表可以讀取其中的 HTTP 要求標頭；若看不到比對欄位，規則不會根據 App 名稱推測內容。

USER-AGENT,ExampleClient*,DIRECT

此行僅說明該類型的寫法與萬用字元形式，不代表裝置上有這個程式。不要為了讓範例符合條件而更改裝置安全設定，也不要以 USER-AGENT 取代能明確表達意圖的網域規則。若懷疑規則未生效，請先確認實際要求中是否存在可觀察且符合預期的欄位，再檢查規則順序；如果欄位原本就不可觀察，增加更多相似規則通常沒有幫助。

位址、地區與要求特徵規則都必須依實際可觀察資訊解讀。記錄中只有一個目標位址時，請先確認它是直接要求的位址、解析結果，還是代理伺服器位址；三者並非同一項目。若將連線至伺服器的外層路徑誤認為目標網站位址，整套分流判斷就會出錯。無法確認時，請回到最精簡的網域規則進行對照，再逐步加入位址條件。

規則回答「比對什麼」，策略回答「如何處理」

常見的網域規則由類型、比對內容與策略組成。DOMAIN-SUFFIX,example.com,PROXY 中，前兩項決定條件，最後一項決定符合後的處理方式。變更最後一項不會改變比對範圍；將 PROXY 改為 DIRECT 後，仍然是同一批網域符合規則，只是連線路徑改變。了解這項分工，就能避免把策略問題誤修成網域範圍問題。

PROXY 實際使用的連線項目，需在目前的設定與 App 選擇中確認。若設定還包含自訂策略名稱，請確認名稱已有對應定義，且其成員符合目前環境。不能只因名稱帶有「代理」的意思，就認定它指向目前選用的伺服器。複製規則時也不要任意保留來源檔案中的自訂名稱，以免引用內容與實際項目不一致。

DIRECT 只選擇連線路徑，不保證連線成功

DIRECT 會讓符合規則的要求使用直接連線路徑，但仍取決於本機網路、目標服務與解析結果。某條規則改為 DIRECT 後仍然失敗，應沿直連路徑繼續排查，不要直接認定規則未比對成功。反之，直連成功也不代表原代理路徑的認證、憑證或傳輸參數正常。策略選擇與網路可連通性是兩個不同結論，需分別透過記錄與實際存取驗證。

REJECT 表示刻意阻止要求。新增此類規則前，請先確認目標主機不會提供登入、驗證或頁面所需的資源。只憑名稱猜測用途，容易連共用 API 一併拒絕。若修改後頁面部分內容缺失，可先暫時移除新增的拒絕規則再測；不要同時新增代理例外、修改 DNS 與改寫網址，否則無法判斷是哪項變更讓功能恢復。

FINAL 不需要網域參數

FINAL 是未被前面規則處理時的兜底選擇。常見寫法為 FINAL,DIRECT 或 FINAL,PROXY，不需要像網域規則那樣再填入比對內容。兜底應放在規則清單末尾，因為它不需要等待特定網域符合條件。若將它提前，後面的普通規則可能永遠不會執行，新增項目看起來就會怎麼改都沒效果。

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

此片段表示「一個精確例外、一個後綴範圍，其餘直連」。若實際意圖是預設使用代理，應將最後一行改為 FINAL,PROXY，並重新檢視前面的直連例外是否仍需保留。不要只複製最後一行而忽略整份檔案的預設方向；預設方向改變後，即使前面的規則完全不動，許多未列出的要求也會改變路徑。

先釐清需求，再選擇兜底方向

選擇 FINAL 前，先用一句話說明目標：是只有少數指定主機使用代理，其餘直接連線；還是大多數要求使用代理，只保留少量直連例外。前者通常較容易搭配 FINAL,DIRECT；後者則需仔細維護例外與 FINAL,PROXY 的關係。沒有一種設定適用於所有網路，應依使用者自己的存取需求與既有連線條件決定。

兜底規則不是故障時的自動切換。FINAL,PROXY 不表示前面的代理連線失敗後會再嘗試其他策略；它判斷的是前面的比對條件是否符合，不是連線是否成功。規則比對與連線結果發生在不同環節。不要為同一網域連續寫兩條不同策略，期待第一條失敗時自動改用第二條；一般的順序比對不會以這種方式重試。

維護時讓每份規則清單只有一個明確的最終出口，方便閱讀與驗證。若檔案中有多個 FINAL，請先找出第一個實際會執行的位置，再整理其後無效的項目。刪除前請保留副本，避免誤將其他章節的內容當成規則。最後應能說明每條一般規則的用途，以及未列出的要求會如何處理。

第一條符合的規則優先，不以「看起來更精確」為準

一般順序規則應由上往下判斷，第一條符合的項目決定處理策略。不要預設 DOMAIN 一定優先於 DOMAIN-SUFFIX，也不要以為檔案後方的新規則會自動覆蓋舊規則。精確程度是安排順序的重要依據，但不能因此忽略文字排列順序。需要保留的精確例外，應放在可能涵蓋它的寬泛規則之前。

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

存取 api.example.com 時，第一行已決定處理方式，不必再比對第二行。存取 www.example.com 時，第一行不符合，才由第二行處理。存取其他未列出的網域時，則由最後一行兜底。這些情況可在實際連線前先行推演；若紙上推演已發現某條規則永遠不會執行，就不必反覆切換網路尋找原因。

情境一：只有指定網站使用代理

若需求明確為少數網站使用代理，先用精確網域或後綴列出目標，再選擇 FINAL,DIRECT。不要一開始就加入大量地區、關鍵字與位址段規則，以免原本簡單的需求被不同範圍交錯涵蓋。若網站實際依賴多個網域，應根據要求記錄逐步補齊，而非依網站名稱猜測所有基礎架構，或以極寬泛的共同字串涵蓋整個服務。

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

這段最精簡的設定適合說明結構，不代表任何實際網站都只需要一個後綴。新增規則時，請記錄新主機的用途，例如 API 或靜態資源，並檢查新增範圍是否包含不希望改變路徑的要求。完整情境說明請參閱只讓指定網站走代理的規則寫法，再回到本頁核對順序。

情境二：預設使用代理，但保留明確的直連例外

另一種設定是在前面列出明確的直連條件，再以 FINAL,PROXY 處理其他要求。此時新增寬泛的 DIRECT 規則，會讓更多流量離開預設代理路徑。修改前請先確認例外依據是網域身分、網路位址還是地區分類；不同依據應使用不同規則，不能用看似方便的後綴，表達實際上與網域無關的條件。

[Rule]
DOMAIN,api.example.com,DIRECT
IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
FINAL,PROXY

範例中的兩個例外分別依據主機名稱與位址，不能視為彼此的備援。第一個條件能否使用，取決於要求中的網域資訊；第二個條件則依據位址，且帶有 no-resolve。實際排錯時應記錄究竟是哪一條規則符合，而非只因最終都使用 DIRECT 就將兩者合併。保留比對依據，有助於解釋位址或要求形式變化後的差異。

衝突排查與漸進維護

發現衝突時，先從預期符合的規則往上檢查所有可能更早符合的項目，包括關鍵字、地區與範圍較大的位址段。不要只搜尋完整網域名稱；不含該網域字串的 GEOIP 規則也可能先處理要求。找出原因後，優先移動精確例外或縮小寬泛規則的範圍，不要在檔案不同位置重複新增相同內容。

每次修改後都要測試符合預期的正例與不應符合的反例。正例可確認目標要求採用預期策略，反例則可確認規則範圍沒有意外擴大；只測試正例，寬泛規則造成的誤判可能長期未被發現。請記錄測試模式、設定名稱與操作順序，避免將不同環境下的結果混在一起比較。不必記錄敏感位址或完整認證參數，留下比對依據與策略結果即可。

依順序推演後再刪除冗餘規則。兩條文字完全相同的規則通常不必並存，但條件看似相近的兩條規則，可能涵蓋不同對象。整理時先標記用途，再逐條移除，並在每個步驟後重新測試主要操作。不要在同一次調整中同時清理規則、更新訂閱與更換伺服器；將變更拆開，才能清楚判斷退回哪一步會恢復原有行為。

Host 變更名稱對應，不會直接選擇策略

[Host] 用於主機名稱對應，處理的是某個名稱對應到哪個位址，而不是直接將該主機指定為 PROXY 或 DIRECT。設定對應後，要求仍須依目前的處理方式決定連線路徑。因此，目標名稱能解析至指定位址，不代表分流策略正確；策略正確，也不代表對應位址是目前服務有效的連線位置。

[Host]
example.com = 192.0.2.10
api.example.com = 192.0.2.11

這些位址僅為文件範例。實際填寫前，必須確認自己管理的服務確實需要此對應，並了解目標位址的維護方式。不要將單次 DNS 查詢取得的位址視為長期穩定的入口。對採用動態調度的服務而言，固定對應可能繞過正常調度，並在網路變更或服務移轉後造成間歇性故障；表面上看似代理不穩，實際上可能只是對應資訊已過時。

將網域對應至另一個位址，不會自動讓該位址上的服務具備正確的憑證、虛擬主機設定或存取權限。存取加密網站時，名稱與憑證驗證仍然重要。遇到名稱或憑證錯誤，應檢查服務端與對應設定是否相符，不要藉由放寬驗證來掩蓋問題。Host 適合已知目標的指定設定，不適合用來猜測陌生服務的可用位址。

URL Rewrite 處理要求網址，不取代代理設定

[URL Rewrite] 用於描述符合條件的 URL 如何改寫或重新導向。它與 DOMAIN 類規則不同，比對對象包含網址結構，而不只是主機名稱。新增前請先確認需求究竟是變更存取路徑，還是只想變更網路出口；後者應透過策略與分流處理，不必為了使用代理而改寫網站網址。

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

範例將指定主機的明文網址重新導向至相應的加密網址，並以 302 表示暫時重新導向。正規表示式中的句點已跳脫，避免將任意字元誤當成網域分隔符號；開頭與結尾的界線用來限制比對範圍；括號會擷取路徑，替換內容中的 $1 則引用該擷取結果。複製正規表示式時，請保留反斜線與半形符號，避免文字編輯器將它們換成全形字元。

要求網址是否可被觀察與處理，取決於通訊協定及 App 中相應功能的條件。不能因為設定中寫了 HTTPS 正規表示式，就認定所有加密要求的完整 URL 都可讀取。一般轉送不等於取得加密內容。本頁不會透過變更憑證信任來實現範例；學習改寫時，請使用自己可控制且條件明確的測試要求，不要擴大處理陌生網站。

避免迴圈、比對範圍過廣與認證資訊外流

重新導向後的網址若再次符合相同條件，可能形成迴圈。撰寫時應並列比較輸入與輸出，確認通訊協定、主機或路徑至少有一項不同，讓新要求不再符合原本的比對範圍。連續跳轉也可能來自目標網站本身的回應，不能只憑瀏覽器提示就斷定本機規則造成迴圈。請先停用本機改寫作為對照，再檢查原始服務是否仍會重新導向。

替換目標可能改變要求所攜帶資訊的傳送對象，因此不要任意將含查詢參數的完整網址改寫至另一個主機。登入狀態、一次性參數與 App 內部跳轉都可能依賴目標名稱。測試時僅使用不含真實憑證的範例，並檢查路徑與查詢部分是否依預期保留。正規表示式比對成功，只能證明文字條件成立，不代表實際操作流程仍然正常。

Host 與 URL Rewrite 應分開驗證。先只啟用名稱對應，確認對應結果與存取狀況正常；再單獨新增一條改寫規則，觀察是否出現預期的重新導向。若同時變更兩者，故障可能來自位址錯誤，也可能來自新 URL，會大幅增加定位成本。需要還原時，撤銷本次新增項目並重新發出要求，避免舊連線與快取的重新導向繼續影響判斷。

從實際要求回頭檢查規則，不要只憑頁面結果推測

驗證分流時應同時核對三件事：是否產生新要求、符合了哪些條件，以及最後採用什麼策略。頁面能開啟只是最終結果，無法單獨回答前兩個問題。反過來說，頁面失敗也可能發生在規則已正確選擇路徑之後。請依 App 中實際可見的連線與診斷資訊判斷，記錄目標主機及相關規則，不要把所有失敗都歸因於規則失效。

先確認基本網路可用，再核對 Global Routing 與目前的設定名稱，接著檢查儲存與載入狀態。然後重新產生目標要求，依規則順序找出第一條符合的條件。確認策略符合預期後，再檢查伺服器連線、通訊協定參數與目標服務狀態。依此順序排查可減少無效修改，也能避免把伺服器故障寫成大量長期保留的直連例外。

Connectivity Test 與實際服務存取各自只能驗證一部分

解讀 Connectivity Test 結果時，應考量 App 中選用的測試方式。它可提供連線檢查的參考，但無法涵蓋實際服務所用的所有網域、路徑與通訊協定條件。測試成功後仍須存取實際目標；測試失敗時，也應確認測試對象是否適合目前環境。不要根據單一顯示結果就推定整條連線路徑正常，更不要把測試數值當成規則符合的證明。

伺服器連線逾時時，優先確認位址、連接埠、認證欄位與通訊協定相關參數是否符合使用者已有的資訊。TLS 情境也請留意名稱與系統時間等條件，不要藉由修改網域規則掩蓋參數錯誤。需要依步驟排查時，請參考伺服器連線逾時檢查順序；其他常見連線問題請見連線故障問答。

建立最小重現比不斷疊加例外更有效

若複雜設定無法說明問題，可在副本中只保留一條目標明確的規則與一條 FINAL，暫時移除無關的對應與改寫，再測試相同操作。若最小設定符合預期，就逐組恢復原有規則，直到找出會改變結果的項目。這種暫時簡化只用於定位，未經檢查不可直接取代長期設定；還原後也要重新測試其他原本依賴的功能。

測試時應盡量維持網路、伺服器選擇與存取操作一致。切換網路會改變解析與連線條件，切換伺服器會改變代理路徑，更新訂閱則可能改變項目參數。若同時發生這些變更，就無法從成功或失敗判斷是哪一項造成影響。若需切換網路進行對照，請明確記錄切換前後的條件，不要將它與規則修改混為同一次測試。

更新、還原與安全分享

維護設定時應保留可用的基準版本。每次大幅修改前先複製檔案，記錄修改目的、涉及章節與預期行為；完成後以相同的主要操作重新測試。訂閱更新的操作細節請見訂閱匯入與更新說明。更新後出現差異時，先比較內容，確認是伺服器資訊變更還是規則檔案變更，再決定要還原哪個項目。

向他人描述問題時，只提供必要的最小片段、模式與比對結果。請刪除完整訂閱網址、認證欄位、真實伺服器資訊，以及可能暴露個人存取行為的記錄。設定檔除了規則，也可能包含其他敏感設定；不要因為某段看起來只有網域，就直接分享整份檔案。展示結果時，也請檢查記錄中是否含有個人資訊。

還原原檔後仍須重新確認選用狀態，不能只將副本改回原名稱就認為已完成還原。請重新載入並重新發出要求，檢查預期網域、反例與兜底這三種結果。若只有舊連線仍異常，請先結束該連線再測；若新要求也異常，則依模式、規則、策略與連線路徑逐層檢查，不要反覆改寫同一條規則的語法。