Shadowrocket
規則與設定完整指南

設定檔描述的是連線處理方式，不是伺服器帳戶本身。了解這一點，便不會將「匯入後出現伺服器」和「已選取分流設定」混為一談。伺服器資訊說明要連到哪裡、使用哪種協定及如何驗證；設定檔則決定哪些請求直接連線、哪些使用代理，以及哪些應予以拒絕。兩者需要搭配使用，但匯入其中一項，不代表另一項也已就緒。使用現有訂閱時，請先確認 Home 中的伺服器資訊，再檢查 Config 中實際啟用的設定。

段落名稱、欄位與規則列

Shadowrocket 設定文字以方括號括住的段落名稱區分用途。[General] 用來設定一般參數，常見格式為欄位名稱、等號與欄位值；[Rule] 用來放置有順序的分流規則；[Host] 用來指定主機名稱與位址的對應；[URL Rewrite] 則處理符合條件的 URL。段落名稱不是裝飾標題，放錯位置會改變解析方式。不要把 General 的等號格式套用到 Rule，也不要把中文說明直接接在規則參數後面。

[General]
bypass-system = true

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

[Host]
router.example.com = 192.168.1.1

這段範例呈現各段落之間的關係，並非適用於所有網路的完整設定。第一條規則讓指定主機直接連線，第二條涵蓋示例網域及其子網域，第三條指定一段私有位址範圍，最後一條則作為預設處理。Host 對應僅將示例主機名稱指向某個位址，不代表該位址上有服務。實際儲存時，請保留原設定中必要且已了解用途的欄位；若設定由遠端來源維護，也要留意下次更新是否會覆寫本機修改。

儲存副本並確認目前使用的設定

修改前，先在 Config 中確認目前選取的設定，記下名稱與可還原的位置，再另存一份副本。開啟某個檔案進行編輯，不代表該檔案目前已用於處理連線。儲存後，請返回設定列表確認選取狀態，並以新連線驗證。若編輯畫面提示語法錯誤，請先修正再啟用；不要在解析錯誤的情況下繼續新增內容，以免後續難以判斷問題源自哪項修改。

設定檔副本與伺服器備份也要分開看待。還原規則設定，不一定能還原伺服器的驗證欄位；重新匯入訂閱，也不一定會還原手動新增的規則。移轉前請分別檢查伺服器、設定檔與必要的設定項目。設定中可能包含私人網域、伺服器識別資訊或驗證資料；提供排錯資料給他人前，請先刪除這些內容，只保留能重現問題的最少規則與經過處理的連線記錄。

如何閱讀本頁的設定範例

範例中的 example.com 僅用來說明語法，不是可用的訂閱入口，也不表示該網域需要特定策略。請依實際環境替換示例位址與規則。程式碼區塊中的空行用於分組；完整段落可以整段參考，零散片段則應放回對應的設定段落。對不熟悉的選項，先確認 App 內是否能辨識，再查明其作用範圍。欄位名稱相似，不代表行為相同，不能只憑字面意思猜測後大量新增。

遠端規則檔與本機設定也各自涉及維護責任。自行新增例外時，建議記下修改原因、驗證目標與預期策略，並在每次更新後確認例外是否仍然存在。少量且容易說明的規則，通常比堆疊來源不明的長清單更容易維護。本手冊後續章節依序說明「設定執行條件、建立比對範圍、選擇策略、觀察結果」；排錯時也應依照相同順序檢查。

先確認 Global Routing，再檢查 Rule 中的規則是否正確。設定檔已儲存，但目前執行模式不是 Config，是判斷「規則沒有生效」時最常見的前提之一。介面中的 Config、Proxy、Direct 分別代表設定、代理與直連模式；它們決定整體連線處理方向，不是用來調整個別規則的優先順序。測試分流時，請明確選擇 Config，並在每輪驗證前確認目前模式沒有改變。

General 不是另一份規則清單

