Shadowrocket
規則與設定參考

設定結構與 General

設定檔用來描述請求如何解析、比對及處理；伺服器資訊則提供實際連線參數，兩者不能互相取代。即使檔案中寫有 PROXY，也不代表已有可用伺服器；反過來，匯入伺服器也不表示某份規則檔正在生效。開始修改前，先在 Config 確認目前使用的設定，再到 Home 確認連線對象，分別記下「使用哪份規則」與「連線至哪裡」。

四個區段各自的用途

方括號標題用來區分設定區段。[General] 放置一般選項，[Rule] 放置依序檢查的分流規則，[Host] 放置名稱與位址的靜態對應，[URL Rewrite] 放置符合條件的 URL 改寫或重新導向。這四者並非可以互相取代的規則：網域應採用哪種策略，通常在 Rule 中設定；網域應解析至哪個位址，則屬於 Host 或 DNS 的問題。

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

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

[Host]
example.com = 192.0.2.10

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

這段文字僅示範區段與語法，不是可直接啟用的完整設定。example.com 是示範網域，192.0.2.10 是文件範例位址；此處以 Host 和 URL Rewrite 說明格式，不代表兩者必須同時啟用。練習時先保留 General 與少量 Rule，確認基本連線正常後，再分別加入需要驗證的區段，避免範例彼此影響。

依用途理解一般選項

dns-server = system 表示使用系統 DNS 設定，適合作為檢查目前網路行為的起點，但不能據此斷定每一個遠端請求都由同一個本機解析器處理。伺服器協定、連線方式與實際請求路徑都會影響最終的解析位置。遇到解析異常時，應同時查看請求記錄中的網域與目標位址，而不是只憑這一行判斷整條連線路徑。

bypass-system = true 是系統相關流量的略過選項，不等同於「所有本機位址都直連」，也不能取代明確的 IP 網段規則。它涉及系統流量的處理範圍，修改後可能影響可觀察到的請求。若只是要讓某個區域網路網段使用 DIRECT，應先在 Rule 中設定該網段，再驗證實際請求，不要順手更動無關的 General 欄位。

儲存、生效與遠端更新是三種不同操作

在編輯器中成功儲存，只能表示內容已寫入，不能證明該檔案已被選用。修改後返回 Config，確認目前使用的設定，再確認 Global Routing 設為 Config。對於遠端維護的設定，也要區分本機修改與上游檔案：重新更新可能會覆蓋本機內容。需要長期保留的自訂規則應另外備份並記下插入位置，不要只把唯一副本留在可能遭更新取代的文字中。

排查設定時，先儲存一份可還原的原始內容，再一次只修改一個欄位。記下修改前的網路環境、Global Routing、測試網域與預期策略；修改後以同一個請求重新驗證。若結果與預期相反，還原該欄位再測一次，比連續加入多個不明選項更容易找出原因。尤其不要把不同來源的 General 內容全部拼在一起，重複鍵或彼此牽制的設定會讓結果難以判讀。

Rule 與規則類型

Rule 的基本格式是「類型、比對內容、策略」，欄位之間以英文逗號分隔；FINAL 不需要比對內容，因此通常只有類型與策略兩個欄位。規則關鍵字應保留英文原文，網域欄位不要加入通訊協定、路徑或查詢參數。以下範例皆假設目前使用 Config，且 PROXY 已有可用的連線對象，否則即使比對正確，也不代表請求一定能成功。

DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD

DOMAIN 精確比對一個主機名稱，適合只處理單一子網域的情況。DOMAIN-SUFFIX 依網域後綴邊界比對，常用於根網域及其子網域；例如 example.com 的後綴規則也會涵蓋 api.example.com，但不應將它理解成任何以相同字串結尾的網域。DOMAIN-KEYWORD 依網域中的關鍵字比對，涵蓋範圍通常較廣，應額外檢查是否可能包含其他主機名稱。

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

