Shadowrocket 規則參考

設定檔結構與載入範圍

Shadowrocket 的設定檔可包含多個以方括號標示的區段。區段名稱決定後續文字的解讀方式，與檔案中的視覺分組無關。[Rule] 下的網域規則與 [Host] 下的位址對應，即使出現相同網域，作用也不同。開始修改前，應先確認目前啟用的設定檔，再編輯相應區段。只將檔案儲存至 Config 列表，不代表已選取該檔案。

先區分伺服器資訊、訂閱與設定檔

伺服器資訊說明連線目標、使用的協定及身分驗證方式；訂閱用於批次取得並更新這些項目；規則設定檔則決定各項請求採用哪種處理策略。這三者可能出現在同一工作流程中，卻不能互相取代。伺服器能連線，不代表規則檔已生效；規則檔能讀取，也不代表其中指定的代理出口可用。匯入後未得到預期結果時，應先判斷缺少的是伺服器項目，還是分流設定。

在 Config 中檢查檔案時，應一併記錄檔名、目前選取狀態與來源。遠端檔案日後更新時，可能會覆蓋本機修改，因此初次測試應保留原始副本。尚未了解原始設定前，不要以網路上的片段取代整段內容。本頁範例僅用於說明語法，不含驗證參數，也不是可直接連線的完整設定。

四個區段各自負責什麼

[General]
dns-server = system

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

[Host]
fixed.example.com = 192.0.2.10

上方的 192.0.2.10 是文件範例位址，不是可供使用的伺服器。閱讀這段文字時，應先看區段名稱，再看各行的分隔方式：General 與 Host 使用等號表示鍵值關係，Rule 通常以英文逗號分隔規則類型、條件與策略。全形逗號、不可見空格，以及從富文字複製而來的標點，都可能使看似相同的內容成為不同的輸入。

編輯前建立基本檢查清單

先記下 Global Routing 目前的模式，再確認 SERVER 中選取的伺服器，最後確認 Config 中正在使用的檔案。記錄這三處，才能避免把出口切換誤認為規則變更。若要比較修改前後的差異，只變更一項條件並儲存，再重新進行連線測試。不要同時更換伺服器、調整 DNS、重排規則，否則結果改變後便無法確認原因。

判斷設定檔時，也要區分「能解析」與「符合目的」。前者只表示語法可被接受；後者則需要透過實際請求驗證。例如，寫在 FINAL 後面的網域規則可能語法正確，卻不會處理已被前面的兜底規則接收的請求。反之，檔案中的註解或許清楚說明用途，但註解本身不會改變比對行為，應以實際生效的語句為準。

General、DNS 與規則輸入

General 會影響規則執行的環境。網域如何解析、哪些目標由系統路徑處理，都會改變後續可觀察到的請求資訊。因此，分析規則前不能只看 Rule 區段。在不同解析條件下，相同規則可能產生不同結果，特別是依賴目標位址的 GEOIP、IP-CIDR 與 IP-CIDR6。先釐清解析與路由是不同階段，再決定要修改哪一處。

DNS 解析不等於策略選擇

DNS 會將網域轉換為位址，分流策略則決定如何處理連線。網域成功解析，只表示取得某種解析結果，不能據此判斷請求會使用 PROXY 還是 DIRECT。網域規則不一定要等取得位址後才有比對依據；用戶端掌握目標網域時，可直接依 DOMAIN 或 DOMAIN-SUFFIX 判斷。位址規則則需要目標位址，兩者所需的輸入條件不同。

[General]
dns-server = system

[Rule]
DOMAIN,portal.example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

dns-server = system 表示此處使用系統提供的 DNS。這是方便理解的起點，不是適用於所有網路的固定答案。若現有設定已指定其他解析方式，應先記下其用途，不要為套用範例而直接覆寫。網路切換、系統 DNS 狀態及所連線服務的部署方式，都可能影響最終回傳的位址。

no-resolve 的作用範圍