[General] 中的欄位控制一般行為，不能用來取代逐網域設定的 Rule。例如 bypass-system 與 skip-proxy 涉及系統及特定目標的略過處理，作用層級與一般 Rule 命中不同。若目標已在較早的略過路徑中處理，單純在 Rule 新增一行 PROXY，可能看不到預期結果。因此排錯時不只要檢查規則，也要確認一般設定是否讓連線未經預期路徑處理。

[General]
bypass-system = true
skip-proxy = 127.0.0.1, localhost, *.local
dns-server = system

此處保留系統略過行為，並列出本機與本地域名格式；DNS 則使用系統提供的解析設定。這段內容用於辨認欄位，不建議直接覆蓋原設定後使用。尤其是 skip-proxy，其清單屬於一般欄位的值，不能據此推論 Rule 也接受相同的萬用字元格式。閱讀現有檔案時，請先辨認該行所屬段落，再依欄位語意理解以逗號分隔的項目，避免混淆兩種語法。

連線開關、按需連線與規則各自負責不同層面

Home 中的連線開關用來啟動或停止連線處理；Global Routing 決定執行模式；目前使用的設定檔中的 Rule 則決定 Config 模式下的比對策略。這三項條件都必須分別確認。On Demand 負責在符合條件時是否按需建立連線，不會替每個網域選擇 PROXY 或 DIRECT。網路切換後若狀態有所變化，請先確認連線是否仍已建立，再檢查執行模式，最後才查看規則順序。

首次建立連線時，系統可能會要求允許新增 VPN 設定。這項授權表示 App 可以使用相應的系統網路功能，不代表現有伺服器一定連得上，也不能證明規則正確。若尚未完成首次連線流程，請返回快速上手教學依序操作。系統需求請以 App Store 頁面標示為準，不要根據他人的舊截圖推斷目前裝置是否相容。

切換模式進行有限的對照測試

針對同一個測試目標，可以短暫比較 Direct 與 Proxy 下新連線的結果，藉此區分直連路徑與代理路徑的問題；對照完成後，再切回 Config。測試期間應保持目標、網路與伺服器不變，才能減少變因。某個頁面在 Proxy 模式下能開啟、在 Config 模式下卻失敗，只能說明值得檢查分流路徑，不能直接判定所有 DIRECT 規則都有問題；頁面可能會連線至多個網域，應逐一檢查相關記錄。

同樣地，Direct 模式下能開啟頁面，也不代表該服務永遠都應直連。網路位置、解析結果與目標服務的存取條件都可能改變。合理的設定應反映明確需求，而不是把單次測試結果當成普遍原則。對 General 中不確定的設定，建議先還原已知可用的副本，再逐項核對；不要反覆切換多個開關碰運氣，以免掩蓋真正的處理界線。

網域規則主要用來決定「依據哪個主機名稱選擇策略」。常見類型包括 DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD，差異在比對範圍，而非規則名稱長短或所謂的權重。三者仍依 Rule 中的實際排列順序參與判斷。撰寫前先從 URL 中分離出目標主機名稱，不要將協定、連接埠、路徑或查詢參數一併填入網域參數。

DOMAIN：指定單一主機

DOMAIN,api.example.com,PROXY 用於指定主機名稱，適合只變更單一介面或新增小範圍例外。它不會自動涵蓋整個 example.com 網域，也不等於涵蓋所有子網域。單一 App 可能將登入、圖片與檔案下載分散在不同主機；只新增一條 DOMAIN 後，即使主頁能開啟，也不能證明所有相關連線都採用相同策略。請依實際記錄補上目標，不要只憑 App 名稱猜測網域。

DOMAIN-SUFFIX：涵蓋網域及其子網域

DOMAIN-SUFFIX,example.com,PROXY 用來比對該網域及其子網域，例如 www.example.com 與 api.example.com。此處的網域後綴有標籤邊界，不應理解成任意字串結尾。撰寫規則時直接填入 example.com 即可，不必為了涵蓋子網域而加上 https://、斜線或路徑。若要排除其中某個主機，請將它的精確規則放在這條廣泛規則之前。

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