依照這個順序，api.example.com 會先命中 DOMAIN，不會繼續套用後面的 DIRECT。其他屬於 example.com 的子網域則由第二行處理。只有前兩行都未命中的請求，且網域中含有 example，才可能由第三行處理。這組範例刻意使用重疊條件，並非通用建議；它用來說明同一個請求符合多條規則時，為何必須留意排列順序。

GEOIP 與 IP-CIDR

GEOIP 依目標 IP 在位址資料庫中的歸屬進行比對，例如 GEOIP,CN,DIRECT。它判斷的不是網頁語言、網站註冊地或使用者所在地。網域可能解析出不同位址，資料庫也有涵蓋範圍與更新上的限制，因此若同一網站在不同網路下採用不同策略，應先比較實際目標 IP，而不是直接認定規則失效。

IP-CIDR 表示 IPv4 位址與前綴長度。192.168.0.0/16 涵蓋相應的位址範圍，不是只比對 192.168.0.0 這一個位址；單一 IPv4 位址可用 /32 表示。IP-CIDR6 則用於 IPv6。使用 IP 條件時，若已有目標位址可直接進行判斷；對只有網域的請求，是否會為了比對而額外解析，則應搭配規則選項與實際記錄核對。

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

no-resolve 用來避免只為這條 IP 規則主動觸發網域解析，不表示忽略已可見的目標 IP，也不保證網域請求一定會命中這條網段規則。若透過主機名稱存取區域網路服務，可能還需要明確的 DOMAIN 規則。新增網段前也要確認是否與遠端資源位址重疊；位址範圍愈大，誤納入請求的可能性愈高。

USER-AGENT 與 FINAL 的適用範圍

USER-AGENT 用來比對可讀取的請求 User-Agent。它不能可靠地驗證應用程式身分，也不能據此認定所有加密請求都能辨識出應用程式名稱。請求是否包含此欄位、欄位是否可見，以及內容是否變動，都會影響結果。若要穩定處理一組主機，應優先核對網域條件；不要只因某條 USER-AGENT 規則未命中，就擴大到未經確認的流量範圍。

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

FINAL 是前面的規則都未命中時使用的預設策略，通常放在 Rule 最後。它不是錯誤處理規則，伺服器連線在前面的規則命中後失敗時，不會自動改由 FINAL 接手。將 FINAL 提前，等於讓後面的普通規則失去被檢查的機會。檢查較長的設定時，先找出 FINAL，再確認希望執行的規則都排在它前面，通常比從第一行逐字檢查更快。

Host 與解析範圍

Host 處理的是「名稱對應哪個位址」，Rule 處理的是「請求採用哪種策略」。在 Host 指定位址，不等於指定 DIRECT，也不等於已繞過伺服器或網路限制。判斷一項對應是否符合需求，至少要分別核對三件事：實際請求的主機名稱、對應後的位址，以及最終命中的策略。只看到位址改變，還不足以證明整條連線都正確。

靜態對應的最簡寫法

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

左側是主機名稱，右側是位址。範例位址僅供文件說明，不對應可用的服務。使用實際對應前，應從自己管理的網路或既有服務資料確認位址，不能只根據一次查詢結果就認定它長期有效。這裡逐一列出特定名稱，也有助於避免將精確名稱對應誤解為涵蓋整個網域的分流規則；需要處理哪些主機，就分別檢查哪些主機的解析結果。

對應只會修改位址資訊，不會自動將網頁原本的主機名稱改成另一個名稱。對 HTTPS 而言，憑證驗證與伺服器端的主機識別仍然重要。即使目標位址可以建立連線，若該位址沒有為原主機名稱提供正確服務，仍可能發生憑證不符、顯示錯誤網站或連線中止。遇到這類情況，應先移除對應並比較結果，不要以降低驗證要求來掩蓋位址錯誤。

Host 不等於固定整個網站

