本頁是 Shadowrocket 官方手冊的系統查閱內容，適合在編輯設定、檢查分流或分析異常時依章節查找。首次加入現有訂閱、允許 VPN 設定並建立連線，請先閱讀快速入門教學；完成基本操作後，再回到這裡了解每條規則的生效原因。Shadowrocket 主要適用於 iPhone 與 iPad，系統需求請以 App Store 頁面標示為準。
開始前，請先備妥自己的訂閱或伺服器資訊。用戶端一次買斷 ≠ 線路方案，本站不提供、不販售也不推薦節點或訂閱服務。取得 App 與確認正版資訊，請使用App Store 下載說明。本文範例著重說明語法與適用範圍，不應整段取代目前使用的設定。
01 / 檔案與適用範圍
設定結構與生效條件
先區分伺服器資訊與設定檔
伺服器資訊決定請求透過哪個現有服務建立連線；設定檔則決定請求符合哪些條件時，應採取哪種處理方式。兩者彼此相關，卻不是同一回事。匯入訂閱後，Home 的 SERVER 清單可能已出現項目，但不代表 Config 已選取合適的分流設定。反過來說，寫有 PROXY 的規則檔也不會自動補上伺服器位址、連接埠或驗證資訊。檢查連線前，應分別確認目前使用的伺服器與選取的設定，避免把清單更新誤認為規則更新。
.conf 是用來編排設定文字的檔案格式。閱讀時，先找出以方括號括住的區段標題，再查看區段中的內容。General 通常包含全域參數，Rule 放置依序排列的比對規則，Host 用於網域對應，URL Rewrite 則包含網址重寫項目。區段標題不是一般說明文字；漏寫括號、把規則貼到其他區段，或編輯時刪除換行，都可能改變解析結果。不要只檢查某條規則的拼字，也要確認它位於哪個區段。
用精簡範例辨識各區段語法
[General]
bypass-system = true
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT
[Host]
lab.example.com = 192.168.1.20這段範例包含三種不同的寫法。General 與 Host 使用等號表示參數或對應關係，Rule 則以英文逗號分隔規則欄位。網域後綴規則的第二個欄位是比對值，第三個欄位才是策略；FINAL 沒有獨立的比對值，因此後面直接接策略。範例中的私有位址僅用於說明 Host 格式，只有在使用者的實際網路中存在對應主機時才有意義。這不是推薦設定，也不包含建立連線所需的所有資訊。
不同區段的語法混用是常見錯誤，例如把 DOMAIN-SUFFIX 後面的逗號改成等號，或把 Host 對應寫成一條 Rule。複製程式碼時，也要檢查標點是否變成中文全形字元、網域兩側是否帶有從網頁複製來的引號，以及檔案是否混入富文字格式。儲存後先查看 App 是否回報解析問題；若有行號，也要檢查該行及前一行，因為缺少換行或區段邊界錯誤可能到下一行才顯現。
儲存、選取與套用是三項檢查
完成設定編輯後，先儲存，再回到 Config 確認目前選取的是剛修改的檔案，最後核對 Home 中的 Global Routing 是否設為 Config。只修改未選取的檔案，不會讓目前連線依新規則運作；若處於 Proxy 或 Direct，也不能把請求結果當作 Rule 順序的驗證。App 內各頁面的入口位置可能調整，請以目前畫面為準；但「檔案內容、選取項目、執行模式」這三項仍應分開記錄。
遠端設定與本機編輯也應分開管理。若檔案之後會從遠端網址更新，本機加入的規則可能在更新時被取代。需要長期保留的修改，請先透過 App 支援的檔案管理方式建立獨立副本，再進行編輯，並保留原檔以便還原。不要一次修改唯一可用設定中的多個區段。先驗證一條網域規則，再加入其他規則；若出現異常，才容易判斷是內容錯誤、選取錯誤，還是更新造成覆蓋。
若想先掌握檔案區段的閱讀方式，可搭配.conf 結構詳解逐段對照。閱讀本文後續章節時，請保留目前檔案的完整上下文：單獨一行寫法正確，只能代表該行符合某種語法，不代表整份設定適用於目前網路與用途。
02 / 全域參數與網域對應
General 與 Host
General 不能取代 Rule
General 中的參數會影響整份設定的處理環境，不能把它當成依網站逐條分流的清單。例如 bypass-system = true 表示與系統流量旁路相關的設定，不代表「所有網站都走 DIRECT」。這類設定可能讓部分流量不進入一般規則判斷，因此分析請求時，應先確認該請求是否在可觀察及處理的範圍內。不要只因設定中有 FINAL，就推定裝置上的所有連線都必定經過該規則。
修改全域參數前，先說明要解決的具體問題：是網域解析失敗、區域網路存取異常，還是某類請求沒有出現在記錄中。只有釐清問題，才能判斷相關參數是否適合修改。直接用網路上看到的一整段 General 覆蓋原設定，可能同時改變 DNS、旁路與連線行為；之後即使網站恢復，也難以確認是哪項修改產生作用。請保留原值，一次只調整一個參數，再用相同請求進行比較。
[General]
bypass-system = true此範例僅展示布林參數的寫法：參數名稱、等號和值都保留英文原文。不要只憑名稱自行推演其他參數，也不要把其他設定格式中的鍵名直接搬進 .conf。App 可辨識的參數及其實際作用，請以目前 App 支援的內容為準。遇到不熟悉的鍵名，先查看現有設定說明與 App 提示，不要反覆嘗試相近拼法。檔案能儲存，不足以證明每項參數都會按預期生效。
Host 變更對應關係，不直接指定策略
Host 的基本用途是將指定網域對應至指定位址。它回答「這個名稱對應哪個位址」，Rule 則回答「這個請求應採取什麼策略」。將網域加入 Host，不代表將它設為 DIRECT；若網域規則先比對到 PROXY，請求仍會依比對結果處理。相對地，Host 對應生效後，後續涉及目標位址的判斷可能會使用不同的位址值。分析這類設定時，應分別列明名稱、解析結果與策略。
[Host]
lab.example.com = 192.168.1.20
[Rule]
DOMAIN,lab.example.com,DIRECT
FINAL,PROXY此處同時列出對應關係與網域規則，是為了說明兩者的分工。lab.example.com 是範例名稱，192.168.1.20 是私有位址，實際使用時必須換成使用者自己網路中確實存在的主機。即使規則選擇 DIRECT，裝置仍須具備存取該私有位址的網路條件。若不在相應區域網路，或目標裝置未開啟所需服務，即使規則比對正確，連線也不會成功。分流判斷與目標可連線性不能混為一談。
檢查 DNS、快取與連線重用的界線
Host 不會自動變更應用層識別資訊。存取 HTTPS 網域時，伺服器憑證仍應符合所存取的名稱；若對應到未提供該網域服務的位址，可能出現憑證或交握錯誤。此時繼續新增 DIRECT 規則通常無法解決問題。請先檢查目標位址是否正確、服務是否在相應連接埠監聽，以及伺服器是否確實為該網域提供服務。不要用放寬無關設定的方式掩蓋名稱與服務不一致的問題。
變更網域對應後，舊的解析快取或既有連線可能暫時影響觀察結果。先結束目標 App 的相關工作階段，再發出新請求；必要時使用 App 內可用的工具檢查 DNS 結果，並區分新請求與舊連線。記錄應包含測試網域、預期位址、實際位址與命中策略。若只記下「網頁無法開啟」，就無法判斷是對應未套用、服務無法連線，還是請求沒有重新建立。維持相同測試條件，比反覆切換許多開關更有助於排錯。
最後檢查設定中是否同時存在同名 Host 項目、較寬泛的網域規則與位址規則。不要依賴重複對應項目的先後順序來表達意圖；能合併為一條明確對應時，請先合併。公共網站的位址可能隨服務部署而變動，長期固定對應需要使用者自行維護；自有區域網路服務則應確認裝置位址穩定。維護規則不只是確保文字能解析，也要讓設定中的名稱持續符合實際網路狀況。
03 / 名稱比對
DOMAIN 與網域規則
依完整名稱、後綴與關鍵字選擇範圍
網域規則主要用於處理「已知請求名稱」的分流。DOMAIN 適用於單一完整網域，DOMAIN-SUFFIX 適用於該網域及其子網域，DOMAIN-KEYWORD 則依名稱是否包含指定文字進行判斷。這三種規則都不會比對 URL 路徑：網域後的斜線、查詢參數與頁面片段都不是這些規則的比對值。若只想處理 api.example.com，不應填入含 https:// 的完整網址，也不要期待網域規則能區分同一主機上的不同頁面。
| 類型 | 範例值 | 比對範圍 |
|---|---|---|
DOMAIN | api.example.com | 指定的完整主機名稱，不延伸至其他子網域。 |
DOMAIN-SUFFIX | example.com | example.com 本身及其子網域，不代表任何包含該字串的名稱。 |
DOMAIN-KEYWORD | example | 名稱中包含指定文字，可能涵蓋不同網域後綴。 |
選擇規則時，應先採用能準確表達需求的較小範圍。指定主機使用 DOMAIN；整組子網域有共同策略時使用 DOMAIN-SUFFIX；只有確實需要跨網域後綴依文字比對時，才考慮 DOMAIN-KEYWORD。關鍵字不必然代表某個組織或服務；其他名稱只要包含相同文字，也可能落入比對範圍。將短而常見的詞設為關鍵字，很容易影響原本不打算處理的請求，而且這種誤比對通常不會造成語法錯誤。
以具體例外優先處理寬泛規則
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,REJECT
FINAL,DIRECT在這組教學範例中，api.example.com 先符合精確規則，採用 DIRECT；www.example.com 不符合第一條，但會符合後綴規則，採用 PROXY；其他包含 example 字樣、卻不屬於 example.com 的名稱，才可能符合關鍵字規則而遭拒絕。這不是 App 自動比較三種規則哪個更精確，而是前面規則先符合後就停止判斷。若將關鍵字規則放在最前面，後兩條就無法為同樣包含該字樣的請求提供例外。
DOMAIN-SUFFIX 的值通常寫成 example.com，不需要加前置星號，也不要將萬用字元寫法與此類型混用。它表示網域標籤邊界上的後綴關係，因此 notexample.com 不會只因結尾字元相似，就被視為 example.com 的子網域。對於含特殊字元、國際化網域或經 App 內部轉換的名稱，請查看請求記錄中實際顯示的形式，再依真實主機名稱撰寫規則，不要只憑瀏覽器網址列的視覺文字推斷。
請求名稱不一定等於網址列中的名稱
一個頁面通常會包含多個請求。主文件可能來自一個網域，圖片、指令碼、登入與介面則可能分別來自其他網域。為網址列中的網域新增規則後，頁面仍有部分內容異常，不一定代表規則無效；應檢查失敗的那個請求使用了什麼名稱。App 也適用相同原則：App 名稱不等於它使用的所有服務網域，不能根據圖示或產品名稱推導出完整網域清單。本文不提供服務網域清單，請以使用者實際的請求記錄為準。
若連線只有目標 IP，沒有可供規則使用的網域資訊，網域規則就無法憑空推導出名稱。另有一些請求可能經過快取、App 內部解析或不同的連線方式，記錄中的主機欄位也可能與預期不同。排錯時先確認記錄是否包含網域，再判斷是否應套用網域規則。不要把「沒有符合 DOMAIN」直接歸因於用戶端忽略規則；該請求可能並未以填寫的名稱進入比對流程。
測試網域規則時，至少準備三種對照：預期會符合的完整名稱、同一群組中的另一個子網域，以及不應受影響的相似名稱。每次只修改一種規則類型，觀察符合項目與策略是否隨之變化。想進一步了解各類關鍵字的範圍，可閱讀規則寫法入門與比對範圍對照。記錄這些邊界案例，比只確認一個網頁能否開啟，更能避免日後誤比對。
04 / 位址、地區與其他條件
IP-CIDR、GEOIP 與其他規則
IP-CIDR 依位址範圍判斷，不依網站名稱判斷
IP-CIDR 的比對值是 IPv4 位址與前綴長度。192.168.0.0/16 表示一個私有位址範圍，不是只比對 192.168.0.0 這一台主機；前綴越長，涵蓋的位址範圍通常越小。撰寫前先確認目標實際位於哪個網段，不要為了方便而不斷擴大範圍。某網站偶爾解析到某個位址，不代表整個位址範圍都應採用相同策略，尤其是共用基礎設施時，同一網段可能承載多個互不相關的服務。
[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
FINAL,PROXYIPv6 位址範圍應使用 IP-CIDR6。範例中的 fc00::/7 是 IPv6 本機位址範圍，不能將 IPv6 文字直接填入 IP-CIDR，然後期待得到相同結果。私有或本機位址的 DIRECT 規則只決定連線方式，不會建立通往目標網路的路由，也不會變更目標裝置的存取權限。若裝置不在相應網路、位址衝突或服務未監聽，即使符合 DIRECT，連線仍可能失敗；請繼續檢查網路與服務本身。
no-resolve 的重點是避免為這條位址規則額外觸發網域解析。對於目標本身已是 IP 的請求，仍可依現有位址進行比對；對於只有網域、缺少可用位址資訊的請求，則不要期待含有 no-resolve 的位址規則必定能辨識。它不是讓整個用戶端停止解析的總開關，也不是宣告某個網域永遠略過 DNS。分析時應一併查看請求是否已有位址，以及前面的網域規則是否已處理該請求。
GEOIP 反映位址資料，不代表服務歸屬
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYGEOIP 依目標位址及相應地區資料進行判斷。GEOIP,CN,DIRECT 表示目標位址符合地區代碼 CN 時選擇 DIRECT，不是依註冊主體或使用者所在地分類。網域可能解析到不同地區的位址，位址資料庫也可能與實際部署狀況有落差。因此，對於明確需要固定策略的重要網域，應將規則放在 GEOIP 之前，而不是把地區判斷當成精確的服務分類表。
若相同網域在不同時間得到不同策略，先檢查解析位址是否改變，再檢查地區規則的位置。不要在沒有記錄的情況下，認定是 GEOIP 自行改變了順序。也要區分目標位址所屬地區與代理出口所在地區，兩者不是同一欄位；規則比對的對象與使用者之後觀察到的出口結果也不能互相取代。排查位址問題時，請保留測試時的網域、位址與命中項目，否則下一次請求可能已連到不同目標。
USER-AGENT 與 FINAL 的適用範圍
[Rule]
USER-AGENT,ExampleApp*,PROXY
FINAL,DIRECTUSER-AGENT 依可讀取到的 User-Agent 資訊進行比對。ExampleApp* 是教學用模式，不是實際 App 清單，也不會依裝置中的 App 名稱識別程序。加密請求的相關欄位不一定都能讀取，因此不能把這條規則理解為能可靠分類某個 App 的所有流量。不要為了讓範例符合而額外啟用不熟悉的憑證或解密設定；優先採用能從現有請求資訊中驗證的網域或位址條件。
FINAL 用於處理其餘請求，不必再填寫網域或位址。它應放在 Rule 區段的最後，明確指定尚未由前文規則處理的請求要如何處理。若將 FINAL 放在中間，後面的普通規則就沒有機會處理其餘請求。檢查較長的檔案時，可先搜尋 FINAL，確認只有一條且位置明確，再檢查前面的具體規則。USER-AGENT、地區與位址規則可取得的資訊各不相同；選擇規則前先確認請求提供哪些資訊，比不斷增加條件更有效。
05 / 執行結果與全域模式
策略與 Global Routing
PROXY、DIRECT、REJECT 各自處理不同問題
規則前半段用來判斷是否符合條件，策略欄位則決定符合後如何處理。PROXY 表示使用目前的代理選擇，DIRECT 表示直接連線至目標，REJECT 表示拒絕該請求。策略名稱不是網域，也不是伺服器位址；不能將 PROXY 改成臨時說明文字，就期待 App 自動理解。若原設定使用命名策略群組，請先確認相應項目確實存在及其選取關係，再引用名稱。本文以基本策略作為範例，避免可複製片段中出現未定義的群組名稱。
| 策略 | 符合後的處理方式 | 仍須核對 |
|---|---|---|
PROXY | 交由目前選取的代理處理。 | 伺服器資訊、驗證、網路可連線性與服務狀態。 |
DIRECT | 直接連線至目標。 | 區域網路、解析結果與目標服務是否可連線。 |
REJECT | 拒絕符合條件的請求。 | 規則範圍是否過廣，以及是否影響必要的相依服務。 |
符合 PROXY 不代表請求一定成功。伺服器資訊失效、驗證不符、網路限制或目標服務異常，都可能發生在規則判斷之後。同樣地，DIRECT 也不是「保證成功」的指令，只會改變連線路徑。排錯時應區分兩個階段：先查看選用了什麼策略，再檢查該策略下連線失敗的原因。只憑頁面是否開啟來反推規則是否符合，容易把傳輸問題誤認為語法問題。
Global Routing 決定是否依設定進行分流
Global Routing 有三種模式：設定 Config、代理 Proxy、直連 Direct。這些介面用語與 Rule 中的大寫策略詞相關，但屬於不同層級。Config 會依目前選取的設定處理請求；Proxy 與 Direct 可用於觀察相應全域模式下的結果。驗證 DOMAIN 或 IP-CIDR 規則時，應先切回 Config，否則即使檔案完全正確，觀察到的流量也未必依該段 Rule 進行判斷。
| 介面模式 | 檢查重點 | 測試用途 |
|---|---|---|
| 設定 Config | 目前使用的設定、規則順序與策略。 | 驗證本文中的分流範例。 |
| 代理 Proxy | 目前的代理選擇與連線狀態。 | 協助區分代理連線問題與分流問題。 |
| 直連 Direct | 區域網路與目標服務。 | 協助確認直連路徑是否可用。 |
切換模式只是用來對照的操作，不應直接當成長期解決方案。某個請求在 Proxy 下成功、在 Config 下失敗，可能是 Config 中選了 DIRECT，也可能是符合 REJECT，或目前使用的根本不是預期檔案。請回到記錄確認實際結果，再修改相應規則。測試完成後，請恢復原先的模式，避免使用環境已改變，卻仍依舊條件解讀結果。
使用拒絕策略時，保留例外與還原方式
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY這段範例展示同一後綴下的不同處理方式，不代表這些範例名稱實際提供特定服務。api.example.com 先指定為 PROXY，metrics.example.com 個別拒絕，其餘 example.com 子網域才採用 DIRECT。若將後綴規則移到最前面，兩個具體例外就不會依原意執行。策略設計與順序設計必須一併檢查，不能只確認最後一個策略欄位的拼字是否正確。
使用 REJECT 時，請留意業務相依關係。看似只是輔助功能的請求，可能參與登入、資源驗證或工作階段續期。若部分功能異常，先暫時移除該條拒絕規則並重新建立請求，不要一次刪除整個規則區段。確認因果關係後，再縮小比對範圍或新增前置例外。若要確認 Global Routing 與 Home 的位置關係，可閱讀首次開啟與 Home 區塊說明；伺服器本身是否可用，仍須另外驗證。
06 / 順序與衝突
比對順序與優先級
先符合的規則先決定結果
Rule 區段依序檢查一般比對規則，符合後便採用相應策略，不會繼續尋找「看起來更精確」的後續條件。因此，優先順序首先取決於排列位置，而不是規則名稱。DOMAIN 不會自動優先於 DOMAIN-SUFFIX，IP-CIDR 也不會自然排在 GEOIP 之後。撰寫設定時，可採用「具體例外在前、一般範圍在後、FINAL 收尾」的編排方式，讓閱讀順序與實際判斷順序一致。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY以 api.example.com 為例，第一條規則已足以決定採用 DIRECT，不會再因後綴屬於 example.com 而改用 PROXY。對於 www.example.com，第一條不符合，第二條符合後便結束判斷。若直接存取私有位址，而前面的網域條件未參與或未符合，則可繼續比對 IP-CIDR。只有此前都未符合的請求才會進入 GEOIP 或 FINAL。逐條模擬時，應明確指出每個步驟使用了哪些請求資訊，不要假設所有請求都同時具備完整網域與位址。
重疊不一定有錯，遮蔽則需要釐清
一條精確網域規則與一條後綴規則同時涵蓋相同請求，可能是刻意設計的例外；若兩條完全相同的條件指向不同策略，通常就需要合併或補充說明。完全相同的條件出現多次，不會讓同一請求有第二次選擇。檢查大型設定時，先找完全重複項，再找包含關係，最後檢查關鍵字與後綴之間的交集。不要只看行數判斷規則是否完整；重複項會增加維護負擔，卻未必帶來有效作用。
若將一條規則從底部移到頂部後問題消失，還應進一步找出它原本被哪條規則遮蔽。直接養成「所有新增規則都放最上面」的習慣，會讓頂端逐漸累積彼此衝突的例外。正確做法是找出最早符合的寬泛條件，將必要例外放在它前面，並保留清楚的業務分類。同一網域若多次加入相反策略，只會讓後續維護者難以判斷哪條才代表真正意圖。
用請求清單驗證規則移動的影響
編輯前可先列出一份簡短的預期清單，至少包含「目標、預期策略、預期符合條件」三項。選擇一個具體例外、一個一般子網域、一個私有位址與一個兜底目標。移動規則後，除了測試剛才出問題的目標，也要重新檢查其他對照項。這樣才能發現修正一個例外，卻破壞整個後綴範圍的情況。測試目標應來自使用者的實際用途，不能以本文範例網域是否能存取，作為設定正確與否的標準。
位址規則之間的順序也遵循相同原則。例如，較小的位址範圍需要 PROXY，而它所屬的大範圍設為 DIRECT，就應將較小範圍放在前面。若 GEOIP 先處理某個位址，後面的位址例外可能就沒有機會執行。此處的「具體優先」是由撰寫者透過排序表達的規則，不是執行時自動按前綴長度進行全域排序。不要把網路路由表的其他比對習慣直接套用到 Rule 清單。
若設定包含遠端規則引用或其他擴充內容，也應確認這些內容在整個判斷鏈中的位置。不能只看手寫的幾行，就推定檔案前面沒有更寬泛的條件。遇到無法解釋的命中結果，請回到完整檔案，從 Rule 開始依實際順序檢查；必要時複製一份精簡測試設定，再逐步加入項目。簡化是為了找出影響條件，確認後仍應恢復原設定中的必要區段，不要長期以刪減過度的檔案取代完整設定。
07 / 網址重寫與組合範例
URL Rewrite 與常見寫法
重寫網址不等於指定代理策略
URL Rewrite 用於依模式處理請求網址，與 Rule 中選擇 PROXY、DIRECT 或 REJECT 是兩種不同操作。網域分流決定連線路徑；重寫項目則可能變更請求指向的網址或傳回重新導向。不要為了讓某網域走代理而新增重寫規則，也不要把一般網域規則貼進 URL Rewrite。若只需選擇存取路徑，優先在 Rule 中設定；只有確實需要變更網址行為時，才考慮重寫區段。
[URL Rewrite]
^http://example\.com/ https://example.com/ 302這條範例由比對模式、替換網址與重新導向狀態碼組成，用於說明範圍有限的 HTTP 至 HTTPS 網址重新導向。模式中的句點使用反斜線跳脫，開頭的 ^ 限定從網址起始處比對，網域後的斜線則用來標示主機邊界。不要由這條簡短範例推斷任意原始路徑與查詢參數都會依預期保留；若用途需要保留這些內容，必須明確設計擷取與替換方式，並逐項驗證實際結果。
對 HTTPS 請求而言，網址中的路徑等資訊不一定能以相同方式讀取。一般網域分流不需要看見完整 URL，但路徑層級的重寫需要相應請求資訊可供讀取。因此，「網域規則能符合」不能證明重寫模式也一定能執行。不要為了測試範例而隨意新增憑證或解密設定。先確認目前的請求類型與 App 可觀察到的資訊，再判斷是否適合使用 URL Rewrite；若無法確認，保留原本請求行為更有利於排錯。
將規則意圖拆成可分別驗證的組合
[Rule]
DOMAIN,lab.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY
[Host]
lab.example.com = 192.168.1.20這組範例同時展示區域網路名稱對應、單一網域拒絕、整個後綴走代理，以及私有位址直連。閱讀時先看兩條具體網域例外，再看後綴範圍，最後查看位址與兜底規則。lab.example.com 對應至範例私有位址，前置的 DOMAIN 規則則明確選擇 DIRECT；blocked.example.com 先被拒絕，不會被後面的後綴 PROXY 覆蓋。範例不包含額外重寫，是為了讓每個項目都能在較少變數下分別核對。
實際使用時，請先複製一份現有設定，只加入最必要的一條規則。若只有某個介面需要不同策略，先加入精確的 DOMAIN 即可，不必同時引入 Host、GEOIP 與重寫。精確規則通過驗證後，再考慮是否應擴大到 DOMAIN-SUFFIX。設定的複雜度應來自實際需求，而不是範例包含了多少種關鍵字。每增加一個區段，就多出一個需要分別說明與測試的處理環節。
避免循環、過寬模式與訂閱概念混淆
測試重新導向時，應留意最終網址與跳轉次數。如果新網址再次符合原模式，或目標網站又把請求導回原網址，就可能形成循環。先選擇單一可控路徑觀察回應，再擴大比對範圍。正則表達式中的句點、問號與括號都有特殊含義，不能未經檢查就把一般 URL 當成模式使用。模式範圍過寬，即使語法有效，也可能處理原本不該修改的請求，造成登入狀態或資源路徑異常。
伺服器訂閱與設定檔網址也不能混為一談。使用者現有的訂閱用來匯入伺服器項目，不一定會傳回 .conf 文字；設定檔網址則應傳回 App 能辨識的設定內容。範例 https://example.com/sub?token=xxxx 只是明顯的假值，不是可用服務。若使用不確定的網址匯入 Config 後出現解析錯誤，請先確認回傳內容類型、帳戶狀態與網址用途，不要試圖靠新增 Rule 關鍵字，修復實際上並非設定檔的回應。
分享設定供他人檢查時，只保留重現問題所需的規則與區段，並移除個人訂閱網址、驗證資訊及其他敏感內容。請說明「預期哪個請求採用什麼策略」，不要只貼出整份檔案讓他人猜測。常見介面用語與策略名稱可參閱概念速查。組合設定的目標，是讓每個處理環節都有清楚的解釋，而不是讓一份檔案負責所有可能的網路調整。
08 / 操作流程
驗證、維護與排錯
依固定順序完成一次有效測試
有效測試需要固定輸入與環境。先記錄目前網路、Global Routing 模式、選取的設定與代理選擇，再記下要測試的完整主機名稱及預期策略。儲存修改後，回到 Config 確認檔案，再切回 Config 模式，並重新發出目標請求。測試期間不要同時更新訂閱、更換伺服器或切換網路，否則請求恢復或失敗都無法歸因於單一變數。設定排錯的關鍵在於可重複，而不是連續按下許多按鈕。
在 App 內可用的請求記錄或診斷頁面中，重點核對目標網域、目標位址、命中規則與策略；具體欄位請以目前介面為準。有些請求可能不會提供全部資訊，請如實記錄缺少的欄位。Connectivity Test 可協助了解特定測試條件下的連線狀況，但不能取代實際業務請求的規則驗證。測試成功只代表該測試對象與條件得到某種結果，不能保證所有網站或 App 請求都採用相同路徑。
- 確認檔案已儲存，且 Config 選取的是該檔案。
- 確認 Global Routing 設為 Config，並檢查目前的代理選擇。
- 結束舊工作階段，再發出一個明確的新請求。
- 核對命中條件與實際策略，不要只看頁面是否開啟。
- 重新測試例外、一般範圍與兜底目標，確認影響邊界。
依現象區分解析、比對與傳輸問題
若設定無法正常讀取，請先處理文字結構：檢查區段標題、英文標點、欄位數量與策略名稱。DOMAIN 規則通常包含類型、值與策略三部分；FINAL 則直接接策略，不應為了湊欄位而多填網域。檢查複製程式碼時是否混入說明文字，尤其是網頁標題、行號與自動換行符號。確認 App 能辨識檔案後，再討論它如何處理請求，避免解析尚未完成就開始研究網路表現。
若檔案可讀取但比對結果不正確，請依序檢查目前是否選取了正確檔案、是否處於 Config 模式、請求實際名稱是否符合規則、前面是否有更寬泛的規則，以及 FINAL 是否過早出現。若網域規則無法使用名稱，請檢查請求是否只提供目標位址；若位址規則含有 no-resolve，請確認是否已有可用的位址資訊。每個判斷都應找到相應證據，不要把所有未觀察到的命中結果都稱為「規則失效」。
若規則符合正確但連線失敗，就進入傳輸層排錯：PROXY 檢查使用者現有的伺服器資訊與驗證，DIRECT 檢查區域網路及目標服務，REJECT 則先確認是否確實要拒絕。DNS 失敗、連線逾時與憑證錯誤發生於不同階段，不應透過同一種規則修改來處理。可暫時使用 Proxy 或 Direct 對照同一目標，但測試後應恢復原模式，再回到 Rule 修正真正的問題。
修改後仍顯示舊策略，應先檢查什麼？
先確認選取的檔案與 Global Routing，再結束舊連線並發出新請求。確認記錄來自新工作階段後，再繼續排查快取、前置規則或遠端更新造成的覆蓋。
符合 PROXY 後仍然逾時，還需要新增網域規則嗎？
通常應先檢查現有伺服器是否可連線、驗證資訊是否正確，以及目標服務是否正常。既然已符合預期策略，重複新增相同網域條件，無法直接解決後續連線失敗。
保留可還原的維護記錄
維護設定時，應保留修改前後的差異、修改原因與驗證目標。可以在自己的記錄中寫明「將某個精確網域移到後綴規則之前，以保留直連例外」，不要只寫「最佳化規則」。定期整理重複項目、長期未使用的例外與失效的 Host 對應，但不要在同一次維護中大幅調整所有層級。遠端設定更新後，請重新確認本機例外是否仍存在，以及原有順序是否改變。
遇到無法解釋的問題時，先還原至最近一次驗證可用的檔案，確認基本連線恢復，再於副本中重現單一修改。若還原後仍然失敗，應考慮網路、服務或訂閱狀態已改變，不要一味認定問題只出在剛修改的規則。需要重新檢查首次連線流程時，請返回快速入門教學；需要確認 App 來源與已購項目還原方式，請查看已購項目還原說明。提交排錯資訊前，請先移除個人憑證，只保留最精簡的規則、請求條件與實際結果。