此順序表示「狀態主機直接連線，其餘示例網域使用代理」。如果將前兩行對調，狀態主機就會先被後綴規則涵蓋，後面的精確例外便不會執行。精確規則能作為例外，是因為它排在前面，而不是因為 DOMAIN 天生優先於 DOMAIN-SUFFIX。維護檔案時，請將例外與所屬的廣泛規則相鄰放置，方便檢查兩者的關係。

DOMAIN-KEYWORD：範圍較廣，需謹慎驗證

DOMAIN-KEYWORD,example,PROXY 會依網域中的關鍵字比對，範圍可能涵蓋多個互不相關的網域。它不會依品牌、網站所屬單位或頁面內容判斷，也無法理解英文詞彙的業務含義。較短的關鍵字容易涵蓋額外目標，尤其是多個單字在主機名稱中連在一起時。除非確實需要關鍵字範圍，否則建議優先使用 DOMAIN 或 DOMAIN-SUFFIX，讓規則意圖能直接從網域確認。

為什麼依網頁網址撰寫規則仍可能漏掉比對

網址列只顯示入口網址，頁面資源可能來自其他主機。重新導向、登入驗證、媒體資源與介面請求都可能建立獨立連線。請在連線記錄中查看實際失敗的目標，分辨是入口請求失敗，還是後續資源請求失敗。不要因為頁面顯示某個路徑，就嘗試用 DOMAIN 比對路徑；網域規則只能指定主機層級的範圍，URL 路徑則屬於另一種處理條件。

此外，用戶端必須在相應連線中取得可用的網域資訊，網域規則才有比對依據。直接連線至 IP、App 自行處理解析，或沿用既有連線時，觀察結果可能與網址列所見不同。網域規則後仍須安排位址規則與 FINAL，涵蓋未符合網域條件的連線。排錯時請以記錄中顯示的目標資訊為準，不要直接將「沒有看到網域命中」解讀為規則解析失敗。

整理長規則清單時，可以先依需求設定範圍最小的精確例外，再設定網域涵蓋規則，最後才考慮確有依據的關鍵字規則。每增加一條範圍較廣的規則，都應測試一個預期會命中的目標，以及一個預期不會命中的目標。只驗證成功案例會漏看誤比對；正反兩面都驗證，能更早發現關鍵字過短、後綴寫錯或例外順序顛倒等問題。

位址規則依連線目標的 IP 判斷策略，與「某個網站屬於哪裡」不是同一概念。一個網域可能解析出多個位址，不同網路或不同時間也可能得到不同結果。服務也可能使用分散式基礎架構，因此 IP-CIDR 與 GEOIP 應視為位址層級的條件，而非固定的網站分類。遇到同一網域有時直連、有時使用代理，請先比較每次連線的目標位址，再判斷位址規則是否影響結果。

IP-CIDR：明確指定一段 IPv4 網段

IP-CIDR,192.168.0.0/16,DIRECT 表示一段位址範圍，斜線後的前綴長度決定範圍大小。前綴越長，範圍越小；若要比對單一 IPv4 位址，可使用 /32。網段位址應符合遮罩邊界，不要將一般網址、連接埠或任意起訖位址填入此參數。設定區域網路規則時，應依目前網路實際使用的位址範圍設定，不要誤以為某個私有網段是所有本機服務共用的位址。

[Rule]
IP-CIDR,192.168.1.10/32,DIRECT,no-resolve
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
FINAL,PROXY

第一條示範單一位址的寫法，第二條涵蓋較大的位址範圍，因此在此範例中，第一條不會改變最終策略，只是方便觀察範圍關係。若兩條規則的策略不同，順序便會直接影響結果。IPv6 位址應使用 IP-CIDR6，並採用 IPv6 前綴表示法；不能因為瀏覽器顯示網域，就認定連線只使用 IPv4。排錯記錄若出現 IPv6 目標，請檢查相應的 IPv6 規則與目前網路的實際連線能力。

no-resolve：控制為了比對而觸發的解析

位址規則末尾的 no-resolve 用於避免只為比對該規則而觸發網域解析。它不會讓整個 App 停止 DNS，也不會禁止所有解析請求。如果目標本來就是 IP，或連線處理時已取得可供判斷的位址，這個參數不代表位址規則永遠會被略過。若需要先依網域處理，再以位址規則補充已知位址，可搭配此參數減少不必要的解析；但仍應透過實際記錄確認效果。