一個頁面通常會連線至多個主機：入口文件、圖片、介面、登入與靜態檔案可能使用不同名稱。只對應入口主機，不能推定其他資源也使用相同位址。若頁面主體能開啟但內容缺漏，請從請求記錄找出失敗資源實際存取的主機，再判斷是否與對應有關。不要為了補齊頁面就盲目擴大對應範圍，更不要將所有子網域都指向同一個未經確認的位址。

靜態位址也會改變 DNS 原本提供的負載平衡。原始解析結果可能隨網路、地區或服務狀態變動，固定至某個位址後，這些變化不會自動反映在本機對應中。短期排錯時，對應可用來確認某個解析結果是否有問題；若要長期保留，則需要明確的維護依據。對於自己無法管理且位址會變動的服務，通常不應將靜態對應當成永久修復方式。

分別檢查 DNS、快取與請求路徑

修改 Host 後立即重新整理舊頁面，觀察到的可能仍是重用既有連線，而不是全新建立的請求。應用程式、系統與網路連線路徑中也可能存在快取。驗證時先記下修改前的位址，再關閉相關頁面或結束舊請求，以相同主機名稱重新連線，然後檢查新記錄。若記錄沒有變化，應確認目前設定是否生效、請求是否經過預期路徑，而不是一再儲存同一行。

有些連線會在遠端解析網域，某些應用程式也可能自行解析或直接使用 IP。因此，「在 Host 中寫入主機名稱」不代表「每條連線都會使用這項對應」。應依實際連線類型觀察名稱與位址在哪個環節可見。對於直接存取 IP 的請求，本來就沒有相應的網域查詢流程，繼續新增網域對應通常不會改變其目標。

完整的 Host 實驗應一次只修改一個主機，明確設定預期位址，並保留還原記錄。若移除對應後故障消失，表示對應至少與問題有關，但仍需分辨是位址失效、憑證不符還是存取路徑不通。確認原因後再決定是否保留，避免把臨時診斷項目留在長期設定中，數週後遇到位址變動時無從追查。

URL Rewrite

URL Rewrite 依 URL 運算式處理符合條件的請求，常見用途是將明確的 HTTP 網址重新導向至 HTTPS。它不是 DOMAIN 規則的另一種寫法，也不能取代 PROXY、DIRECT 或 REJECT 的策略選擇。設定前應先釐清目的：是要變更存取網址，還是只改變連線路徑；若只是希望某個網域採用不同策略，通常應修改 Rule，而非新增重新導向。

先從範圍明確的重新導向開始

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

這個範例由比對運算式、目標 URL 與狀態碼組成。開頭的 ^ 限定從字串起始處比對，結尾的 $ 限定比對至字串結尾；\. 表示網域中的實際句點，避免將一般的正規表示式句點當成任意字元。範例只比對指定主機的 HTTP 根路徑，並使用 302 重新導向，不涵蓋該主機的所有路徑或查詢參數。

選擇如此精確的運算式，是為了讓測試結果更容易判讀。若運算式只寫到網域而未限制後續內容，可能涵蓋更多路徑；若又將目標固定為根路徑，還可能遺失原請求中的服務路徑與查詢資訊。若需保留特定部分，應先分別列出根路徑、子路徑與查詢參數三種請求，再設計並驗證運算式，不要從範圍過大的比對條件開始反覆嘗試。

適用範圍取決於請求是否可見

HTTP URL 與加密連線中的完整 URL，並非相同的可見條件。看得到目標網域，不代表也能讀取 HTTPS 請求的路徑、查詢參數或 User-Agent。加密流量是否具備處理相關內容的條件，必須另外確認。本文範例從明確的 HTTP 請求開始，不需要為了讓某條改寫生效而調整憑證信任或擴大解密範圍。

瀏覽器也可能依既有安全政策，先將 HTTP 升級為 HTTPS，使實際送出的請求與網址列最初輸入的內容不同。此時沒有看到預期的 302，不能單憑這點判定運算式有誤；應先確認是否真的送出了符合條件的 HTTP 請求。存取工具、瀏覽器歷程與網站本身的跳轉都會影響觀察結果，測試記錄應包含最初請求及後續請求鏈。