位址規則末尾的 no-resolve 表示不要只為了嘗試該條位址規則而觸發網域解析。這不等於關閉 DNS，也不表示整個連線之後都不會再解析。如果請求原本已有可用的目標位址，仍可依該位址進行判斷；如果只有網域而當下沒有對應位址，這條規則便無法憑空取得位址來比對，後續規則仍可能繼續處理請求。

這項差異對排錯很重要：加入 no-resolve 後，某個網域不再符合位址規則，不一定是位址區段寫錯，也可能是比對時沒有可用位址。不要為了強行符合而刪除所有 no-resolve。應先確認目標是網域請求還是直接位址請求，再判斷是否需要解析，最後權衡解析成本與分流目的。

快取、網路切換與觀察時間

瀏覽器、應用程式、系統與用戶端可能在不同位置保留解析或連線狀態。變更 DNS 後立即重新整理頁面，有時仍會沿用既有連線，因此看不到新設定的效果。測試時應重新發出請求，必要時關閉相關應用程式的既有工作階段，再依應用程式提供的方式清除相關快取。重新整理一次沒有變化，不足以證明設定未載入；同樣地，偶然成功一次也不足以證明問題已解決。

在無線網路與行動網路之間切換後，應重新確認基礎網路是否可用。若系統本身無法存取已知可連線的目標，繼續調整 Rule 通常無法解決底層連線問題。可先使用 Direct 模式進行有限度的對照，再回到 Config 驗證規則。對照完成後應恢復原本模式，避免之後將全域直連狀態誤認為規則分流結果。

不要把略過範圍當成一般 Rule

General 中某些設定會影響哪些流量進入後續處理路徑，與 Rule 中的 DIRECT 並非同一層意思。擴大略過範圍可能使請求根本不經過預期規則，因此不能只因「最後有 FINAL」就推斷所有流量都會套用兜底規則。調整這類設定前，應檢查現有檔案說明與 App 內選項；用途不明時，保留原值比大量刪除更容易維持可重現性。

遇到 IPv6 相關問題，也應檢查網域是否同時回傳不同位址族的結果。只為 IPv4 撰寫位址規則，不代表 IPv6 請求也涵蓋在內。優先使用能準確描述業務範圍的網域規則，再依實際需要補充位址範圍。不要一開始就停用某種位址族；先透過記錄確認實際目標位址，才能判斷問題出在解析、比對還是連線路徑。

DOMAIN 系列的比對範圍

與不斷變動的目標位址相比，網域規則通常更適合表達網站分流需求，前提是用戶端在比對時能取得目標網域。DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD 的差別主要在涵蓋範圍，而非哪一種「比較強」。選擇規則時，應先寫清楚希望涵蓋的對象，再採用範圍最小且足夠的條件，避免為了少寫一行而造成難以察覺的誤比對。

DOMAIN：限定單一完整網域

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

DOMAIN 用於比對完整網域。第一條只表示處理 login.example.com，不會自動涵蓋 example.com 或 cdn.login.example.com。適合將登入入口、API 網域等分開處理。規則條件中應填寫網域，不要附加通訊協定標頭、連接埠或路徑；填入完整網頁網址，也不會讓這條網域規則變成路徑規則。

如果只想變更某一項 API 請求，而同一網域下的其他路徑維持原狀，DOMAIN 本身無法表達這種細緻度。應先確認是否真的需要依路徑處理，不能只在網域後面加上斜線。網域規則選擇的是連線策略，不會因為條件填入登入網域，就自動處理登入流程中涉及的其他相依網域。

DOMAIN-SUFFIX：涵蓋根網域與子網域

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

DOMAIN-SUFFIX 用於比對網域後綴的邊界。此處的 example.com 涵蓋根網域及其子網域，例如 www.example.com 與 a.b.example.com；只要在任意位置出現相同字元，並不代表符合。notexample.com 不在此網域邊界內，example.com.other.test 也不是它的子網域。