GEOIP：依位址資料庫分類

GEOIP,CN,DIRECT 依目標位址在資料庫中的分類比對，不是依網域後綴、網頁語言或使用者所在地判斷。資料庫可能更新不及或存在歸屬差異，不能據此證明服務營運者或資料存放位置。若某個網域需要穩定採用指定策略，明確的網域規則通常比依賴位址分類更容易說明；GEOIP 較適合作為已了解其限制的補充條件。

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

此例先處理明確指定的網域，再依位址分類補充，最後交由 FINAL 處理。若網域規則已命中，就不會再比對 GEOIP 以重新選擇策略。反過來，若較廣泛的位址條件排在前面，後續網域規則的意圖可能無法實現。不同類型的規則不是互相投票的條件；它們共用同一套順序，先命中的條件決定本次判斷結果。

USER-AGENT：取決於能否取得請求資訊

USER-AGENT,Example*,DIRECT 示範依 User-Agent 模式比對的寫法。這不等於依 App 名稱分流，也不保證能識別裝置上的每個 App。只有請求包含可供判斷的相應資訊時，才可能符合規則。對於加密的 HTTPS 流量，不能假設只要啟用連線開關，就能讀取其中的 HTTP 請求標頭；若資訊不可見，應改用可確認的網域或位址條件，而不是不斷擴大比對模式。

診斷時建議先用一條明確的 DOMAIN 規則建立對照，再考慮 USER-AGENT 這類補充條件。不要為了測試一條規則，就擴大憑證信任範圍或修改大量請求處理設定。如果目標 App 會變更請求標頭、使用不同的網路程式庫或重複使用連線，模式比對結果也可能不同。規則是否可靠，取決於實際可取得的輸入條件，而不是名稱看起來是否更貼近 App 本身。

規則由比對條件與處理策略組成。比對條件回答「是否為這類連線」，策略則回答「命中後如何處理」。PROXY、DIRECT、REJECT 代表不同的處理結果，不是連線品質等級。將所有目標都改成相同策略，或許能暫時避開某個現象，卻會失去原設定的分流目的。請先釐清各類目標的需求，再選擇範圍最小的比對條件與相應策略。

由上而下比對，首條命中即停止

在 Rule 規則序列中，第一條出現且符合條件的規則會決定策略。不能假設較精確的 DOMAIN 一定會覆蓋較早出現的 DOMAIN-SUFFIX，也不能假設位址規則天生排在網域規則之後。所謂「例外優先」必須透過排列位置實現。閱讀複雜設定時，應從第一條相關規則開始往下檢查，不要只搜尋目標網域，就停在最符合直覺的那一行。

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

在此範例中，先個別處理兩個指定主機，再將其他示例網域交由 PROXY 處理；未符合網域條件的連線會繼續比對位址規則；前面都未命中時才會進入 FINAL。若將 FINAL 移到最前面，後續規則便無法正常參與比對。FINAL 不帶網域或位址參數，寫法為 FINAL,PROXY，不要誤寫成一般的三段式規則。

命中 PROXY 不代表一定連得上

規則比對成功，只能證明策略選擇符合條件。後續仍可能遇到伺服器無法連線、驗證失敗、目標拒絕或解析異常。PROXY 通常會交由目前選取的代理路徑處理；若現有設定使用命名策略或策略群組，也要確認對應名稱確實存在，且指向預期的選項。拼字錯誤、刪除被引用的群組，或群組內的選取項目改變，都可能讓人覺得「規則寫對了卻打不開」，但問題並不在比對條件本身。

DIRECT 也不保證能繞過目前的網路限制，而是讓連線直接前往目標。若本機網路無法存取該目標，DIRECT 連線失敗屬於路徑問題。REJECT 則會明確拒絕連線，不負責修復頁面版面、刪除已快取的內容，或區分同一主機上的不同用途。若登入與其他資源共用同一主機，拒絕整個網域可能連正常功能也一併影響。相關限制請參閱REJECT 規則寫法與比對限制。

