01 / 檔案結構
設定檔結構：先釐清四種用途
Shadowrocket 設定檔以分段文字組成。方括號中的段落名稱用來區分用途，各段再填入參數、規則或對應資訊。閱讀檔案時，先找出 [General]、[Rule]、[Host] 和 [URL Rewrite]，再查看各段內容。設定檔不等於伺服器清單：伺服器負責建立連線，設定則規範各類請求的處理方式，兩者須配合目前的執行狀態判讀。
段落名稱決定內容的解讀方式
[General] 放置設定層級的參數，通常採用鍵值格式；[Rule] 放置依序比對的分流條件；[Host] 設定指定主機名稱的本機 IP 對應；[URL Rewrite] 處理符合運算式的請求網址。將有效規則放進錯誤的段落，不會使它自動成為有效的分流規則。排錯時應先確認段落位置，再檢查規則是否精確。
# 分段結構示意；並非完整的連線設定
[General]
dns-server = system
[Rule]
DOMAIN,example.com,DIRECT
FINAL,PROXY
[Host]
test.example.com = 192.0.2.10
[URL Rewrite]
^http://example\.com/ https://example.com/ 302以上四段展示不同語法，不代表每份設定都必須包含全部內容。若不需要本機對應，可不加入 Host 項目；若沒有明確的網址改寫需求，也不必加入 URL Rewrite。精簡設定的價值在於容易理解：每項設定都應對應實際需求，而不是為了讓檔案看起來完整，加入用途不明的參數。
設定、伺服器資訊與訂閱分開管理
使用者已有的伺服器資訊通常包含位址、連接埠、協定與驗證參數。訂閱用於集中匯入或更新這些項目；設定檔則另外描述分流方式。匯入成功只代表某類內容已加入 App，不表示伺服器可連線、設定已選取，或規則會依預期執行。檢查時應分別確認這三件事，不要以「訂閱已更新」取代「目前使用正確的設定」。
在 App 的 Config 中查看目前設定，確認名稱與內容，再回到 Home 檢查 Global Routing。只儲存本機檔案，不代表它已成為執行中的設定。遠端設定與本機副本也可能名稱相近，修改前先確認編輯的對象。若設定來自使用者自行管理的來源，也應確認後續更新是否會覆蓋本機修改；需要保留測試版本時，先另存一份容易辨識的副本。
| 設定段落 | 用途 | 勿與以下內容混淆 |
|---|---|---|
General | 設定層級的執行參數 | 不是依序比對的規則清單 |
Rule | 條件比對與策略選擇 | 不儲存伺服器驗證參數 |
Host | 主機名稱與 IP 的本機對應 | 不直接指定 PROXY 或 DIRECT |
URL Rewrite | 依運算式處理請求網址 | 不等同於網域分流 |
編輯前先建立可還原的基準版本
首次維護較長的設定檔時，先記錄目前可正常連線的目標、選用的伺服器與 Global Routing，再儲存原始檔案。不要在同一次測試中同時更換 DNS、重排所有規則並新增改寫。若結果改變，單項修改才能協助判斷原因。為設定加上註解時，說明「為何需要這項例外」會比重述規則字面內容更有幫助，例如指出某個內部主機必須透過本機網路連線。
語法方面也應檢查英文逗號、段落名稱拼字、意外換行，以及複製時帶入的全形符號。建議將註解獨立成行，避免被誤認為欄位。規則片段可分批加入，儲存後確認 App 的提示，再重新建立需要驗證的連線。若只想快速了解各段用途，可閱讀設定檔各段用途；本頁後續章節會進一步說明比對範圍與驗證方法。
02 / 生效條件
General：執行參數與 DNS 的界線
General 用來提供設定層級的執行條件，不能取代 Rule 決定各個目標的連線出口。排查「同一條規則為何結果不同」時，須一併檢查網域解析、目標 IP、目前網路與實際選用的設定。尤其是 IP-CIDR 或 GEOIP，能否取得目標 IP 會影響後續判斷；只看一行規則而不檢查解析過程，通常無法完整解釋結果。
從必要的最少參數開始查看
General 的參數採用鍵與值對應的格式。不要把其他地方看到的長串參數整批加進現有檔案，因為部分設定會改變解析、網路接管或位址處理方式。查看不熟悉的參數時，先在 App 內確認說明，再判斷是否與目前問題相關。沒有明確目的的設定應維持原狀，不要為了「最佳化」同時修改多項執行條件。
[General]
# 使用系統提供的 DNS 解析設定
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT這段範例僅說明 DNS 設定與 Rule 段落彼此獨立。dns-server = system 表示使用系統的解析設定，不代表每個網域都會回傳相同 IP，也不代表所有網路環境的解析結果都一樣。切換網路、解析快取，以及目標本身的位址調度，都可能改變回傳內容。判斷個別請求時，應以當下可確認的資訊為準。
網域規則與 IP 規則需要不同資訊
DOMAIN 類規則需要可辨識的目標主機名稱；IP-CIDR 與 GEOIP 則需要 IP 資訊。以網域發出的請求，可能先依網域規則決定策略，也可能在後續比對時涉及 IP 解析。不能簡單認為「網域在某地註冊，所以必定符合某條 GEOIP」，因為 GEOIP 判斷的是 IP 及其資料庫歸屬，而不是網站名稱或註冊資料。
解析使用的路徑，與後續業務連線使用的路徑是兩回事。看到一筆 DNS 請求，不能直接推斷後續網頁連線一定使用相同出口；看到業務請求命中 PROXY，也不能據此認定所有解析都經過同一部伺服器。排錯時應將「取得 IP」與「連線至目標」分成兩個階段記錄，分別確認錯誤發生在哪裡，避免一律將逾時歸咎於規則。
分別檢查 IPv4、IPv6 與快取
只有 IPv4 網段規則時，不應假設也涵蓋 IPv6 目標。若某次連線實際使用 IPv6，應檢查 IP-CIDR6 與相應策略，而不是繼續擴大 IPv4 網段。同一個網域在不同請求中也可能使用不同的位址類型。驗證設定不必先停用某種位址類型；優先記錄實際目標 IP，再依該 IP 所屬的規則進行判讀。
快取與既有連線可能讓設定修改後的效果無法立即反映在觀察結果中。App、瀏覽器與網路層可能各自保留資訊；長連線也不一定會因儲存設定而重新建立。完成修改後，先確認設定仍處於選取狀態，再關閉測試目標的舊連線或重新送出請求。是否需要重新連線，取決於修改項目與 App 提示，不應把反覆切換連線當成唯一的排錯方式。
系統網路條件不屬於規則本身
本機網路需要登入、Wi-Fi 無法連線至目標，或伺服器主機名稱解析失敗，都可能讓語法正確的設定無法使用。這時新增更多 DOMAIN-SUFFIX 並不能修復底層連線。先確認裝置已連上可用網路，再檢查使用者已有伺服器是否可連線及驗證資訊是否正確，最後再驗證業務目標的分流。依此順序檢查，可以區分規則問題與網路問題。
維護 General 時，建議一併記錄修改前後的網路類型、解析設定與測試目標，但不要記錄實際驗證資訊。若只有某個網路發生異常，可保留另一個網路作為對照，逐項比較即可。權限與首次啟動的步驟請參閱入門指南；Global Routing 模式選擇請參閱代理模式說明。不要用執行參數來彌補尚未確認的伺服器或權限問題。
03 / 主機名稱比對
DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD
網域規則適合用來指定「這個主機或這組主機應採用哪種策略」。三種常見寫法的差異在於涵蓋範圍，並非哪一種比較進階。需要精確例外時使用 DOMAIN；需要包含根網域與子網域時考慮 DOMAIN-SUFFIX；只有確實需要依名稱片段進行廣泛比對時，才使用 DOMAIN-KEYWORD。比對範圍越廣，越需要留意誤命中的可能。
DOMAIN：為單一主機設定明確例外
DOMAIN,api.example.com,PROXY 只比對完整主機名稱，不會因為名稱包含 example 就自動涵蓋其他主機。規則欄位只填主機名稱，不包含通訊協定、路徑、查詢參數或連接埠。將 https://api.example.com/login 整段填入 DOMAIN，無法表示「只讓登入頁面使用代理」；路徑處理屬於另一種需求，應先確認是否真的需要改寫。
[Rule]
# 單一主機的精確例外
DOMAIN,api.example.com,PROXY
DOMAIN,intranet.example.com,DIRECT
FINAL,DIRECT這種寫法適合先進行小範圍測試。確認單一主機的策略正確後，再決定是否擴展至同一服務的其他網域。一個頁面可能會存取 API、圖片與身分驗證等多個主機，因此「主頁面命中」不代表所有相關請求都會命中。頁面只載入部分內容時，應檢查失敗資源實際使用的主機名稱，不要立刻把整類網域都改成相同策略。
DOMAIN-SUFFIX：依網域層級涵蓋
DOMAIN-SUFFIX,example.com,PROXY 用於比對 example.com 及其子網域，例如 api.example.com。它依據網域後綴關係比對，而非任意字串結尾；notexample.com 並不是 example.com 的子網域。通常不必在欄位前加上星號。了解這點可避免混淆萬用字元寫法與規則本身的比對方式。
後綴規則涵蓋範圍較大，加入前應先確認該網域底下是否有必須直連的內部服務。例如內部管理主機與公開 API 共用同一根網域時，應先加入內部主機的精確 DIRECT 例外，再加入根網域的 PROXY 後綴規則。若順序相反，內部主機會先命中前面的規則，後續的精確例外便無法改變該次結果。
[Rule]
DOMAIN,intranet.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTDOMAIN-KEYWORD：比對範圍取決於名稱片段
DOMAIN-KEYWORD,ads,REJECT 會依網域中的關鍵字比對，不會理解詞義，也無法判斷請求是否真的是廣告。只要主機名稱包含相應片段，就可能被納入範圍。因此，較短的關鍵字更容易誤擋正常服務。範例僅用於說明語法，不代表適合所有網路環境的封鎖建議；實際維護時應優先使用已確認的精確主機或後綴。
| 規則類型 | 欄位範例 | 比對範圍 |
|---|---|---|
DOMAIN | api.example.com | 指定的完整主機名稱 |
DOMAIN-SUFFIX | example.com | 根網域及其子網域 |
DOMAIN-KEYWORD | ads | 主機名稱中包含的片段 |
若要保留包含關鍵字的正常主機，應將精確例外放在關鍵字規則之前。但例外持續增加時，應重新檢視關鍵字是否設定得太廣，而不是無限制地追加補丁。維護規則的目標是讓條件符合需求，而不是讓範圍過廣的規則靠大量例外勉強運作。可讀性與驗證成本也應納入考量。
看不到網域時，不要靠猜測新增規則
並非每次連線都能取得預期的主機名稱。使用 IP 直接連線、請求經過其他中介處理，或連線資訊不足時，都可能無法如預期命中網域條件。此時先確認 App 內可見的目標資訊，再判斷是否需要 IP 規則。不要因為瀏覽器網址列顯示某個名稱，就假設該頁面建立的每一條連線都帶有可用於比對的相同網域。
最後，網域欄位與程式範例都使用英文逗號分隔，多個主機應分別寫成多條規則，不要塞進同一個欄位。遇到國際化網域或名稱格式不同時，應依實際請求中可確認的形式進行測試。DOMAIN、FINAL 等關鍵字的簡短說明可參閱名詞解釋；本章則用於判斷涵蓋範圍與例外關係。
04 / IP 與請求屬性
IP-CIDR、GEOIP 與 USER-AGENT
當需求直接針對目標 IP、網段或請求屬性時，網域規則未必是最適合的工具。IP-CIDR 表示 IPv4 位址集合，IP-CIDR6 表示 IPv6 位址集合，GEOIP 依據 IP 歸屬資料庫進行分類。USER-AGENT 則取決於是否能取得相應的請求標頭。這些規則需要的輸入各不相同，不能只把它們視為網域規則的另一種寫法。
IP-CIDR：以前綴表示 IP 集合
192.168.0.0/16 表示一個 IPv4 網段，斜線後方是網路前綴長度，不是連接埠。前綴越長，涵蓋範圍越小；單一 IPv4 位址可用 /32 表示。撰寫規則前應先確認目標實際使用的 IP，尤其不要混淆伺服器 IP、裝置本身的 IP 與業務目標 IP：一般目標分流規則檢查的是請求目標。
[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
FINAL,PROXY以上範例用於說明私有 IP 範圍的寫法，不保證所有本機服務都因此能連線。裝置所在網路的路由、伺服器監聽位址、防火牆，以及 App 中的略過設定，都可能影響結果。某些流量若在規則處理前已遭排除，就不會再經過這些項目。排查內部服務時，也須確認裝置本身確實能連線至該位址。
no-resolve：不主動為此規則觸發解析
IP 規則末尾的 no-resolve 用來避免為了比對該規則而主動解析網域。這不代表關閉整份設定的 DNS，也不代表忽略已存在的 IP 資訊。對於只有主機名稱、尚無可用 IP 的請求，帶有此選項的 IP 規則可能無法據此命中；請求會繼續交由後續規則處理，因此仍需要合理的網域規則與 FINAL。
在本機網段規則中使用此選項，常見目的是避免為了檢查私有網段而替大量一般網域觸發額外解析。但是否適合目前設定，仍須觀察請求資訊與解析機制。若某個內部網域必須直連，可優先加入明確的 DOMAIN 規則，並確認該名稱在目前網路中能正確解析，而不是只依賴 IP 規則碰巧取得所需資訊。
GEOIP：資料庫歸屬不等於服務身分
GEOIP,CN,DIRECT 表示依據目標 IP 在資料庫中的歸屬選擇策略。它不會依網頁語言、網域後綴或使用者所在位置判斷，也無法證明目標由哪個機構營運。IP 歸屬資料可能有更新延遲或邊界差異，同一服務也可能使用不同地區的 IP，因此 GEOIP 較適合作為廣泛的分類條件，而非身分驗證依據。
[Rule]
DOMAIN,api.example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY這個順序會先讓明確指定的主機使用 PROXY，其餘請求再比對 GEOIP。若將範圍較廣的 IP 分類放在前面，符合條件的請求可能提前結束比對，後面的網域例外便不會生效。若要穩定指定某個服務的連線方式，先用可確認的主機名稱描述需求，再以 GEOIP 補足，通常更容易理解與維護。
USER-AGENT：先確認資訊是否可用
USER-AGENT 會依可見的請求標頭內容進行模式比對，例如 USER-AGENT,ExampleClient*,DIRECT。此處的 ExampleClient 只是範例用戶端識別，不代表實際 App 支援。它不等同於依 App 名稱分流，也不能只因裝置安裝了某個 App，就推斷該 App 的所有流量都會命中相同的請求標頭模式。
HTTPS 會加密請求內容，規則處理過程未必能讀取其中的 User-Agent；有些請求也不包含這個欄位，或欄位內容會隨 App 改變。不要為了驗證一般分流而擴大解密相關設定。若能以已知網域準確描述目標，優先使用網域規則。確實需要 USER-AGENT 時，應先確認 App 內能觀察到相應資訊，並為未命中的請求保留明確的預設處理策略。
05 / 流量去向
PROXY、DIRECT、REJECT 與 Global Routing
規則中的策略用來決定「命中後如何處理」，Global Routing 則用來設定「目前採用哪種整體路由方式」，兩者屬於不同層級。排查 Rule 未生效時，先確認 Global Routing 是否為 Config；若目前使用 Proxy 或 Direct，就不能再用 Config 中的一般規則順序解釋同一個請求。先確認模式，再討論策略。
三種基本策略的用途
PROXY 會將符合接管條件的目標交由代理路徑處理，能否連線仍取決於使用者已有伺服器是否可用及相關設定。DIRECT 表示目標採用直連路徑，不經過選用的代理伺服器，但不保證目標本身一定可連線。REJECT 表示拒絕符合條件的請求，不會在失敗後自動改走其他路徑。三種策略都應配合具體需求使用。
| 策略 | 處理方式 | 常見誤解 |
|---|---|---|
| PROXY | 使用代理路徑 | 命中不代表伺服器一定可用 |
| DIRECT | 使用直連路徑 | 直連也可能受網路條件影響 |
| REJECT | 拒絕符合條件的請求 | 不會自動改走 DIRECT |
設定檔中的基本策略維持大寫寫法，方便與介面中的 Config、Proxy、Direct 區分。若現有設定使用自訂策略名稱，也應檢查名稱是否有對應定義，以及該名稱指向哪部伺服器或選擇邏輯。本手冊的精簡範例只使用三種基本策略，不假設使用者已建立自訂群組，也不要求為基本分流額外建立複雜結構。
Config、Proxy、Direct 對照
Global Routing 中的 Config 會依選取設定中的規則分流；Proxy 會讓受接管的流量採用代理方式；Direct 則採用直連方式。此處的「全域」不表示能繞過所有系統限制或處理裝置上所有可能的流量，實際範圍仍受系統、App 接管範圍與相關設定影響。這是 App 中的路由選擇，不是連線成功的保證。
日常使用時，若須保留內部服務直連，同時讓指定目標使用代理，Config 較適合呈現這種差異。暫時切換至 Proxy 可協助判斷代理路徑是否可用；切換至 Direct 則可作為直連對照，但兩者都只是診斷方式，不代表規則已修正。測試完成後應恢復原本需要的模式，否則後續觀察結果將不符合原設定的設計目標。
FINAL 決定未命中請求的處理方式
FINAL,PROXY 表示先前沒有任何規則命中的請求，最後使用 PROXY；FINAL,DIRECT 則使用 DIRECT。FINAL 沒有網域或網段欄位，不應寫成三欄位的一般條件規則。FINAL 應放在規則末尾，因為請求一旦到達這一行就會套用預設處理，後續條件無法再影響該請求。
[Rule]
DOMAIN,intranet.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,ads,REJECT
FINAL,DIRECT這段範例將未明確列出的目標設為 DIRECT，不代表這種預設處理適合所有使用者。選擇 FINAL 時，應先決定設定的預設處理原則，再為例外補上規則。變更預設處理會影響大量未明確列出的目標，因此驗證範圍應大於修改單一 DOMAIN。不要只測試一個明確命中的網域，就認為新的 FINAL 已驗證完成。
分別判斷連線狀態、策略命中與服務結果
系統顯示連線已建立，只能說明相應的連線狀態，不代表所有目標都可存取。規則命中 PROXY，也只代表選擇了相應的處理方向，後續仍可能發生驗證失敗、連線逾時或目標拒絕。Connectivity Test 可提供連線能力參考，卻不能取代對特定業務請求的規則檢查。應分別記錄這三個層面，不要以一項測試結果代替其他結果。
需要取得 App 時，請先前往App Store 正版核對頁確認開發者與 App ID。Shadowrocket 是 Apple 平台的付費用戶端，唯一取得管道為 App Store；系統需求以 App Store 頁面標示為準。購買 App 與使用者已有的伺服器是兩回事，客戶端一次買斷 ≠ 線路方案。模式說明請參閱Global Routing 三種模式的差異。
06 / 優先順序
比對順序：先命中的規則先決定結果
規則清單會依順序逐一檢查，通常由第一條符合的規則決定策略。不要假設 DOMAIN 一定優先於 DOMAIN-SUFFIX，也不要認為較精確的網段會自動覆蓋前面較寬的條件。條件的精確程度可作為安排順序的參考，但不會形成獨立於檔案順序之外的優先級系統。要預測一次比對結果，應從規則清單頂端逐行檢查。
精確例外在前，範圍規則在後
假設 example.com 及其子網域需要使用 PROXY，但 intranet.example.com 必須使用 DIRECT。正確做法不是只將兩條規則放進清單，而是先加入內部主機的精確條件。因為 intranet.example.com 同樣是 example.com 的子網域，若後綴規則排在前面，它會先命中；後續精確條件即使完全正確，也無法改變結果。
# 例外規則在前
[Rule]
DOMAIN,intranet.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT反向排列的清單看起來只交換了兩行，實際行為卻不同。這也是排錯時不能只搜尋「有沒有那條規則」的原因：規則存在，不代表請求會執行到它。找到目標項目後，還要往上檢查所有可能涵蓋它的條件，包括關鍵字、網域後綴、IP 分類，以及提前出現的 FINAL。上方任何一條規則命中，都可能讓目標項目沒有執行機會。
不同類型的規則也共用相同比對順序
網域規則與 IP 規則並非兩份互不相關的清單。在同一個 Rule 段中，仍須依實際排列逐項判讀，只是不同條件需要的資訊各不相同。前面的網域條件若已命中，就不必期待後面的 GEOIP 改變結果；前面的 IP 條件若符合，也可能讓後方的網域例外沒有機會生效。涉及解析時，還須一併考量第二章說明的 IP 資訊界線。
「由精確到寬泛」可作為整理習慣：先列出明確主機例外，再列出明確網域集合、必要的 IP 範圍、較廣泛的分類條件，最後放 FINAL。但不必死守固定範本。例如，若要拒絕某個已確認主機的連線，精確的 REJECT 可能須放在允許該網域後綴的規則之前。順序始終取決於需求優先級，而不是策略顏色。
如何處理重複或互相矛盾的規則
相同條件出現兩次且策略相同時，後續項目通常只會增加閱讀負擔；相同條件出現兩次但策略不同時，結果仍由先命中的規則決定。維護時應先標記重複項目的來源，再決定保留哪一條，不要只刪除看起來較舊的行。有些項目可能來自更新內容；若不處理來源，下次更新時還會再次出現。
規則範圍重疊不一定是錯誤。精確例外與後綴規則重疊可能是刻意安排，但必須能說明優先關係。無法說明用途的重疊，通常表示設定檔是多次拼接而成。整理時先依需求分組，再在各組旁註明例外原因；不要只按網域字母順序排列，否則原本依賴上下順序的行為可能在不知不覺中改變。
使用測試矩陣檢查各種情況
以上述範例為例，至少準備三類目標：符合精確例外的主機、同一網域下的一般主機，以及無關網域的主機。它們分別用來驗證 DIRECT 例外、PROXY 範圍與 FINAL。再加入一個相似但不屬於該後綴的名稱，檢查是否誤解比對邊界。範例名稱不必對應實際服務；實際連線測試應改用使用者已確認存在的目標。
測試時記錄目標、預期命中的條件、預期策略、觀察結果與失敗階段。若預期規則未命中，先檢查上方的涵蓋條件；若規則已命中但請求失敗，再檢查出口與目標服務。修改順序後應重新建立測試連線，避免舊連線干擾。這樣的記錄比持續追加相似規則更容易重現問題，也更方便在更新設定後重新驗證。
07 / 對應與改寫
Host 與 URL Rewrite：不可取代分流規則
Host 會變更指定名稱所對應的 IP，URL Rewrite 會處理符合運算式的請求網址，而 Rule 則決定採用哪種策略。三者可以出現在同一份檔案中，但不能互相取代。若某個主機需要使用 DIRECT，通常應先明確寫出分流條件；不要為了直連而任意將主機對應至固定 IP，更不應透過改寫將目標換成無關服務。
Host 對應設定固定的是解析關係
例如 test.example.com = 192.0.2.10 展示主機名稱對應至 IP 的靜態設定。此處的 IP 僅供文件範例使用，並非可連線的實際服務。Host 項目不包含 PROXY、DIRECT 或 REJECT 欄位；後續連線採用何種策略，仍須依據 Rule 與實際請求資訊判斷。若將成功對應 IP 與成功分流視為同一件事，就會掩蓋問題所在。
[Host]
test.example.com = 192.0.2.10
[Rule]
DOMAIN,test.example.com,DIRECT
FINAL,PROXY靜態對應適用於使用者明確管理的測試環境等有限情況。公開服務可能使用動態 IP、負載調度或故障切換，長期固定 IP 可能導致連線失敗，也可能略過原本會隨網路變化的調度機制。只有在確認 IP 歸屬、用途與維護責任後，才應加入對應，並記錄移除條件。不要將某次成功解析取得的 IP 永久寫入設定。
對應設定無法取代憑證與服務身分檢查
將主機對應至另一個 IP，不代表該 IP 上的服務會自動取得原主機的身分。HTTPS 仍會檢查憑證與請求主機名稱；若目標服務未為該主機設定，可能出現憑證不符或服務拒絕。遇到這類錯誤時，不應忽略身分驗證來「證明對應有效」，而應重新確認 IP、主機名稱與服務設定是否一致。
若連線行為與對應設定的預期不同，也應檢查 App 是否確實使用這份解析資訊、既有連線是否仍保留舊 IP，以及請求是否透過其他機制取得 IP。先移除單一對應設定進行比較，再恢復設定並重新建立連線。確認差異確實來自 Host 後，再討論它與 IP 規則的互動；避免同時修改對應與分流，導致原因難以判斷。
URL Rewrite 的三個組成部分
常見的重新導向寫法由比對運算式、替換目標與狀態碼組成，各欄位依相應語法分隔。以下範例會將特定主機的 HTTP 前綴替換為 HTTPS 前綴，並使用 302。運算式中的句點以反斜線跳脫，避免被解讀為任意字元；開頭的 ^ 則限定從請求網址起始位置比對，以減少不必要的誤命中。
[URL Rewrite]
^http://example\.com/ https://example.com/ 302這段範例僅用於說明語法，無法取代網站本身正確的 HTTPS 設定。比對範圍包含斜線位置，因此沒有路徑斜線、使用不同連接埠或不同主機的輸入，不一定會有相同結果。測試時應分別檢查首頁、含路徑的請求，以及含查詢參數的請求，確認替換後的目標仍符合預期。運算式範圍越廣，越需要反向測試不應命中的輸入。
避免循環與超出可見範圍的改寫
若某項改寫的結果再次符合另一條改寫規則，可能造成重複重新導向，甚至在兩個網址之間循環。新增規則前，應列出原始網址、第一次替換結果，以及後續可能符合的條件。瀏覽器可能會快取重新導向結果，排錯時應將此因素納入考量，不要把快取中的跳轉誤認為目前設定仍在生效。移除規則後也要重新驗證新請求。
加密請求的路徑不一定能被規則處理過程讀取；URL Rewrite 也不保證可以修改任意 HTTPS 內容。本頁不要求為一般分流設定額外的解密能力。若只要變更流量出口，請回到 Rule；若只要查明名稱對應的 IP，請檢查 Host；只有在確實需要管理請求網址轉換時，才使用 URL Rewrite。釐清這三者的界線，才能在故障時快速找出負責的部分。
08 / 維護流程
設定驗證：從精簡範例到可還原維護
驗證設定的目標不是只成功連線一次，而是確認預期規則在預期條件下產生可解釋的結果。完整流程包括儲存原始設定、確認執行模式、單獨修改一項內容、建立新請求、核對命中與連線結果、記錄過程並保留還原方案。將各階段分開處理，可減少誤判，也方便在後續訂閱或設定更新後快速複查。
步驟一：確認目前實際執行的設定
先在 Home 檢查連線狀態、目前選取的伺服器與 Global Routing，再前往 Config 確認正在使用的檔案。若檔名相同或相似，應直接檢查內容，不要只依名稱判斷。使用者已有伺服器的參數應與自己的來源一致；尤其不要在驗證規則時順便修改協定、連接埠與驗證欄位，否則連線結果改變後將無法判斷原因。
若尚未建立過可用連線，請先完成入門指南，不要立即匯入含大量規則與改寫的設定。App 取得與已購項目還原問題，請查閱購買還原說明，而不是修改 Rule。App Store 正版核對資訊：開發者為 Shadow Launch Technology Limited，App ID 為 932747118；系統需求以 App Store 頁面標示為準。
步驟二：縮小至能夠解釋的設定片段
發生異常時，保留原始檔案，並在副本中只留下與測試目標相關的條件及明確的 FINAL。先驗證精確 DOMAIN，再逐步還原後綴、IP 分類、Host 與改寫。不要直接刪除唯一可用的設定，也不要用測試副本覆寫遠端來源。精簡設定是為了排除干擾，不代表日常使用時永遠只需兩三條規則。
[Rule]
# 將 example.com 換成使用者自行確認存在的測試主機
DOMAIN,example.com,PROXY
FINAL,DIRECT使用這個結構測試時，應選擇一個明確命中 DOMAIN 的目標，再選擇一個未命中的目標來檢查 FINAL。若兩者結果都不符合預期，先確認目前是否使用 Config，以及副本是否已選取。若只有 PROXY 目標失敗，應單獨檢查代理路徑；若 DIRECT 目標失敗，則檢查目前網路能否直連該目標。不要只憑一次失敗就否定整份設定的語法。
步驟三：區分四種常見故障
| 現象 | 優先檢查 | 下一步 |
|---|---|---|
| 規則未命中 | 是否選取設定、目前模式、上方涵蓋條件 | 確認目標資訊並精簡規則 |
| 已命中但連線逾時 | 選用的出口、伺服器與目標連線狀態 | 分別測試各連線路徑 |
| 只有部分資源載入失敗 | 失敗資源的實際主機與策略 | 逐一檢查相關請求 |
| 修改後仍看到舊結果 | 舊連線、快取與設定選取狀態 | 建立新請求後再次觀察 |
App 內可用的連線記錄或日誌可協助確認目標、策略與失敗階段，實際呈現方式以目前 App 介面為準。記錄中若只有 IP，不要自行補上網域名稱；若只有網域，也不要斷言它必定屬於某個網段。Connectivity Test 可用來輔助判斷連線能力，但特定網頁或 API 仍須另外送出請求驗證。
步驟四：處理更新覆蓋與規則回歸
訂閱更新與設定更新應分開檢查。更新現有伺服器項目不一定會改變目前的 Rule；更新遠端設定則可能重新排序或取代本機修改。每次更新後，至少重新測試精確例外、常用範圍與 FINAL 三類目標。若有 Host 或 URL Rewrite，也要測試對應目標與重新導向範圍，避免只確認主頁能開啟就結束維護。
維護記錄可包含修改原因、原規則、新規則、預期結果與實際結果，但不應包含完整訂閱網址、驗證資訊或其他敏感內容。需要向他人說明問題時，先替換真實主機與憑證，同時保留規則順序、欄位結構及必要錯誤資訊。只刪除密碼、卻保留含驗證參數的訂閱網址，仍可能洩漏使用者自己的存取權限。
規則已儲存，為什麼仍看不到變化？
先確認選取的設定與 Global Routing，再檢查舊連線和快取。重新建立測試請求後，確認上方是否已有先命中的規則，不要只檢查新增項目是否存在。
命中 PROXY 是否就代表整份設定都正確？
這只能證明該次請求選用了相應策略。伺服器連線、驗證、解析與目標服務仍可能失敗；也需要檢查其他規則分支，以及未命中請求的 FINAL。
最後，保留一份已驗證且可還原的設定，並清理已確認多餘的測試項目。規則數量增加不代表結果更穩定；能說明每項條件的用途、順序與驗證方式，才有利於長期維護。想重新檢查首次連線流程，可閱讀選取預設伺服器並使用 Connectivity Test 驗證；想快速確認術語，則前往名詞解釋依關鍵字查閱。