範例中，portal 的精確例外規則排在前面，因此先套用 DIRECT；其餘屬於 example.com 的網域才會由後綴規則交給 PROXY。若將後綴規則放在第一行，portal 例外便沒有機會生效。由此可見，精確規則不會自動取得較高優先順序，是否先檢查仍由排列位置決定。

DOMAIN-KEYWORD：涵蓋範圍較廣

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

DOMAIN-KEYWORD 用於比對網域中的關鍵字。它可能涵蓋 example.com，也可能涵蓋 myexample.test。如果實際需求是處理某一網域及其子網域，關鍵字通常比後綴規則涵蓋更廣，可能連名稱中恰好含有相同字元的其他網站也一併處理。關鍵字只有幾個常見字母時，誤比對尤其難以追查。

因此，建議先用 DOMAIN 表達單一目標的例外，再用 DOMAIN-SUFFIX 表達明確的網域集合。只有確實需要依名稱片段分類多個沒有共同後綴的網域，且已檢查可能涵蓋的範圍時，才考慮使用 DOMAIN-KEYWORD。不要用關鍵字取代網域清單的維護，否則日後很難說明某項請求為何被歸類。

網域條件的邊界與缺漏

網頁通常會同時請求主網站、靜態資源、身分驗證、API 等多個網域。主網站符合預期規則，不代表頁面中的所有資源都使用相同策略。若頁面框架正常，但圖片或登入失敗，應依實際失敗請求的網域檢查，而不是繼續為主網域重複新增規則。處理第三方相依項目時也應依據記錄，不要猜測後再擴大範圍。

直接連線至位址時可能沒有可用網域，此時網域規則便缺少比對條件。加密流量中能取得哪些網域資訊，也取決於實際連線情況，不應假設所有請求都能還原原始名稱。若記錄只顯示位址，應改查位址規則，而不是把位址偽裝成 DOMAIN 條件。術語說明可參閱名詞解釋。

GEOIP、IP-CIDR 與 USER-AGENT

目標以位址形式出現，或分流需求確實取決於位址歸屬時，可使用位址類規則。這些規則與網域規則並列參與比對，不會自動排在網域規則之後。USER-AGENT 則依據可見的請求標頭資訊，比對條件又不同。將這些類型放在同一份列表時，必須分別了解各條件的資訊來源，否則容易把缺少輸入資訊誤判為語法問題。

IP-CIDR 與 IP-CIDR6

[Rule]
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
IP-CIDR,198.51.100.8/32,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

IP-CIDR 用於描述 IPv4 位址範圍。斜線後的數字是網路前綴長度，不是連接埠，也不是優先順序。/32 對應單一 IPv4 位址，/24 則對應更大的位址區塊。IP-CIDR6 用於描述 IPv6 範圍，單一位址可使用 /128 表示。範例中的位址僅供文件說明，不能當成實際服務目標來驗證連線。

前綴越短，通常涵蓋範圍越大。不要為了「確保包含目標」而任意擴大網段，因為這可能讓與目標無關的連線一併改道。撰寫前先確認實際位址，再確認網路邊界。若位址來自某次網域解析，也要考慮該網域日後是否會回傳其他位址；單次解析結果不代表服務長期使用的所有位址範圍。

GEOIP：依據位址資料庫判斷

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

GEOIP 會依據位址資料庫中的地區分類進行比對。範例表示先處理明確的網域例外，再讓歸類為 CN 的目標位址使用 DIRECT，其餘則交由 FINAL。地區分類不等於網域註冊地、內容語言或服務所屬機構，也不能代表連線速度。資料庫更新與實際網路配置可能存在時間差，跨地區部署與位址變動也會使直覺判斷與資料庫結果不同。

重要目標若無法只靠地區分類穩定處理，可在 GEOIP 前加入更明確的網域或位址例外，並記下原因。不要在沒有觀察結果的情況下頻繁切換整體地區策略。若使用 GEOIP,CN,DIRECT,no-resolve，也要考慮前一章所述的解析限制：沒有可用位址時，這條規則可能無法完成預期判斷。