如何選擇 FINAL 策略

FINAL 是未命中規則時的預設決定，不是「智慧判斷」開關。選擇 PROXY，表示未明確分類的連線會使用代理路徑；選擇 DIRECT，則表示未分類連線會直接連線。請依自己的設定目標、現有規則涵蓋範圍與可接受的失敗情況決定。只修改 FINAL 可能影響大量原本未注意到的連線，因此必須同時觀察正常與異常案例，不能只測試一個網頁就結束。

維護時應保留一條清楚的 FINAL，並放在規則序列末尾。多條 FINAL 不會形成備援路徑，較早出現的預設規則會先結束判斷。規則順序也不是伺服器故障切換機制；PROXY 規則命中後若連線失敗，不會因此自動繼續嘗試後面的 DIRECT。規則比對與建立連線是兩個階段，不能將後續規則當成連線失敗後的補救方式。

規則清單越來越長時，建議清除完全重複的項目，檢查被上方廣泛規則涵蓋的項目，並為重要例外保留修改紀錄。不要只為了按字母排序而重排整個 Rule 段，因為排序會改變優先順序。可讀性應配合執行順序：同一組中的精確例外、範圍規則與補充規則應相鄰放置，並讓最後的預設規則清楚可見，方便日後確認設定是否仍符合需求。

DNS 負責將主機名稱解析為位址，分流規則依可用條件選擇連線策略，Host 則可為指定主機設定位址對應。三者彼此相關，卻不能互相取代。頁面無法開啟時，先判斷是沒有取得位址、取得的位址不合適，還是位址可用但連線路徑失敗。直接更換所有 DNS 設定可能暫時改變現象，卻無法說明真正的故障位置。

General 中的 DNS 設定

dns-server = system 表示使用系統提供的解析設定。實際效果取決於目前的網路環境，不代表每次都會取得相同結果。若現有設定採用其他明確的解析方式，請保留其完整設定意義，先檢查欄位是否能被辨識、位址是否可連線，以及是否與現有設定相容。不要直接將網路上的一串解析位址加進來，尤其不要混入不熟悉用途的擴充參數後，就據此判斷規則是否有效。

[General]
dns-server = system

[Host]
router.example.com = 192.168.1.1

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

此範例將指定主機對應至私有位址，並明確為其指定 DIRECT。這裡同時列出 Host 與 Rule，是為了呈現解析結果與處理策略這兩個獨立目的。不能將「對應至本機位址」直接等同於「一定採用直連」，也不能認為只要有一條 DIRECT，就會自動產生正確位址。實際裝置還必須能連到該私有位址，且目標服務確實在對應連接埠運作。

Host 不會改變目標服務的身分

Host 可以改變連線使用的位址，但不會讓另一台伺服器成為原網域的合法服務。HTTPS 也會驗證憑證與主機名稱；若對應到錯誤位址，即使網路層能建立連線，也可能出現憑證錯誤或服務不相符。遇到這類問題，應撤除對應並核對位址，不要把關閉身分驗證當成一般解決方式。私有服務也需要正確設定自己的網域與憑證。

維護 Host 時，請留意位址可能改變。行動裝置切換網路後，原有私有位址可能不再可連，或已指向另一台裝置。固定對應適合明確、穩定且可以驗證的目標，不適合將某次解析結果長期固定給公用服務。使用分散式位址的網域尤其如此；固定單一 IP 可能略過正常的位址選擇，造成部分地區可用、部分網路失敗。

解析結果與規則命中的先後關係

網域規則可直接依網域判斷；位址規則則需要可用的 IP 資訊。有些位址判斷會涉及解析程序，前文的 no-resolve 正是用來控制是否為了比對而主動解析。若明確的 DOMAIN 規則已經命中，後續 GEOIP 不會推翻結果。因此分析連線記錄時，應一併查看目標網域、解析位址、命中規則與最終策略，不能只比較位址的地理分類。