重新導向後會送出新的請求

收到重新導向後，用戶端通常會向目標 URL 發出新的請求；新請求需要再次解析位址並接受規則處理。原請求命中的分流規則，不代表目標請求必然採用完全相同的處理方式。若重新導向後的目標使用不同主機名稱，尤其要檢查新主機是否被另一條 DOMAIN 或 DOMAIN-SUFFIX 規則涵蓋，以及解析與連線是否正常。

重新導向迴圈通常來自互相衝突的條件，例如本機規則將網址導向 HTTPS，而伺服器又將同一入口送回原本的 HTTP 網址。可能出現不斷跳轉、載入失敗或瀏覽器顯示重新導向次數過多。遇到這種情況，應先停用新增的改寫規則，確認原網站行為，再檢查每一步返回的目標。不要只靠新增更寬泛的改寫規則來掩蓋症狀，否則更難找出迴圈來源。

涉及登入、表單或含有臨時憑證的 URL 時，應格外謹慎。查詢參數可能包含敏感資訊，對外分享測試記錄前應先移除；請求方法與重新導向狀態碼之間的互動，也不能只憑網址變化推斷。初次驗證應選擇自己可控制且未登入的普通頁面，確認運算式只處理預期請求後，再評估是否適用於實際情境。

策略與 Global Routing

策略說明命中後如何處理請求，Global Routing 則說明目前採用哪種整體路由模式。排查時應先檢查 Global Routing，再查看規則中的策略欄位；否則即使逐字檢查 Rule，也可能一直在驗證目前並未依預期參與處理的設定。中文說明可稱為設定、代理、直連，對應的介面詞分別是 Config、Proxy、Direct。

PROXY、DIRECT、REJECT

PROXY 表示透過代理路徑處理，需要已有可用的連線對象。它不是具體的伺服器位址，也不會自動補齊驗證資訊。DIRECT 表示直接連線至目標，但「直接」不代表目標一定可達；目前網路的路由、DNS 與目標服務狀態仍然會影響結果。REJECT 表示拒絕相應請求，適合用於明確需要阻擋的目標，不能誤認為失敗後會再嘗試其他路徑。

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

範例中的名稱用來說明三種處理方式。api.example.com 命中後使用 PROXY；即使連線失敗，也不會因失敗而自動嘗試下一行的 DIRECT。printer.example.com 則直接連線，是否成功仍取決於解析位址及目前網路是否可達。blocked.example.com 遭明確拒絕後出現失敗，是策略預期的結果，不應再歸類為伺服器故障。

如何對照三種整體模式

在 Proxy 下可以存取、在 Config 下卻失敗，表示應繼續檢查 Config 下實際命中了哪種策略，但不能立刻斷定某個規則關鍵字有誤。兩種模式可能讓請求採用不同的解析位置、目標位址或連線路徑。可靠的對照測試應同時記錄主機、實際位址與處理策略，確認差異從哪一步開始，而不只是記下頁面最後有沒有開啟。

在 Direct 下失敗、Proxy 下成功，也不代表應將整份設定都改成 PROXY。區域網路裝置、僅對目前網路開放的服務及其他特定資源，仍可能需要 DIRECT。暫時切換 Global Routing 有助於縮小問題範圍；長期策略則應了解資源需求後寫入 Rule。完成對照後應恢復原有模式，避免之後以錯誤模式判斷新規則。

分別核對策略名稱與實際連線能力

部分設定會引用自訂策略名稱。閱讀這類檔案時，不要把看起來像英文標籤的值都當成內建策略；應確認該名稱是否已在目前設定中定義、指向哪個連線對象，以及該對象是否仍存在。若只需要學習基礎分流，先用 PROXY、DIRECT、REJECT 理清流程，比同時加入複雜的選擇關係更容易核對。

