Shadowrocket 設定欄位與規則參考
從設定檔結構到規則命中結果，依欄位查語法、依現象找原因。本文以使用者已有自己的訂閱或伺服器資訊為前提，不提供連線服務的取得指引。
入門指南說明首次匯入、選擇 Global Routing（全域路由）與建立連線的操作流程；本頁則說明各設定區段如何影響結果，適合首次連線完成後查閱。第一次使用時，請先完成教學，再回到相關章節調整設定。
設定檔結構與啟用關係
先區分伺服器資訊、訂閱與 Config
伺服器資訊說明如何連線至指定伺服器端，包含協定、位址、連接埠與驗證參數。Subscribe（訂閱）用於匯入及更新使用者已有的伺服器項目。Config 則負責一般選項、網域解析、請求比對與策略分配。三者用途不同，成功匯入訂閱不代表已套用某份規則，也不能據此判斷所有請求都會經過目前選取的伺服器。
檢查設定時，先在 Home（首頁）確認目前可用的伺服器，再查看 Global Routing 的模式，最後到 Config 確認實際啟用的檔案。只在編輯器中開啟檔案，不代表它已生效；儲存副本也不一定會改變目前的選取項目。排查問題時應一併記錄這三項狀態，否則同一條規則可能因測試入口不同而呈現不同結果。
方括號區段名稱與逐行語法
Shadowrocket 的常見設定會以方括號標示區段。General 儲存一般鍵值，Rule 儲存依序檢查的規則，Host 儲存指定主機對應，URL Rewrite 儲存網址改寫運算式。區段名稱是語法的一部分，不應翻成中文。空行主要用於分組閱讀；欄位之間使用半形標點，中文逗號、全形等號或智慧引號都可能使解析結果不如預期。
# 設定結構示意；不含伺服器連線參數
[General]
dns-server = system
ipv6 = false
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT
[Host]
intranet.example.com = 192.0.2.10
[URL Rewrite]
^http://legacy\.example\.com/(.*) https://www.example.com/$1 302這段內容只示範各區段的排列方式，不能取代使用者已有的完整連線設定。範例中的網域與位址僅供文件說明；尤其 Host 對應不會憑空建立內部伺服器。實際合併時，應將對應行加入既有的同名區段，而不是在檔案末尾重複新增區段標頭，更不要把規則行放進 General 的鍵值清單。
| 設定區段 | 主要用途 | 檢查重點 |
|---|---|---|
[General] | 一般行為與解析選項 | 鍵名、值類型與網路條件 |
[Rule] | 請求比對與策略 | 規則順序與兜底策略 |
[Host] | 指定主機位址對應 | 主機名稱與位址是否相符 |
[URL Rewrite] | 請求網址改寫或重新導向 | 正規表示式範圍與目標網址 |
本機修改與遠端更新的界線
若設定來自遠端位址，應先了解更新操作會替換哪些內容。重新取得遠端檔案後，本機編輯內容可能遭到覆蓋；伺服器訂閱更新與設定更新也未必是同一項操作。需要長期保留的規則，應記錄在可自行管理的設定副本中，並註明來源。不要依賴記憶重新拼湊，否則更新幾次後就難以確認哪些規則來自原始檔案、哪些是後續新增的。
建議依用途命名副本，例如「日常設定」和「規則測試」，不要只用含糊的數字區分。建立副本後，先不修改內容並啟用一次，確認基本連線與原始檔案一致，再開始編輯。如此可分別驗證複製、切換與規則修改；若第一步就出現差異，應檢查檔案內容與選取狀態，而不是繼續疊加新設定。
設定中可能包含使用者自己的伺服器資訊、私人位址或驗證資料。分享問題時只保留相關區段，並替換敏感值，同時保留逗號位置、鍵名與欄位順序。只截取最後的錯誤提示通常不足以診斷；直接公開完整設定又會洩露不必要資訊。最有效的資料是已去識別的最小片段、預期結果與實際命中紀錄。
閱讀其他設定範例時，也要區分「區段語法正確」與「適合目前環境」。同一條規則在不同 DNS、不同出口與不同 Global Routing 模式下，可能產生不同結果。移植前請逐行確認用途；無法說明用途的行先不要加入。設定越複雜，越需要明確指出每個選項要解決哪個可觀察到的問題。
General 一般欄位與 DNS 解析
鍵值選項不等於分流規則
General 使用「鍵名等於值」的形式描述一般行為，與 Rule 的逗號分隔結構不同。修改這個區段往往會影響多個網域，不宜將它當成修復單一網站的首選。遇到存取異常時，先確認問題是解析失敗、位址無法連線，還是規則套用錯誤，再決定是否需要修改一般欄位，避免一次調整連原本正常的請求也改變行為。
dns-server = system 表示使用系統提供的解析設定。這適合作為理解流程的起點，但不保證在任何網路環境下都會得到相同結果。網路切換、系統設定及網域本身的解析策略，都可能改變回傳位址。若使用者已有明確的解析伺服器需求，應依照其技術說明填寫；不要只因某個位址出現在範例中，就認定它適用於目前網路。
[General]
dns-server = system
ipv6 = false
skip-proxy = 127.0.0.1, localhostipv6 = false 是布林值寫法範例，不代表所有使用者都應關閉 IPv6。是否啟用應一併考量目前網路、伺服器能力與目標位址。關閉後若能連線，只能說明存取路徑有所改變，不能直接證明故障原因。應保留啟用前後的解析紀錄，區分原本回傳了無法連線的 IPv6 位址，還是其他設定隨著重新連線一併變動。
了解網域與位址資訊的出現時機
App 發出請求時，客戶端不一定同時掌握完整網址、網域與目標位址。有些請求以網域建立連線，有些直接使用位址，既有連線也可能繼續使用快取結果。網域規則與位址規則仰賴的資訊不同，因此排查時應先查看請求紀錄實際提供哪些資訊，再判斷某種比對方式是否具備執行條件。
位址規則有時需要等網域解析後才能判斷。規則後附加 no-resolve 的作用，是避免只為檢查該條位址規則而主動解析網域；這並非關閉整個客戶端的 DNS。若請求本身已使用位址，仍可能以現有位址進行比對。了解這項差異有助於減少不必要的解析，也能說明為何同一條位址規則在不同請求上的表現不一。
[Rule]
DOMAIN,portal.example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY上述範例先處理明確網域，再檢查現有位址是否落在文件專用網段，最後交由兜底策略處理。若請求只有網域且不符合第一條規則，帶有 no-resolve 的位址規則不會為了自身額外發出查詢；此時不能因網域最後解析到該網段，就斷定這條規則一定會先命中。應以實際請求資訊與比對紀錄為準。
skip-proxy 與請求路徑
skip-proxy 用於列出系統代理層級的例外目標，不應視為 Rule 中 DIRECT 的同義寫法。不同流量進入客戶端的方式可能不同，系統代理例外也不能取代完整的規則設計。對需要核對分流結果的業務，優先在 Rule 中明確寫出條件，並確認該流量確實經過客戶端可處理的路徑。
對於內部網域，應先確認系統網路是否具備相應的解析條件。即使規則選擇 DIRECT，系統仍需知道該主機的正確位址；即使 Host 已指定位址，裝置仍需有可連線至該位址的路徑。解析、策略與連線能力是連續但彼此獨立的環節，單獨修改其中一項無法取代另外兩項。
DNS 結果也可能由 App、系統或客戶端快取。修改解析設定後，應關閉目前的測試頁面並重新建立請求，必要時使用 App 內對應的清除工具。不要同時清除快取、更換伺服器又調整規則，否則即使恢復存取，也無法確認是哪個步驟生效。重新測試的紀錄至少應包含網路類型、目標主機、解析位址與實際策略四項。
若只有部分網域無法連線，先將它們與正常網域分組比較，不要立刻替換所有一般選項。檢查失敗網域是否有回傳位址、回傳位址是否變動，以及相同策略下的其他目標是否可連線。DNS 問題常在切換網路後出現，保存前後狀態有助於判斷是網路條件改變，還是目前設定遭另一個檔案取代。
DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD
完整網域與後綴範圍
DOMAIN 用於精確比對完整主機名稱。條件寫成 api.example.com 時，規則只針對這台主機，不會自動涵蓋 www.example.com 或更深層的子網域。條件中不要加入協定、連接埠、斜線或網址路徑。若要區分同一主機上的不同頁面，一般網域規則無法做到，因為這些頁面在網域層級並無差異。
DOMAIN-SUFFIX 用於比對指定網域及其子網域。條件為 example.com 時，可涵蓋該網域本身及 api.example.com 等子網域；它不是任意字串結尾比對，不應解讀為也涵蓋 notexample.com。填寫時不需在前面加星號，也不要直接貼上瀏覽器常見的完整網址作為條件。
[Rule]
DOMAIN,accounts.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT在這組規則中，帳戶主機先命中精確例外，其餘屬於 example.com 的主機再由後綴規則處理。如果將後綴規則放在第一行，帳戶主機也會先符合它，後面的精確例外便沒有機會執行。精確比對的條件範圍較窄，但不會脫離檔案順序自動取得優先權，必須主動排在範圍較廣的規則之前。
關鍵字比對的誤判範圍
DOMAIN-KEYWORD 會檢查網域中是否包含指定關鍵字，適合確實需要以同一字串涵蓋多個網域的情況。它不會辨識所屬組織，也不會判斷字詞邊界。關鍵字太短時，許多不相關的主機也可能被選中。若只有一個或幾個已知網域，應優先使用 DOMAIN 或 DOMAIN-SUFFIX，讓設定範圍一目了然。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT此處先保留 example.com 的例外，再將其他包含 example 字串的網域交由 PROXY 處理。這個順序僅用來說明語意，並非通用建議規則。使用關鍵字前，應從實際請求中列出希望涵蓋與不希望涵蓋的主機，逐一確認是否符合預期；不能只測試一個成功頁面就結束驗證。
| 類型 | 條件範例 | 範圍界線 |
|---|---|---|
DOMAIN | api.example.com | 只比對該完整主機名稱 |
DOMAIN-SUFFIX | example.com | 主網域及其子網域 |
DOMAIN-KEYWORD | example | 網域中包含該字串 |
頁面由多個主機共同組成
瀏覽器網址列顯示的主機，不一定涵蓋頁面載入的所有目標。圖片、字型、登入驗證、API 與影片片段可能來自不同網域。主頁正常但部分內容載入失敗時，應查看缺少的資源所對應的主機，再決定是否補上規則。將整個頂級網域範圍交給同一策略雖然簡單，卻會擴大影響範圍，也可能掩蓋真正需要處理的條件。
同一服務也可能使用外部儲存空間或內容傳遞主機，這些主機未必屬於主站的網域後綴。應根據使用者實際存取紀錄與服務文件確認關聯，不要只憑相似拼字推測。若公共資源網域由多人共用，修改其策略可能影響其他 App；必要時保留更精確的例外，並說明為何不能只使用主站後綴。
有些請求直接連線至位址，沒有可用的主機名稱；有些網域經過別名解析，但規則紀錄仍會顯示原始請求網域。不能只根據某次 DNS 查詢看到的別名，就斷定網域規則一定會比對該別名。排查時應以客戶端紀錄中的目標欄位為準；若紀錄中只有位址，請接著檢查位址規則與網域資訊是否可見。
測試網域規則時，可先放一條暫時性的精確規則，將測試範圍縮小至單一主機。確認命中後，再擴大為後綴規則，並測試一個子網域與一個不相關網域。這個流程可以驗證規則語法、排序與範圍三項問題。測試完成後請刪除暫時規則，避免日後忘記用途，讓不易察覺的例外排在廣泛規則之前。
維護網域清單時，應記錄每條規則對應的實際需求，而不是不斷堆疊無法說明的後綴。重複規則不會提高可靠性；條件相同、策略不同的重複行尤其容易造成誤解。整理時保留有效的第一條，確認後續重複項目是否只是失效的舊內容，並在修改後重新測試登入、靜態資源與 API 等不同請求。
IP-CIDR、GEOIP 與 USER-AGENT
位址範圍與前綴長度
IP-CIDR 以網路位址與前綴長度表示一段 IPv4 位址。前綴長度越大，涵蓋範圍通常越小；單一位址可使用三十二位元前綴。填寫前應先確認目標是單一主機還是整個網段，不能只因兩個位址開頭幾段相似，就擴大涵蓋範圍。涉及區域網路時，也要核對目前網路實際分配的位址範圍，避免將不相關的遠端位址一併設為 DIRECT。
[Rule]
IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR,198.51.100.0/24,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY以上位址皆為文件用途，不能作為實際服務位址。第一條只選取一個 IPv4 位址，第二條涵蓋一個 IPv4 網段，第三條示範 IPv6 前綴寫法。IP-CIDR6 對應 IPv6 位址範圍，不應將含冒號的位址填入 IP-CIDR。前綴代表位址集合，不是連接埠範圍，也無法區分同一伺服器上的不同網站。
若多個網域共用同一個位址，位址規則可能同時影響這些網域。因此，已知目標主機時通常應先考慮網域規則；只有確實以位址管理的業務才使用網段規則。反過來說，若目標是固定的內部裝置，且請求直接使用位址，網域規則也無法取代位址規則。選擇依據應是業務識別方式，而不是哪種寫法看起來更簡短。
GEOIP 是位址分類，不是網站身分
GEOIP 依位址資料庫中的地區分類進行判斷，例如 GEOIP,CN,DIRECT。這類規則描述的是目標位址的分類，而非網域註冊地或服務提供者所在地。網站採用內容傳遞服務後，在不同網路下可能解析至不同位址；資料庫也可能與目前實際使用情況不符，因此地區規則適合作為較廣泛的補充條件。
[Rule]
DOMAIN,api.example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY此例先固定特定 API 的策略，再以地區條件處理其他請求。若將 GEOIP 移到前面，當 API 解析出的位址符合該地區分類時，精確網域例外便可能無法執行。規則仍依順序評估，不會因後面有更精確的網域條件就自動重新比對。發生分流錯誤時，先查看命中位置，再確認是否需要核對位址資料庫。
GEOIP 判斷可能涉及解析目標網域。是否附加 no-resolve，應依是否願意為這項條件觸發解析來決定。加上後，只有網域而沒有可用位址的請求可能會直接繼續檢查後續規則；不加則可能產生額外的解析等待。這是行為上的取捨，並沒有適用所有網路的固定寫法，必須依實際紀錄驗證。
USER-AGENT 的可見性限制
USER-AGENT 依據可見請求中的 User-Agent 資訊比對，不能等同於依 App 身分分流。多個 App 可能傳送相同識別資訊，同一個 App 也可能依請求類型改變識別資訊。一般加密連線不會自然公開所有 HTTP 請求標頭，因此不能期待它識別所有 App 流量，更不能將它當作系統層級的程序選擇器。
[Rule]
USER-AGENT,ExampleClient*,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTExampleClient* 是示範模式，實際條件應取自使用者能確認的請求識別資訊。只憑 App 名稱猜測 User-Agent 容易失敗，因為品牌名稱與請求標頭不一定相同。若請求紀錄沒有相應資訊，應改用可觀察到的網域或位址條件，不要不斷放寬萬用字元來彌補資訊不足。
存取控制需求也不應只依賴 USER-AGENT。這個欄位是請求中繼資料，不是強式驗證憑證；同一個目標在不同請求中可能帶有不同值。若目標是封鎖明確的主機，直接設定網域條件較容易複核。若要區分同一主機上的不同業務，應先確認客戶端可見資訊能否表達差異，再決定是否適合在規則層處理。
測試位址與中繼資料規則時，應分別涵蓋既有連線與新建連線、以網域存取與以位址存取。某次命中只能表示該請求符合條件，不能推論所有相似流量都相同。若紀錄缺少關鍵欄位，應註明「目前證據不足」，保留更容易觀察的規則，而不是把偶然結果固定為大範圍預設策略。
PROXY、DIRECT、REJECT 與規則優先順序
先確認 Global Routing 模式
Global Routing 中的 Config、Proxy、Direct 分別代表設定、代理與直連模式。檢視 Rule 中逐條分流時，應使用 Config，並確認實際啟用的設定檔。Proxy 和 Direct 用於依相應全域模式處理連線，不應拿它們的測試結果證明一般分流規則是否正確。介面上的 Proxy 與規則關鍵字 PROXY 大小寫不同，閱讀時應區分層級。
| 層級 | 名稱 | 意義與檢查點 |
|---|---|---|
| Global Routing | Config | 依目前設定檢查規則命中 |
| Global Routing | Proxy / Direct | 全域模式，不等同於規則行 |
| Rule 策略 | PROXY | 交由目前的代理選擇處理 |
| Rule 策略 | DIRECT | 透過本機網路直接連線 |
| Rule 策略 | REJECT | 拒絕符合條件的請求 |
PROXY 不會在規則中定義伺服器端，而是引用目前可用的代理選擇。若伺服器參數錯誤、驗證失敗或伺服器無法連線，即使規則完全正確地命中，請求仍會失敗。DIRECT 不表示繞過裝置的所有系統網路條件，仍會受到目前網路、DNS 與目標服務狀態影響。REJECT 是明確拒絕，不應作為診斷未知故障的預設測試方式。
首條命中與明確例外
Rule 常見的處理方式是由上而下檢查，由第一條符合條件的規則決定該請求的策略。規則不會依網域長度、類型名稱或撰寫時間重新排序。建立設定時，可依「精確例外、業務網域、位址補充、最終兜底」的順序組織；這只是方便推理的結構，不是必須照抄的固定清單，每條規則仍應說明為何放在該位置。
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,blocked.example.net,REJECT
GEOIP,CN,DIRECT
FINAL,PROXY登入主機命中第一條後，就不再由 example.com 的後綴規則決定策略。另一個 example.com 子網域會繼續檢查第二條。明確列出的拒絕目標由第三條處理，其餘請求才進入地區判斷。閱讀設定時，可以拿一個具體主機從第一行開始逐條推演，不要只盯著看似相關的單一行。
若將第三條的拒絕目標也包含在更前面的廣泛直連規則中，拒絕條件就可能無法執行。這種衝突無法靠重複寫同一條 REJECT 修復，應調整規則位置或縮小前面條件的範圍。刪除失效規則前，也應確認它是否是刻意保留的文件說明；若確實無效，加入註解說明會比留下互相矛盾的啟用項目更清楚。
FINAL 是兜底，不是自動修復
FINAL 不需要填寫網域條件，基本形式為 FINAL,PROXY 或 FINAL,DIRECT。它會接手前面都未命中的請求，應放在規則末尾。若將 FINAL 放在中間，後續一般規則就失去預期的執行機會。檢查設定時，先搜尋 FINAL 出現次數；通常保留一條明確的最終策略即可，不要用多條兜底規則表達不同用途。
選擇哪種兜底策略，應考量實際使用需求與既有連線條件。FINAL 設為 PROXY，代表尚未分類的請求交由代理選擇處理；設為 DIRECT，則代表未分類請求直接透過目前網路連線。兩者都不保證目標一定可連線。遇到單一業務異常時，應先新增有依據的精確例外，不要來回切換整體兜底策略碰運氣。
# 精確例外必須放在涵蓋它的廣泛規則之前
[Rule]
DOMAIN,health.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT測試上述範例時，至少檢查健康檢查主機、另一個 example.com 子網域，以及一個完全不相關的網域。這三類請求分別驗證例外、後綴與兜底策略。若只測第一類，可能發現不了 FINAL 被誤改；若只測主站，也可能發現不了精確例外遭到涵蓋。驗證規則時應涵蓋邊界，而不只是確認一條成功路徑。
On Demand（隨選連線）決定在相應網路條件下是否建立連線，無法取代 Rule 對請求策略的判斷。連線自動建立後，仍須核對目前的 Global Routing 與 Config。若切換網路後結果改變，應分別檢查連線是否重新建立、設定是否相同、DNS 是否變動；不能因為 On Demand 已開啟，就斷定所有請求都使用預期的出口。
策略命中與業務成功應分開驗收。命中紀錄證明分類邏輯，目標回應則證明目前路徑可用，兩者缺一不可。遇到失敗時，先判斷是「策略選錯」還是「策略正確但連線失敗」，再進行下一步。首次連線的相關問題可參閱常見問答，避免將授權或伺服器驗證故障誤判為規則優先順序問題。
Host 對應與 URL Rewrite 的適用範圍
Host 變更位址對應，不會改變網站身分
Host 可為指定主機設定靜態位址對應，常用於使用者明確知道目標位址的受控環境。它無法自動找出內部裝置，也不保證該位址可連線。設定前應取得正確位址，並確認該主機確實在目標位址提供服務。填入隨機可連線的位址，只會讓請求送往錯誤目標，不能用來修復解析問題。
[Host]
portal.example.com = 192.0.2.20
files.example.com = 192.0.2.21
[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN,files.example.com,DIRECT
FINAL,PROXY此處的 Host 用於指定位址，Rule 用於指定策略，兩個區段描述的是不同環節。範例使用文件專用範圍，實際使用時必須替換成使用者環境中的有效值。若目標位址只在特定網路中可連線，裝置離開該網路後，即使靜態對應仍存在也可能連線失敗；這時應檢查連線路徑，而不是繼續新增同名對應。
使用 HTTPS 時，原始網域仍會參與網站身分驗證。Host 將網域指向另一個位址，不會讓憑證自動變正確，也不會把請求中的主機身分改成該位址。若出現憑證名稱不符，應核對對應目標與服務設定，不要把關閉驗證當成正常修復方式。目標服務遷移後，尤其應重新檢查靜態對應。
Host 與快取也可能共同影響觀察結果。修改後若仍連線至舊位址，應先結束既有連線，並檢查 App 端是否有快取。確認新請求已使用新對應後，才能評估是否有效。若要還原原有解析，刪除測試對應並重新發出請求，比在同一主機下不斷新增互相衝突的值更容易追蹤。
URL Rewrite 比對網址運算式
URL Rewrite 使用正規表示式識別請求網址，並依設定執行改寫或重新導向。它與網域分流並非同一種機制：網域規則決定策略，改寫規則則變更目標運算式。若只希望某個主機使用 DIRECT，無須使用網址改寫；只有確實需要受控的網址遷移、路徑調整等情況，才應加入這個區段。
[URL Rewrite]
^http://legacy\.example\.com/(.*) https://www.example.com/$1 302範例會將舊主機上的 HTTP 網址重新導向至新主機，並保留捕獲到的後續內容。開頭的插入符號限制比對起點，反斜線讓網域中的句點按字面比對，括號建立捕獲群組，目標中的美元符號加數字則引用該群組。最後的 302 表示暫時重新導向。此寫法僅示範語法，目標網域不是可用的業務服務。
省略起點限制或未跳脫句點，都會擴大正規表示式的比對範圍。正規表示式中的句點通常代表任意字元，不是一般的網域分隔點。編輯前應用幾個相似網址測試：預期的舊主機應符合，其他主機不應符合，已是新主機的網址也不應再次符合。範圍越小，越容易確認改寫只影響預期請求。
重新導向、加密與循環檢查
客戶端能處理哪些網址資訊，取決於實際請求路徑與加密可見性。不能假設加入 URL Rewrite 後就能讀取任意 HTTPS 路徑；若通道中只有主機資訊，依完整路徑比對的運算式可能不具備執行條件。請先用資訊可見、範圍受控的請求驗證，不要為了單一路徑問題任意擴大憑證信任或檢查範圍。
重新導向後，App 需要向新目標發出後續請求，新目標也必須符合目前的分流設定並可連線。舊目標規則正確，不代表新目標的策略也相同。若新主機又將請求送回舊主機，就會形成循環；瀏覽器可能只顯示重新導向次數過多。此時應分別查看每次跳轉的來源與目標，檢查伺服器行為是否與本機規則相互疊加。
永久重新導向可能會被客戶端快取，因此驗證階段通常適合先使用可控的暫時重新導向，確認後再依業務需求決定最終方式。即使刪除本機規則，App 快取也可能使測試結果暫時不變。排查時應使用新的請求入口並記錄實際跳轉鏈，不要只憑網址列最後顯示的位址判斷規則是否仍在執行。
查詢參數可能包含驗證或業務狀態，不了解其結構時，不要任意丟棄或拼接。捕獲運算式是否保留查詢部分，應以具體範例檢查；路徑中的特殊字元也可能涉及跳脫差異。對登入、付款或提交表單等敏感流程，應優先遵循服務本身的跳轉設計，不要把簡單 GET 請求的測試結果套用到所有請求方法。
常見規則組合、合併與設定維護
從能夠說明的最小規則開始
建立規則集前，先用自然語言寫清楚需求，例如「帳戶主機直接連線，其他業務子網域使用目前的代理，其餘請求維持直連」。再將每個需求轉換成相應條件。如此才能判斷新增規則是否真的必要，測試失敗時也能回到原始需求，而不是靠增加更多廣泛比對條件掩蓋既有衝突。
[Rule]
# 帳戶主機例外
DOMAIN,accounts.example.com,DIRECT
# 業務網域
DOMAIN-SUFFIX,example.com,PROXY
# 使用者確認的拒絕目標
DOMAIN,blocked.example.net,REJECT
# 其他請求
FINAL,DIRECT這組規則刻意保持簡短，方便逐條核對。它不包含伺服器位址，也不包含訂閱內容，必須以使用者已有可用連線資訊為前提。新增業務時先確認目標主機，再決定使用精確條件或後綴條件；不要因一個頁面載入失敗，就加入一長串未經核對的網域，否則之後將無法判斷哪些行真正參與處理。
合併規則時處理語意衝突
合併兩份設定不能只把文字前後串接。先辨識兩份檔案各自的區段，再將同類內容放進相應區段，最後統一檢查規則順序與 FINAL。General 中相同鍵名但值不同、Host 中同名主機但位址不同，以及 Rule 中條件相同但策略不同的項目，都應由人工決定保留哪一項，而不是依賴不明確的重複覆寫行為。
網域後綴與精確網域也可能有隱含衝突。某份規則將 example.com 全部交給 PROXY，另一份則指定其中一個 API 使用 DIRECT；這不是簡單的重複行，必須將精確例外放在廣泛規則之前。合併時應搜尋同一主網域附近的所有項目，檢查是否有更廣泛的後綴或關鍵字已提前涵蓋它。
# 合併後的順序：例外在前，廣泛條件在後
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY若原始檔案包含自訂策略名稱，移轉時還要確認目標設定中存在同名定義，且名稱與大小寫完全一致。本頁使用 PROXY、DIRECT、REJECT 說明基本語意，不能據此推論任何陌生策略名稱都能直接使用。遇到未知引用時，先查明它連結到哪個伺服器選擇或策略群組，確認後再決定是否保留。
保留修改紀錄並掌握更新界線
每次變更都應記錄目標、修改行與驗證結果。註解可另起一行，寫明業務用途與例外原因，不必長篇敘述。暫時性的診斷規則尤其應標示移除條件，否則幾次測試後容易忘記，形成不易察覺的優先順序。整理規則時也應檢查註解是否仍符合實際策略；過時註解會讓設定比沒有說明更難維護。
更新遠端設定前，先備份本機副本，再比較重要區段，不要只確認檔案是否成功取得。上游可能變更兜底策略、新增廣泛規則或調整解析選項，這些變動都會影響本機例外。若需要重新合併本機內容，應依規則語意檢查位置；將舊例外原封不動貼到檔案末尾，可能剛好落在 FINAL 之後而失效。
訂閱更新主要涉及既有伺服器項目，不應視為同步規則的通用替代操作。更新後若代理路徑異常，請檢查目前選取的伺服器是否仍有效、驗證參數是否變更，以及舊項目是否遭到替換。即使規則仍命中 PROXY，若指向不同的連線選擇，業務結果也會改變；這類問題無法靠調整網域順序解決。
設定備份與伺服器憑證應分開管理。匯出的檔案可能包含連線參數，也可能需要另外保存伺服器清單；換機後不能只因檔名相同就認定內容完整。具體準備與還原步驟請參閱設定備份與換機還原說明，並在舊裝置仍可使用時完成一次還原確認。
規則集逐漸增加後，應定期精簡。對於從未命中、用途不明或已被更廣泛條件涵蓋的項目，先在測試副本中停用並觀察，再決定是否刪除。整理的目標不是讓行數最少，而是讓每條啟用中的規則都有明確理由。維持正常業務穩定，比把所有可能類型都加入設定更容易管理。
協定連線參數與規則策略也應分開管理。例如 WireGuard 的金鑰與位址會影響連線建立，DOMAIN-SUFFIX 則決定哪些目標交由該代理選擇處理；兩者屬於不同層級的問題。欄位說明可另參閱WireGuard 設定欄位填寫說明，不要為了修復驗證錯誤而不斷擴大業務網域的比對範圍。
規則驗證、故障分流與還原檢查
建立可重複的測試條件
有效的測試應具備明確的目標主機、預期策略、固定網路與清楚的設定狀態。先確認使用 Config 模式，記錄啟用檔案與目前伺服器，再發出新請求。測試期間不要同時更新訂閱或切換網路。若條件不斷變動，即使結果偶爾成功，也難以證明是規則修正造成的變化，更無法將結論用於後續維護。
建議每次修改都選擇三類測試對象：應該命中的目標、應該套用例外的目標，以及不應受影響的目標。分別記錄規則、策略與業務結果。新增後綴規則時，至少涵蓋主網域、子網域與相似但不屬於該後綴的網域；新增位址規則時，則驗證範圍內外的兩個位址，避免只測成功的範例。
| 觀察到的現象 | 優先檢查 | 下一步 |
|---|---|---|
| 未如預期命中 | 檔案、模式、請求欄位 | 檢查前置的廣泛規則與新請求 |
| 命中 PROXY 但連線失敗 | 伺服器連線與驗證 | 區分出口與目標服務問題 |
| 命中 DIRECT 但連線失敗 | 本機解析與網路路徑 | 檢查回傳位址與可連線範圍 |
| 主頁正常，資源載入失敗 | 資源實際使用的主機 | 逐項核對相依請求 |
| 修改後結果沒有變化 | 快取與既有長連線 | 建立新請求並確認檔案 |
先區分未命中與命中後失敗
未命中時，首先檢查目標是否真的具備規則所需資訊。網域條件無法比對只有位址的請求，USER-AGENT 條件無法比對不可見的請求標頭。接著從 Rule 頂端往下檢查，找出更早的後綴、關鍵字、地區條件或 FINAL。最後確認半形標點、策略拼寫，以及該行是否位於正確區段。
已命中但存取失敗時，應停止毫無根據地移動規則。PROXY 分支應檢查目前伺服器能否建立連線、驗證資訊是否仍有效，以及目標服務是否可連線；DIRECT 分支則檢查本機網路是否能存取解析位址。若只有單一目標失敗，優先比較目標差異；若所有採用相同策略的請求都失敗，再檢查該策略共用的連線條件。
Connectivity Test（連線測試）可提供特定測試條件下的結果，但不能取代每個業務請求的驗證。某個測試目標有回應，不代表登入介面、影片資源或其他協定請求都能成功。應將測試結果視為縮小問題範圍的線索，並搭配實際失敗請求判斷；不能只憑單一數值就替整份設定下結論。
處理快取、長連線與網路切換
設定變更不一定會讓所有已建立的連線立即依新策略重新建立。瀏覽器重複使用連線、App 背景傳輸與媒體持續播放，都可能保留舊狀態。驗證時應主動結束相關工作階段並重新請求，必要時重新建立客戶端連線。既有頁面持續播放只能表示舊連線仍可運作，不能證明新規則已套用至後續連線。
從無線區域網路切換至行動網路後，解析伺服器、可連線位址與連線狀態可能一併改變。內部主機原本在某個網路中可連線，切換後卻失敗，不一定是規則錯誤。請重新確認 On Demand 是否建立連線、Global Routing 是否維持原模式，以及目標是否依賴原網路路徑，再決定是否需要為不同網路安排獨立設定。
Data（流量統計）反映統計範圍內的傳輸量，並非規則命中的直接證明。看到某個伺服器有流量，只能表示它曾參與傳輸，不能證明目前的測試目標一定經過它；命中快取也可能沒有明顯新增流量。統計範圍與讀數解讀請參閱流量統計說明；驗收分流仍應以個別請求為單位。
最小化重現與安全還原
複雜問題可在測試副本中逐步縮小範圍：保留必要的 General、單一目標規則與一條 FINAL，暫時移除不相關的 Host 與 URL Rewrite。每移除一組內容，就以相同方式重複測試並觀察差異。不要直接清空日常設定中的所有區段；一旦失去基準，原本正常的行為也會難以還原。
# 用於隔離單一目標的規則區段；不是完整連線設定
[Rule]
DOMAIN,api.example.com,PROXY
FINAL,DIRECT若最小規則能如預期命中，再逐組還原原有內容，找出首次出現差異的位置。若最小規則仍未命中，應回頭檢查啟用關係與請求欄位，而不是繼續合併更多規則。每一步只改變一個變數，才能區分「檔案未啟用」、「前置條件涵蓋」與「策略路徑故障」，減少重複嘗試。
若需進一步諮詢，請提供已去識別的相關區段、實際主機、命中策略、網路條件與重現步驟。不要公開完整訂閱網址、金鑰或驗證欄位。若無法繼續排查，請還原已驗證的備份，確認原有業務恢復後，再安排下一次測試。匯入與首次授權操作請返回入門指南；購買確認與還原取得方式請參閱已購項目還原說明。