記錄中只有 IP 時，不要立刻認定 Host 或 DNS 失效。App 可能直接連線至 IP，或目前的觀察階段未顯示網域資訊。反過來，能看到網域也不代表所有解析都經過相同路徑。排錯時應以可重現的單一請求為準，使用相同目標、相同網路與新建連線，逐步確認是哪個環節提供比對依據。

快取與既有連線會影響驗證

修改解析設定或 Host 後，既有連線不一定會立即改用新的目標位址，App 也可能保留解析結果。請先儲存設定，視需要重新建立連線，再讓目標 App 發出新請求。不要用仍在播放的媒體或長時間保持的訊息連線來判斷新規則；這些連線可能在修改前就已建立。即使重新載入頁面，也應檢查記錄，確認是否真的出現新的目標連線。

如果多個互不相關的網域同時解析失敗，應優先檢查目前網路與解析路徑，而不是逐一為網域新增 Host。若只有一個網域異常，先檢查拼字、既有對應與目標服務狀態。Host 是精確管理位址的工具，不是解決所有 DNS 問題的通用清單；讓對應保持少量、明確且可撤回，通常更有助於行動裝置在不同網路間穩定切換。

URL Rewrite 與 Rule 的用途不同。Rule 為連線選擇 PROXY、DIRECT 或 REJECT 等策略；URL Rewrite 則比對並改寫可處理的請求 URL。若要改變某個網域的連線路徑，應先使用 Rule，而非用 URL Rewrite 取代分流。只有在需要依完整 URL 特徵處理請求時，才進一步確認是否具備相應的請求可見性與處理條件。

先了解正規表示式比對的對象

URL Rewrite 的比對部分通常使用正規表示式，必須分清起始錨點、字元跳脫與比對範圍。網域中的點在正規表示式裡有特殊用途；若要表示字面上的點，應寫成 \.。開頭的 ^ 限定從 URL 起始位置開始比對；缺少必要邊界會擴大比對範圍。不要將正規表示式片段直接放進 DOMAIN，兩者使用的比對語法不同。

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

此例僅示範重新導向語法：比對指定主機上的精確路徑，將請求導向另一個路徑，並使用 302。結尾的 $ 限定字串結束，因此帶有查詢參數的 URL 不會自動符合此例。目標網址仍是語法範例，不應用作實際服務測試。與任意比對相比，先設定範圍明確且容易說明的條件，更容易確認重新導向是否只影響預期請求。

查詢參數、路徑邊界與重新導向迴圈

URL 中的路徑、查詢字串與主機名稱分屬不同部分。若要允許查詢參數，應明確設計比對範圍與保留方式，不能只刪除所有邊界，就期待行為維持不變。參數可能包含登入狀態、簽章或一次性識別資訊，隨意刪除會使請求失效。對於用於驗證的請求，應優先保持原樣，先在不涉及私人資訊的測試目標上了解運算式的實際結果。

也要確認改寫後的目標不會再次符合同一條規則。如果來源範圍涵蓋目標範圍，用戶端或目標服務可能不斷重新導向，最後呈現為頁面反覆載入或提示重新導向次數過多。多個改寫項目之間也可能互相指回。排錯時請依序列出「原始 URL、改寫目標、伺服器再次回傳的位置」，逐一確認每次跳轉，不要只看第一條運算式是否符合。

HTTPS 不會自動顯示完整請求

HTTPS 的路徑與請求標頭位於加密通訊中，不能假設一般分流已具備讀取及改寫完整 URL 的條件。網域分流可用，不代表路徑改寫也一定可用。處理 HTTPS 請求時，還須另外了解 App 內相關功能、憑證信任範圍與目標 App 的驗證方式；部分 App 可能採用更嚴格的憑證驗證，不能保證所有請求都能以相同方式處理。

REJECT 與內容處理的差異

Rule 中的 REJECT 針對符合條件的連線，不會分析頁面中的每個元素。若頁面內容與必要介面共用同一個網域，拒絕該主機也會一併影響其他請求。URL Rewrite 可以指定更精細的 URL 條件，但仍受實際可見性、協定方式與目標行為限制。不能將某條改寫或拒絕規則解讀成適用所有 App 的內容清理方案，也不應一概將載入失敗視為規則已達成目的。