連線對象失效時，規則仍可能正常命中。例如驗證資訊已變更、伺服器位址暫時無法連線，或伺服器端不支援目前參數，都可能造成「策略選對了但連線失敗」。此時繼續調整 DOMAIN 的比對範圍無法修復伺服器。應先依據已有的服務資料核對位址、連接埠與驗證資訊，再執行 Connectivity Test，並分別記錄測試結果與實際服務請求的結果。

同樣地，連線測試成功只代表測試涵蓋的部分路徑收到回應，不保證所有目標、協定與服務操作都能成功。網頁請求、長連線及其他傳輸方式可能各有不同條件。若只有某項服務失敗，應先找出該服務使用的主機與請求類型，不要因一次測試成功就完全排除伺服器端或目標端問題。

既有訂閱中的伺服器與本機規則，是兩種不同的維護對象。更新訂閱可能改變可選的連線對象，不代表本機規則順序已修正；編輯 Rule 也不會更新已過期的伺服器參數。關於更新方式的差異，請參閱訂閱更新與失敗原因，避免混淆伺服器資料變動與設定檔變更。

比對順序與優先級

Rule 的核心順序是由上而下檢查，首條命中規則決定策略。所謂「較具體的規則優先」是撰寫設定時的建議，並非自動排序機制。DOMAIN 不會只因為更精確，就跳過前面的 DOMAIN-SUFFIX；IP-CIDR 也不會自動讓位給後面的網域條件。若要達到預期的優先級，就必須在文字中將例外規則排在涵蓋範圍較廣的條件之前。

以同一個請求逐行推演

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

以 api.example.com 為例，第一行已精確命中，因此後面的網域後綴、關鍵字、位址歸屬與 FINAL 都不再決定該請求的策略。以 www.example.com 為例，第一行不符合，第二行的後綴規則命中後採用 DIRECT。只有前兩行都未命中，第三行的關鍵字規則才有機會生效。逐行推演時，應將「是否符合條件」與「命中後採取的動作」分成兩欄，避免憑關鍵字的直覺跳過規則。

若將第二行移到第一行之前，api.example.com 就會先被後綴規則攔截，原本的精確例外也就失效。改變的不是 DOMAIN 的比對能力，而是檢查順序。了解這一點後，遇到「新增規則完全沒效果」，應先往上檢查是否已有規則涵蓋該請求，而不是在檔案末尾反覆加入相同條件。

如何安排寬泛與精確規則

常見寫法是先放明確的例外，再放網域集合或較廣泛的條件，接著放需要的 IP 規則，最後保留 FINAL。但這只是方便維護的排列方式，並非所有情境都必須套用的固定順序。若某個受控網段必須優先直連，就可能需要排在相關的廣泛條件之前；關鍵是先說明需求，再對照具體請求判斷條件是否重疊，而不是機械式套用同一種排列。

同一個目標可能同時符合網域條件與 IP 條件。例如，網域屬於指定後綴，解析後的位址又落在某個 GEOIP 範圍。最終採用哪條規則，取決於實際可取得的資訊及規則順序。為 IP 規則加上 no-resolve 後，也要考慮只有網域時是否會進行額外解析；不能將文字中的先後順序與請求當下尚不可用的資訊混為一談。

FINAL 不是第二次機會

FINAL 只處理前面規則都未命中的請求。某條規則已選擇 PROXY，之後伺服器連線失敗，並不代表「未命中」，因此不會回到 Rule 繼續尋找 DIRECT 或 FINAL。若需要備援連線能力，應檢查相關連線或策略設定實際支援的方式，而不是重複新增 FINAL 來期待錯誤自動恢復。Rule 負責選擇策略，連線失敗則發生在選擇之後。