USER-AGENT 的適用範圍

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

USER-AGENT 用於檢查用戶端可讀取的 User-Agent 請求標頭。範例以萬用字元表示以 ExampleClient 開頭的值，僅說明規則結構，不對應任何實際應用程式。它不是依系統 App 名稱分流的通用機制，也無法從加密連線中自動取得任意請求標頭。App 顯示名稱、程序名稱與 User-Agent 可能完全不同，不能互相替代填寫。

對於 HTTPS，一般連線處理通常無法直接讀取已加密的 HTTP 請求標頭，因此不要將 USER-AGENT 當成涵蓋所有 App 流量的依據。本頁範例不要求為此新增憑證或擴大解密範圍。若無法確認標頭是否可見，優先採用可驗證的網域或位址規則；若目標原本就沒有該請求標頭，這類規則同樣缺少比對輸入。

先選擇表達方式，再處理例外

維護業務網域時，優先考慮網域條件；維護固定位址範圍時，考慮 IP-CIDR；依位址資料庫分類時使用 GEOIP；只有確認請求標頭可讀，而且確實需要依標頭區分時，才考慮 USER-AGENT。規則類型不是越多越完整，同一目標堆疊多條條件只會增加理解成本，尤其是不同條件對應不同策略時。

驗證位址規則時，應一併記錄位址族、實際目標位址與命中規則。同一網域在某次測試中使用 IPv4，另一次使用 IPv6，可能因此符合不同規則。對照測試應盡量維持相同網路與目標；若需新增 IPv6 例外，也應以確認過的範圍為依據，不要用統一處理所有 IPv6 請求來掩蓋局部設定問題。

策略、Global Routing 與優先順序

規則條件回答「是否符合」，策略回答「符合後如何處理」。PROXY、DIRECT 與 REJECT 是本頁範例使用的三種基本策略。它們與 Home 中的 Global Routing 並非同一層：Global Routing 決定採用設定分流或全域模式，Rule 中的策略則在設定分流過程中為單一連線指定處理方式。排錯時必須先看外層模式，再看內層規則。

三種策略的實際意義

使用 PROXY 的前提是已有可用的伺服器資訊，並選取有效出口。若出口驗證失敗，符合 PROXY 的規則仍可能正確，只是後續連線無法完成。DIRECT 不代表請求必定成功，也不代表請求不受任何系統網路條件影響。REJECT 是明確拒絕，適用於確實需要阻擋的條件；不要將範圍寬廣的關鍵字直接設為 REJECT，再把資源缺漏當成伺服器故障。

Global Routing 的三種模式

設定模式對應 Config，依目前設定進行分流；代理模式對應 Proxy，用於全域代理處理；直連模式對應 Direct，用於全域直接連線。核對規則時應切回 Config。若一直處於 Proxy 或 Direct，單純調整 Rule 並不能證明規則是否按預期運作。模式切換應作為診斷步驟，而不是長期取代正確規則。

本頁討論的是進入用戶端處理路徑後的分流。系統層級的網路處理與 General 中的略過範圍仍可能影響實際涵蓋範圍，因此不要把「全域」解讀為所有系統流量必定經過相同路徑。測試對象應是可觀察的具體請求，不能只看狀態列是否出現連線標示，就推斷每個目標都採用預期策略。

由上而下檢查，首次符合即結束