驗證改寫時，應記錄原始 URL 的結構、預期目標與實際跳轉情形，不要儲存含有私人參數的完整網址後公開分享。檢查目標是否符合原本的協定需求、是否意外遺失路徑或參數，再確認最終頁面能否正常運作。和分流測試一樣，也要驗證一個不應受影響的請求，避免正規表示式範圍過廣而改變同一網站的登入、付款或其他必要流程。

維護時建議將暫時測試項目與長期需要的項目分開記錄，並刪除已無使用依據的運算式。遠端設定更新後，也要檢查相關規則的比對範圍是否改變。關於拒絕策略與網域範圍的進一步說明，請參閱REJECT 原理、比對範圍與限制；先了解連線層的界線，再決定是否確實需要在請求層處理。

有效的排錯應能回答四個問題：目標是什麼、命中哪條規則、採用什麼策略，以及最後在哪個階段失敗。只描述「打不開」，無法判斷問題出在規則、解析還是連線路徑。開始前先選擇一個可以重複存取的測試目標，記錄目前網路、使用中的設定與伺服器選擇，避免測試期間自動變更多項條件。測試資料應移除私人位址參數與驗證資訊。

建立最小可重現的規則組

先複製一份可還原的設定，再為目標新增一條範圍明確的 DOMAIN 規則，並放在可能涵蓋它的規則之前。儲存並確認已選取後，以 Config 模式建立新連線。查看請求或連線記錄中可取得的目標、規則與策略資訊；不同介面的呈現方式可能不同，請以目前 App 顯示內容為準。若已命中預期策略，就停止修改比對條件，改為檢查解析結果與路徑是否可連線。

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

此片段刻意將單一測試主機與其他連線分開，方便觀察規則選擇，並非通用設定建議。請以自己明確掌握的實際測試目標取代示例主機。驗證完成後，應將有效修改合併回原設定，並恢復原本的預設處理方式。不要因為暫時使用的片段較短，就忽略原檔案中的其他必要規則、一般參數與本機服務例外。

依現象分層排查，不要把所有失敗都歸因於規則錯誤

Connectivity Test 可協助判斷相關連線條件，但測試結果不能直接取代目標 App 的實際請求。某項測試有回應，不代表目標網域解析正確，也不代表所有協定、連接埠與資源都可用。反過來，單一測試失敗也須依測試方式解讀。請將診斷工具視為縮小問題範圍的線索，再以實際目標的新連線確認最終行為。

分別處理訂閱更新與規則更新

更新現有訂閱失敗時，先核對網址是否完整、目前網路與帳戶是否有效，不要立即重寫 Rule。伺服器列表空白與分流命中錯誤屬於不同層次的問題。單一分享連結與訂閱網址的更新方式也不同，不應將其中一種當成另一種重複匯入。入口辨識請參閱訂閱匯入的四種入口；格式差異請見分享連結與訂閱網址說明。

遠端設定更新後若行為改變，先比對變動的段落，再確認自行新增的例外是否仍然存在。不要同時更新訂閱、替換設定並更換伺服器，再試圖從單次結果推斷原因。訂閱內容空白或解析失敗的排查方式，請參閱訂閱更新失敗與列表空白自查。本頁僅說明設定與比對邏輯，不涉及服務來源推薦。

還原、重新測試與長期維護

若修改後出現範圍更大的異常，請先還原已知可用的設定副本，並核對 Global Routing、伺服器選擇與一般設定是否一併恢復。還原後重新建立連線，使用同一組目標再次測試，確認基準狀態仍可正常運作。不要在失敗的設定上不斷疊加互相衝突的例外；每條暫時規則都應說明用途，否則後續排錯會越來越依賴偶然結果。

長期維護建議保留簡短的變更紀錄：修改了哪個設定段、修改原因、哪些目標已驗證，以及如何還原。定期檢查失效網域、重複規則、範圍過廣的關鍵字與已不再使用的 Host 對應。關於購買項目還原、相容性與 App Store 搜尋問題，請參閱已購項目還原說明與商店搜尋核對步驟；若要重新依操作流程進行，請返回快速上手教學。