排查時也要分清「未命中預期規則」與「命中預期規則但執行失敗」。前者應檢查主機、類型、順序及目前設定；後者則應檢查連線對象、解析位址與目標服務。若混淆這兩類結果，可能一邊修改分流範圍、一邊意外改變請求路徑，最後雖然某次成功，卻無法解釋真正原因。

維護較長的規則清單時，可為每個例外記下它涵蓋的廣泛規則及保留原因。刪除重複內容前，應比較完整欄位，而不只是網域；相同網域搭配不同策略、相同網段搭配不同選項，都不一定是無意義的重複。整理後，再用事先選定的代表請求進行測試，至少包含一個精確例外、一個一般子網域，以及一個應由 FINAL 處理的目標。

常見寫法與修改流程

以下依需求拆分設定片段。每段只呈現一個主要目的，不代表合併所有片段後就適用於任何網路。使用前應換成自己需要處理的目標，保留既有伺服器資訊，並確認目前檔案中的其他規則是否會先行命中。若既有設定包含 FINAL，應將需要的例外安排在原本的末尾規則之前，而不是再附加一套互相重疊的結尾規則。

同一網域內的精確例外

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

需求是讓指定介面使用 PROXY，同一網域中的其他主機使用 DIRECT。關鍵是先精確、後廣泛。測試時分別存取 api.example.com 與另一個已確認存在的子網域，檢查兩者是否採用不同策略。不要只驗證介面能否使用就認定例外正確，因為整體 Proxy 模式也可能讓介面成功，卻無法證明後綴規則有參與處理。

若介面發生跳轉，或頁面還會呼叫其他網域，應繼續查看後續請求。第一個請求命中精確例外，只能證明這一個請求處理正確。需要多個獨立主機協同運作的服務，應依實際記錄逐一整理；不能把看得到的入口當成完整資源清單。擴大範圍前，也應確認新增的主機確實屬於所需服務。

分別處理區域網路網段與主機名稱

[Rule]
DOMAIN,printer.example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
FINAL,PROXY

此處分別設定主機名稱與位址範圍的直連需求。主機名稱使用範例名稱，實際使用時應填入自己管理環境中的名稱。使用 no-resolve 的網段規則，不代表所有網域都一定會經解析後比對，因此可另外明確設定區域網路名稱。測試前還要確認目前連線至可存取裝置的網路；DIRECT 不會替使用者建立通往其他區域網路的路由。

若相同位址範圍也用於其他受控網路，網段規則可能涵蓋不同用途的目標。尤其在多個網路使用重疊的私有位址時，不能只因位址「看起來像內網」就決定處理路徑。應先列出需要存取的裝置、實際網路與目標位址，盡量縮小至必要範圍；若只涉及單一裝置，可考慮使用更精確的前綴，而不是一開始就涵蓋大段位址。

依位址歸屬分流並設定末尾預設規則

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

這段設定包含一個精確例外、一個位址歸屬條件及一個預設規則，並不等同於依網站內容或語言分類。使用分散式位址的服務，解析至不同 IP 可能改變 GEOIP 的判斷結果；測試時應記錄實際位址，而不只是網址。若需求原本是針對一組確定的網域，使用明確的網域規則通常更容易說明，但仍應依自己的資源與網路條件決定。

將 FINAL 設為 PROXY 也有明確前提：使用者已有可用伺服器，且願意讓未被其他規則涵蓋的請求走這條路徑。若實際維護需求不同，可以選擇其他預設策略，但必須了解它會影響大量尚未明確列出的請求。調整 FINAL 的影響範圍較大，不能只根據單一頁面是否成功來評估，也應一併測試日常使用的代表性資源。

保留、編輯、驗證、回復

1. 儲存目前設定的原始內容，記下所選檔案、Global Routing 與連線對象。
2. 寫下一項可驗證的需求，例如「讓指定主機由 DIRECT 改為 PROXY」。
3. 搜尋既有規則，找出最早可能涵蓋該主機的條件，並決定插入位置。
4. 只修改一處並儲存，確認目前仍使用這份設定檔。
5. 建立新請求，核對命中規則、目標位址、策略與實際結果。
6. 結果不符時，還原原始內容，再以相同目標重新測試並保留差異記錄。