[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

Rule 列表通常由上而下檢查，首次符合後即採用對應策略，不會繼續尋找「更精確」的規則。上例將單一網域例外排在後綴規則之前，將明確位址範圍排在地區規則之前，最後才設定兜底。此處排列反映的是作者意圖，不是引擎替作者計算精確度排名。同一目標若符合兩條規則，會先由排在前面的規則產生結果。

FINAL 不是一般的條件規則

FINAL,PROXY 只有類型與策略，用於處理前面都未符合的請求，不必再填寫網域。若將它放在中間，後續規則便無法處理其餘請求。維護時應確認只保留預期的末尾兜底規則，不要因合併檔案而產生多個 FINAL。末尾使用 PROXY 或 DIRECT，應依設定目的、現有網路與存取需求決定，而不是認定其中一種天生正確。

重新排列規則前，可先在紙上推演優先順序：選取一個具體網域，從第一行開始逐條判斷，遇到第一個符合項目即停止。再以一個不在清單中的目標重複推演，確認它會進入 FINAL。若推演結果與實際記錄不同，應檢查目前使用的檔案、模式與可用輸入資訊，不要先假設比對引擎會依關鍵字長度或網域層級自動排序。

Host 與 URL Rewrite 的差異

Host 與 URL Rewrite 都可能改變存取結果，但處理對象完全不同。Host 指定網域與位址的對應，URL Rewrite 則依 URL 運算式執行相應處理；兩者都不等同於 Rule 中的策略選擇。若請求連到非預期位址或跳轉至另一個 URL，應分別檢查解析對應、重寫結果與分流規則，不能只在 Rule 中尋找原因。

Host：指定解析對應

[Host]
fixed.example.com = 192.0.2.10
service.example.com = 198.51.100.20

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

此處兩筆 Host 記錄示範將完整網域對應至指定位址，位址仍為文件範例值。第一條 Rule 另行決定 fixed.example.com 使用 DIRECT，說明「對應到哪裡」與「如何連線」必須分別設定。填入 Host 不代表該網域一定會直連；同樣地，DOMAIN 指向 PROXY 也不會自動修正錯誤的位址對應。

固定對應可減少對一般 DNS 回應的依賴，但也會失去服務動態調整位址的彈性。若服務採用動態部署或多地區連線節點，長期固定某次解析取得的位址可能逐漸失效。只有在用途已確認且能持續維護時才適合使用。若出現部分網路可連線、部分網路失敗的情況，應將 Host 作為單一變因移除並進行對照，而不是直接替換所有 DNS 設定。

Host 不會變更憑證身分

將網域對應至某個位址，不會讓該位址上的服務自動擁有正確的網站設定或有效憑證。HTTPS 仍會驗證與存取網域相對應的身分，伺服器也可能依請求中的名稱選擇不同網站。對應後若出現憑證錯誤，應檢查目標位址是否確實提供該網域的服務，不應透過忽略身分驗證來掩蓋位址填寫錯誤。

同樣地，Host 不是網頁重新導向工具。存取列中的網域通常不會只因位址對應就變成另一個名稱。若要了解瀏覽器為何跳轉至新頁面，應檢查伺服器回應或 URL Rewrite，而不是混淆位址變更與可見 URL 變更。維持這種分層思維，才能避免用錯誤機制處理表面相似的問題。

URL Rewrite：先了解運算式與動作

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

範例會將符合條件的 HTTP URL 重新導向至對應的 HTTPS URL。左側是正規運算式，^ 限定起點，網域中的句點以反斜線跳脫，(.*) 則擷取後續內容；中間是替換目標，$1 代表第一組擷取內容；末尾的 302 表示暫時重新導向。這不是將目標網域交由 PROXY 處理的語法，也不等於為伺服器設定 HTTPS。

撰寫運算式時，應限定通訊協定與網域邊界。未跳脫的句點代表任意字元，缺少起點或結尾邊界則可能擴大比對範圍。測試至少應包含根路徑、含查詢參數的路徑，以及不應符合的相似網域，確認擷取內容沒有被截斷或重複串接。不要將含私人查詢參數的實際 URL 貼到共用筆記中，範例統一使用 example.com。

可見範圍與重新導向迴圈

URL Rewrite 必須能辨識相應的 URL 資訊。一般加密連線不代表完整路徑自然可讀，不應假設 HTTP 範例會自動涵蓋所有 HTTPS 內容。本章不要求擴大解密範圍。若規則始終未觸發，先檢查輸入 URL 是否可見，再檢查運算式；直接將正規運算式擴大至所有網域只會增加風險，無法補足缺少的資訊。

若目標位址又被另一條規則改回原位址，就可能形成重新導向迴圈。瀏覽器記錄通常會呈現反覆跳轉，而非單次逾時。排查時可暫時停用新增的 Rewrite，確認原始請求恢復，再逐條加入並對照。Host、Rewrite 與 Rule 應分開測試，每次只變更一種機制，並保留原始 URL、最終 URL 與命中結果供比較。

規則組合、合併與設定維護

易於維護的設定檔，關鍵不在規則數量，而在於每一層條件都有明確用途。常見的組織方式是：明確的單一目標例外在前，其次是業務網域集合，再來才是必要的位址與地區條件，最後統一兜底。這種「常見」方式並非固定標準；設定目的不同時可以調整層級，但必須能說明任一具體請求為何得到目前結果。

從最小可驗證片段開始

[Rule]
# 單一目標例外優先於網域集合
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY

# 僅處理已有可用位址的目標
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve

# 地區判斷後統一兜底
GEOIP,CN,DIRECT
FINAL,PROXY

此範例只說明規則層的組織方式，不包含伺服器與驗證資訊。先確認 portal 是否使用 DIRECT，再檢查相同後綴下的其他網域是否使用 PROXY，最後確認無關網域是否依位址分類或進入 FINAL。文件範例位址不能作為實際測試伺服器，請以自己已掌握且有權存取的測試目標替換相應條件。

新增 REJECT 時，也應採用相同的最小原則。可先限定一個已確認不會影響主要功能的完整網域，再透過實際記錄驗證請求確實屬於預期對象。不要為了減少請求數量就直接拒絕整個業務網域範圍。看似只提供靜態資源的網域，也可能負責身分驗證或頁面初始化；誤拒絕通常會造成局部異常，而非完全斷線。

合併前先處理重疊條件與終止規則

直接將兩份檔案首尾串接，容易產生重複區段、互相衝突的策略，以及位於中段的 FINAL。合併時先整理成一份明確的 Rule 列表，再檢查各規則的位置。相同條件若重複出現且策略一致，通常只會增加維護負擔；若策略不同，後面的規則可能長期沒有機會符合，卻會讓讀者誤以為兩種處理方式都在生效。

不能只靠文字去重來判斷衝突。DOMAIN 與 DOMAIN-SUFFIX 雖然內容不同，也可能涵蓋相同目標；IP-CIDR 與 GEOIP 也可能在位址範圍上重疊。應選取幾個代表性目標逐條推演，確認例外仍排在寬泛條件之前。合併完成後只保留一個預期的兜底規則，並重新確認所有策略名稱都能在目前的設定環境中解析。

遠端更新與本機修改的範圍

既有訂閱更新主要涉及伺服器項目，遠端設定更新則可能涉及 Rule、General 等文字內容，兩者不能視為同一件事。若更新後行為改變，應先確認更新的是哪種內容。伺服器列表變更可能影響出口選擇，規則文字變更則可能改變比對路徑。分別保存更新前後的檔案，通常比憑記憶回想更容易找出真正差異。

長期使用時，建議將已驗證的本機修改另存為獨立副本，並記錄來源、目的與還原方式。更新遠端內容前先確認是否會覆蓋該檔案，不要假設所有本機新增內容都會自動保留。關於匯入入口與訂閱更新的差異，可參閱Subscribe、Add Server、掃描 QR Code 與剪貼簿匯入說明。

註解應記錄原因與撤銷條件

有效的註解不只是重述規則，而是說明為何需要例外、如何驗證，以及何時可以撤銷。例如記錄「此 API 需與主站使用相同出口，測試時核對登入與後續 API」，比只寫「API 規則」更有幫助。註解中不要保存訂閱驗證資訊、完整私人連結或伺服器密碼；尋求協助時，應先將設定文字中的敏感資訊遮蔽。

每次變更都應留下簡短記錄：變更條件、原先結果、預期結果與實際結果。新增規則若未改善目標問題，應先撤銷，再嘗試其他變數，不要讓無效修補長期留在列表中。規則維護的目標，是讓日後能再次說明目前行為，而不是讓檔案累積越來越多、無從追溯的例外。

命中驗證與連線排錯

規則問題與連線問題常會同樣表現為頁面無法開啟，但處理方式不同。排查規則時，先確認請求是否進入預期策略；排查連線時，則檢查該策略對應的網路路徑是否可用。應分別記錄「目前連線狀態」、「命中條件」與「出口連線結果」。VPN 開關已開啟，只表示設定連線已啟動，不足以證明伺服器、DNS 與目標服務都正常。

建立可重複的測試條件

開始前記錄網路類型、Global Routing 模式、目前設定檔名稱、選取的伺服器，以及一個明確的測試目標。先用既有設定驗證基本連線，再進入 Config 檢查目標規則。每次測試盡量重新發起連線，避免應用程式沿用舊工作階段。不要同時開啟多個相似頁面比較體感速度，應優先確認是否有實際請求符合預期策略的證據。

Connectivity Test 可協助觀察既有伺服器的連線狀況，但結果只適用於該次測試條件，不代表所有網域與各種協定請求都能成功。伺服器測試通過後，目標網站仍可能因 DNS、分流、伺服器端限制或位址族不同而連線失敗。因此，伺服器測試通過只是檢查項目之一，不能因此略過規則驗證。

未命中預期規則時的檢查方式

1. 確認 Global Routing 設為 Config，且 Config 中選取的確實是剛編輯的檔案。
2. 檢查請求實際使用的網域或位址，不要以瀏覽器網址列代替所有資源請求。
3. 從列表頂端往下檢查是否有更早符合的寬泛條件、重複條件或提前出現的 FINAL。
4. 核對英文逗號、區段名稱、策略名稱，以及 no-resolve 對輸入條件的影響。

如果記錄中只看到位址，先確認網域是否確實無法取得，再檢查 IP-CIDR 或 GEOIP。若符合了非預期的 DOMAIN-KEYWORD，應考慮縮小關鍵字涵蓋範圍。若規則根本未參與處理，也應回頭檢查 General 的略過設定。不要一開始就刪除整份設定檔，以免失去有助於解釋問題的原始條件。

已符合正確策略但仍然失敗

PROXY 路徑失敗時，可在規則不變的前提下，使用自己已有的其他有效出口進行對照；若更換後恢復，問題較可能出在原出口或其連往目標的路徑。DIRECT 路徑失敗時，先檢查同一網路下的系統存取情況。對照過程中，記錄每次只變更了哪一項，避免將網路波動與設定修改混為一談。

局部資源失敗與設定還原

登入、圖片、影片或 API 失敗時，先檢查對應請求，不要假設它們與主頁面共用網域和連線。也應確認 REJECT 是否阻擋相依項目，以及不同網域是否被安排到彼此不相容的出口路徑。若新增設定後才出現問題，先還原基準版本確認是否相關，再逐條恢復修改，比繼續新增修補更容易找出原因。

整理問題記錄時，只保留設定片段、已遮蔽敏感資訊的目標名稱、命中規則與錯誤現象。移除驗證參數、私人訂閱網址與敏感請求內容。協定參數不相符的問題可繼續參閱VMess 與 VLESS 欄位差異；常見連線現象可前往常見問題依分類核對。不要把驗證故障當成規則關鍵字故障。

完成驗證後，恢復平時使用的 Global Routing 模式，儲存已確認有效的設定，並撤銷臨時 Host、Rewrite 或測試規則。若要重新依完整流程開始使用，請返回使用說明，逐步核對匯入、出口選擇、VPN 設定授權與連線驗證。系統需求、裝置相容性及應用程式取得資訊，請以 App Store 頁面標示為準。