回復用的檔案不要與正在自動更新的來源混用。尤其在訂閱或遠端設定更新後，應重新確認自訂規則是否仍在預期位置，以及規則引用的連線對象是否已變更。更新完成只表示取得資料的動作已結束，不能取代功能驗證。若修改項目較多，分批保留可用狀態，比一次覆寫整份設定更容易找出問題從哪一步開始。

驗證與故障排除

驗證目的不只是確認連線開關已開啟，而是確認某個具體請求採用預期設定、命中預期條件，並透過相應路徑取得結果。建議固定一個測試目標，依「伺服器、Global Routing、DNS、規則、目標服務」的順序檢查。每完成一步，都記錄已確認的事實及尚未排除的因素；同一輪測試中不要同時更新訂閱、更換伺服器及修改 DNS。

從連線對象到實際請求

先核對使用者已有伺服器的位址、連接埠、驗證資訊與協定參數，再使用 Connectivity Test 取得基本連線狀況的線索。若測試失敗，先確認目前網路與服務資料，不必立刻重新排列 Rule。若測試有回應，再送出實際服務請求，觀察是否只有特定主機失敗。基本測試與服務請求並不相同；前者有回應，不能證明後者所需的所有路徑與參數都正確。

接著檢查 Global Routing。若目前為 Proxy 或 Direct，先記下狀態，再切換至 Config 驗證規則。若在 Config 下結果異常，查看實際請求的主機名稱與目標位址，確認與預先設定的測試對象一致。頁面可能會重新導向，也可能呼叫獨立介面；發生錯誤的主機未必就是網址列中的主機，不要只圍繞入口網域反覆新增規則。

透過記錄區分三類失敗

第一類是規則未如預期命中：目前設定可能不正確、比對內容可能有誤，或上方規則已先行處理。第二類是策略正確但連線失敗：應檢查伺服器是否可連線、位址及目標服務。第三類是解析異常：應比較網域是否取得位址、位址是否符合預期，以及 Host 是否覆寫了解析結果。將三類情況分開後，通常就能大幅縮小需要修改的範圍。

如果記錄中出現 REJECT，先回到設定檔找出相應條件，判斷是否原本就要阻擋該目標。若記錄顯示 DIRECT，但目標資源只能透過既有遠端路徑存取，應核對策略設定；若顯示 PROXY，但伺服器驗證失敗，則應優先檢查已有的服務資料。錯誤訊息只能提供排查線索，不能取代對實際命中規則與連線對象的核對。

分開驗證 On Demand 與規則分流

On Demand 負責依條件觸發連線或中斷連線，Rule 則負責連線期間如何處理請求。自動連線未觸發時，不應先判定網域規則有誤；應檢查目前網路是否符合 On Demand 條件，以及連線是否確實建立。反過來，連線已建立也不代表所有請求都會採用 PROXY，因為 Config 仍可能將部分請求交由 DIRECT 或 REJECT 處理。

驗證自動行為時，先手動建立連線，確認相同設定能正確處理請求，再單獨測試網路切換後是否觸發。記錄切換前後的網路、連線狀態與請求時間，不要同時修改觸發條件與 Rule。特定情境請參閱On Demand 的 Wi-Fi、行動網路與網域條件；背景連線的取捨請參閱背景耗電與常駐連線說明。

常見核對問題

分享排查記錄前，應移除完整訂閱網址、驗證資訊、個人網路名稱及其他敏感內容。通常只需保留去識別化後的主機、規則類型、策略與錯誤階段，就足以說明問題。排錯完成後，請恢復暫時切換的 Global Routing，移除不再需要的 Host 或改寫測試項目，並再次儲存已驗證的設定。日後遇到類似故障時，先以這份基準狀態為對照，再逐項測試。