Shadowrocket
規則與設定參考

Shadowrocket 的設定檔並不是伺服器清單的另一種說法。伺服器資訊回答「使用哪個連線端點」，設定檔則回答「遇到某種請求時如何處理」。透過 Subscribe 更新現有訂閱，通常是在維護連線資訊；在 Config 切換設定，則可能改變規則、DNS 與位址映射等行為。兩者可以互相搭配，但不能把更新訂閱視為所有設定項目都已同步。排查時應分別記錄目前選用的伺服器與生效中的設定，避免只檢查其中一項。

區段名稱界定用途，規則行描述條件

常見的 .conf 文字檔會以方括號標示區段名稱。[General] 放整體選項，[Rule] 放依序判斷的分流規則，[Host] 放主機名稱與位址的靜態映射，[URL Rewrite] 放針對可見請求 URL 的改寫運算式。各區段在檔案中的排列位置，不代表所有功能會依此順序串接執行；只有 Rule 區段中的規則清單，應直接依由上而下的順序理解。不要為了「提高優先順序」而把 Host 區段移到檔案最前面。

[General]
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

這段文字展示三種不同用途：General 選擇系統 DNS，Rule 為範例網域與區域網路位址設定分流，Host 則將範例主機名稱映射至文件保留位址。這些位址只用來說明格式，不應作為實際服務設定。URL Rewrite 並非建立基本連線的必要項目，因此未納入這份起始範例。若只想調整分流，應先保留其他區段不變，以免同時改動多個變數而難以判斷原因。

編輯前先確認生效中的設定

進入 Config 後，先確認目前選用的設定，不要只因檔名看起來相似，就打開檔案直接修改。遠端來源設定、本機複製的設定與暫存測試檔可能使用相近名稱，內容卻不相同。建議在現有設定的副本中測試，使用容易辨認的本機名稱，並記錄來源與修改目的。遠端設定再次更新時，是否會覆蓋本機修改取決於儲存方式；需要長期保留的規則應放在明確且便於維護的位置，不能假設所有手動修改都會與遠端來源合併。

儲存文字後，還要返回 Config 確認已選取該檔案；接著檢查 Global Routing 是否設為 Config。成功編輯只代表文字已儲存，不表示每個新請求都已依照這份設定處理。既有連線可能仍保留先前的處理結果，驗證時應建立新的請求。若客戶端回報解析錯誤，請先修正錯誤再測試連線；不要把無法載入的檔案與上一次正常設定的結果混為一談。

文字格式與最小幅度修改

規則通常以半形逗號分隔欄位，選項則通常以半形等號連接鍵和值。中文輸入法產生的全形逗號、不可見空格，以及從富文字複製的引號，都可能讓看似相同的文字無法解析。建議使用純文字編輯；每行只放一條規則，避免將說明文字直接加成未知欄位。本文程式碼區塊以外的中文說明都不是設定內容，複製時不要連同章節編號或行號一起貼上。

每次只修改一種行為，例如只新增一條 DOMAIN 規則，再測試對應網域。若同時更換 DNS、加入重寫、移動 FINAL 並更換伺服器，即使結果改變，也無法判斷是哪項修改造成的。可靠的維護紀錄應記下修改前的狀況、具體修改的行與驗證結果，而不只是寫「最佳化設定」。下次需要復原時，這些資訊比更長的規則清單更有用。

網域規則比對的是處理請求時可取得的主機名稱，不是瀏覽器網址列中的完整 URL。把通訊協定、連接埠或路徑一併寫進 DOMAIN，通常不會得到預期結果。例如，若目標是 example.com 下的某個頁面，網域欄位仍只填主機名稱；若確實要依路徑處理請求，應另行評估 URL Rewrite 的適用條件，不能要求網域規則負責比對路徑。

DOMAIN：只比對完整主機名稱

DOMAIN,example.com,DIRECT 表示對 example.com 這個主機名稱使用 DIRECT。它不會自動涵蓋 api.example.com，也不代表「整個網站的所有資源都直連」。一個頁面可能同時要求主網域、靜態資源網域與介面網域；主頁能開啟，不代表所有請求都符合同一條規則。若要精確處理特定介面，DOMAIN 的範圍容易核對，日後也方便撤除例外。

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

這段規則先為 api.example.com 指定 DIRECT，再讓 example.com 及其子網域走 PROXY。例外必須放在範圍較大的後綴規則之前，否則請求會先符合後綴規則，精確規則就沒有機會生效。真正決定結果的是排列順序，而不是 DOMAIN 這個關鍵字天生比 DOMAIN-SUFFIX「更優先」。

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

若想統一處理一組網域，適合使用 DOMAIN-SUFFIX。寫成 DOMAIN-SUFFIX,example.com,PROXY 時，目標包括 example.com 及其子網域；不應加上路徑，也不需要在開頭加星號。後綴比對應依網域邊界判斷，不能只因字串結尾相似就認定符合。維護時應選擇確實需要涵蓋的網域範圍，避免為了少寫幾行而擴及無關主機。

DOMAIN-KEYWORD：涵蓋範圍較廣，維護成本也較高

DOMAIN-KEYWORD 用來檢查網域是否包含指定文字，不會搜尋頁面標題、搜尋詞或網頁內文。DOMAIN-KEYWORD,example,PROXY 可用來表達關鍵字比對範圍，但不能保證符合的主機都屬於同一項服務。關鍵字越短，就越容易涵蓋原本不打算處理的請求。因此，若已有明確的網域清單，優先使用 DOMAIN 或 DOMAIN-SUFFIX；只有確實能接受較廣的比對範圍時，才使用關鍵字規則。

關鍵字規則特別容易讓後面的例外形同虛設。測試時不要只挑一個預期會符合的主機，也應選擇一個不應符合的主機作為對照，確認規則沒有擴大適用範圍。若關鍵字來自遠端設定，應檢視附近的規則與註解，確認是否有相應的例外。只複製一行卻不了解原有上下文，可能讓原本受限的比對變成範圍很廣的全域處理。

網域存在，不代表客戶端一定取得了網域名稱

部分應用程式會直接連線至 IP，或在應用程式內自行選擇位址；此時分流過程未必能取得可供判斷的主機名稱。若請求紀錄只顯示位址，不要立刻認定 DOMAIN-SUFFIX 寫錯。先確認請求是以網域發出，還是只帶有目標 IP，再決定是否需要補上位址規則。若反向推測 IP 屬於哪個網域並據此下結論，在共用位址或動態解析的情況下很容易出錯。

同樣地，網頁重新導向可能讓後續請求改為存取另一個主機；即使初始網域符合預期，後續資源仍可能採用不同策略。驗證時應以請求紀錄中的實際主機名稱為準，而不是依賴使用者記得的網站名稱。若想進一步了解廣泛規則與例外的關係，可繼續閱讀自訂規則、比對順序與 FINAL，再回到本章逐步縮小比對範圍。

位址規則判斷的是目標位址，不是網頁語言、使用者所在地或服務商名稱。請求若未符合前面的網域規則，位址條件便可繼續參與判斷；若更前面的規則已符合，後續的 IP-CIDR 或 GEOIP 就不會再為同一個請求重新選擇策略。了解這點後，才能分辨「位址分類結果不如預期」與「請求根本沒有進入位址規則」這兩種不同問題。

IP-CIDR：以網路前綴表示 IPv4 範圍

CIDR 由位址和斜線後的前綴長度組成。前綴越長，範圍越小；192.168.0.0/16 表示一段私有位址範圍，192.168.1.10/32 則只表示一個 IPv4 位址。不要在位址欄位填入連接埠，也不要用連字號表示起訖位址。若要為本機裝置設定 DIRECT，應先確認裝置實際位址及所在子網路；不要因為範例使用某段私有位址，就假設自己的網路也屬於該範圍。

[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

這組規則用來說明私有位址比對，不是完整的區域網路通行清單。區域網路連線也會受到系統網路權限、裝置防火牆、監聽位址與路由影響。符合 DIRECT 只代表不經所選代理轉送，不能保證印表機、檔案共享或本機服務一定可連線。驗證時也應確認目標服務正在執行，並檢查同一網路上的其他裝置是否能存取。

no-resolve：避免僅為這項判斷主動解析

位址規則末尾的 no-resolve 用來避免僅為了嘗試符合該規則而觸發網域解析。它不是「停用整個客戶端的 DNS」，也不是「忽略所有現有位址資訊」。若請求原本就使用 IP，或處理過程中已取得可用位址，仍可能參與相應的位址判斷。因此，不能靠加入 no-resolve 修復所有 DNS 問題，也不能把它當成強制讓網域規則優先的開關。

為本機位址規則加上這個參數，通常是為了避免每個尚未解析的網域都只因本機網段判斷而觸發額外解析。實際效果仍取決於請求進入規則階段時可用的資訊。若目標是網域，卻始終未符合本機位址規則，請檢查解析結果與請求紀錄；不要直接刪除參數，再把偶然出現的變化當作定論。

GEOIP：依位址資料庫分類，不代表服務歸屬

GEOIP,CN,DIRECT 會依位址資料庫中的地區分類選擇 DIRECT。此處的 CN 是規則參數，不代表「中文網頁」，也不代表「所有面向某地區的服務」。同一主機可能使用多個位址，內容傳遞網路也可能因連線網路不同而改變解析結果。不同位址的分類可能不一致；資料庫記錄與實際網路部署之間也可能存在時間差，因此 GEOIP 適合作為範圍性條件，而非精確判定服務身分。

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

在這段規則中，example.com 會先由網域規則決定處理方式；即使解析後的位址符合 CN 分類，也不會再被後續 GEOIP 改成 DIRECT。只有未符合網域規則的其他請求，才可能進入 GEOIP 判斷。若某項服務必須固定使用特定策略，優先為已知主機建立清楚的網域規則，再讓 GEOIP 處理其餘請求，之後更容易說明結果。

IPv6 應獨立檢查，不能直接套用 IPv4 的結論

IPv4 與 IPv6 是不同的位址族。只設定 IP-CIDR 不代表已涵蓋 IPv6；需要比對 IPv6 前綴時，請使用 IP-CIDR6。若網域同時回傳兩種位址，應用程式最後採用哪一種，也會受到系統與網路狀況影響。單次連線成功只代表這次路徑可用，不能證明另一個位址族也能正常使用。排查時應記錄實際目標位址，再分別檢查規則與網路連線。

規則條件決定「是否符合」，策略則決定「符合後如何處理」。PROXY、DIRECT 與 REJECT 是三種不同的處理結果，不是服務品質等級，也不是通訊協定名稱。Shadowsocks、VMess、VLESS、Trojan、Hysteria2 與 WireGuard 描述連線方式；使用其中一種通訊協定，不會讓規則中的 PROXY 自動取得更高優先順序。維護設定時，應分開檢查條件、策略與連線端點，避免以更換通訊協定掩蓋規則錯誤。

PROXY、DIRECT 與 REJECT

PROXY 會將請求交由目前代理選項所對應的處理路徑；能否完成連線，仍取決於您現有的伺服器資訊、認證參數與伺服器是否可用。DIRECT 表示直接連線至目標，不代表請求不受任何系統網路限制，也不表示 DNS 行為必然與停用客戶端時完全相同。REJECT 用來拒絕符合條件的請求，適合用於明確需要封鎖的目標；若拒絕了業務必需的主機，應用程式可能會載入失敗、反覆重試或缺少部分內容。

Global Routing 中的 Config、Proxy、Direct 是全域模式；規則行中的 PROXY、DIRECT、REJECT 則是設定內的策略，大小寫與含義應分開理解。若要確認某條 Rule 是否生效，請先選擇 Config；切換至 Proxy 後請求恢復，只能表示問題可能與設定分流或直連路徑有關，不能直接證明某一行語法錯誤。完成對照測試後，應恢復原本模式，避免後續測試的前提不同。

USER-AGENT 取決於是否能取得請求標頭

USER-AGENT 規則比對的是可取得的 User-Agent 內容，不是應用程式圖示、名稱或系統處理程序名稱。應用程式可能使用不同的請求標頭，也可能在更新後變更內容；多個程式也可能共用相同標頭。因此，把某段字串當成應用程式身分的永久識別碼並不可靠。只有在已觀察到實際請求標頭，並確認客戶端能在相應請求情境下讀取它時，才適合使用這類規則。

[Rule]
USER-AGENT,ExampleClient*,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

此處的 ExampleClient 是教學用字串，不代表真實應用程式。星號表示萬用比對範圍；若看不到請求標頭，這條規則就無法依預期參與判斷。加密連線中的 HTTP 標頭通常無法只透過一般轉送讀取；不能因為瀏覽器開發人員工具看得到 User-Agent，就認定客戶端的規則階段也一定看得到。不要為了驗證 USER-AGENT 規則，就擴大憑證信任範圍或啟用不必要的流量解密。

策略正確，連線仍可能失敗

請求紀錄顯示 PROXY，只能確認路由選擇，不代表遠端已完成認證、解析或連上目標。接下來應檢查伺服器位址、連接埠、認證方式與傳輸參數是否符合您現有的服務資訊。紀錄顯示 DIRECT，也只代表選擇了直連路徑；若本機網路無法連到目標，改變規則名稱並不能修復網路。若紀錄顯示 REJECT，應先找出是哪條規則拒絕請求，而不是先測試伺服器。

尤其當頁面只載入部分內容時，應分別檢視失敗與成功的資源。一個應用程式可能同時有多個請求，分別由 DIRECT、PROXY 與 REJECT 處理；「應用程式能開啟」不代表驗證完整，「應用程式無法開啟」也不足以證明只有一條規則有問題。將實際主機、符合的規則與策略逐項對照，才能判斷該調整的是條件範圍、排列順序還是連線參數。

日常維護時，優先使用網域或位址條件表達穩定的網路範圍，將 USER-AGENT 留給能明確驗證的有限情境。規則越依賴請求內部細節，跨應用程式與平台使用時就越需要重新測試。若現有設定中出現不熟悉的自訂策略名稱，應先找出它的定義與引用方式；不要直接將名稱改成 PROXY 就宣稱設定等效，也不要假設任何名稱都是客戶端內建策略。

Rule 的核心原則是由上而下檢查，最先符合的規則決定處理策略。客戶端不會先收集所有符合結果，再選擇看起來最精確的一條。精確網域、網域後綴、關鍵字與位址範圍之間，也沒有能取代行順序的固定優先級。排查「明明寫了規則卻沒生效」時，第一步不是重複新增相同條件，而是往上尋找是否已有規則涵蓋該請求。

明確例外應放在廣泛條件之前

假設 example.com 及其子網域應走 PROXY，但 api.example.com 必須 DIRECT，正確做法是先寫單獨的例外，再寫後綴範圍。若順序相反，api.example.com 已在後綴規則處符合，後面的 DOMAIN 就不會再次改變結果。這項原則同樣適用於 REJECT：廣泛拒絕規則之前必須放置確實需要的例外，並確認例外沒有涵蓋超出原先預期的主機。

[Rule]
DOMAIN,api.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

逐行推演時，api.example.com 在第一行就結束判斷；blocked.example.com 在第二行被拒絕；其他 example.com 子網域則在第三行走 PROXY。目標若是私有位址，且先前沒有網域規則符合，可能由第四行選擇 DIRECT；其他請求則繼續比對 GEOIP，仍未符合才會採用 FINAL。推演時應使用實際請求條件，而不是只盯著希望它符合的那一行。

FINAL 是兜底規則，不是修補工具

FINAL,PROXY 沒有額外的比對條件，用來處理前面規則都未符合的請求，因此應放在 Rule 最後。若將 FINAL 提前，就等於中途接手所有剩餘請求，後面的普通規則便沒有機會處理。FINAL 的策略應由使用者自行選擇：PROXY 與 DIRECT 代表不同的預設路徑，不能只看別人設定的最後一行，就推斷哪種更適合自己的網路。

建議易於維護的 Rule 只保留一條明確的 FINAL。合併兩份規則時，常見錯誤是將第一份設定連同 FINAL 一起貼到第二份前面，導致第二份大部分規則永遠無法符合。合併後應先找出所有 FINAL，整理為唯一的末尾兜底，再檢查重複規則與互相衝突的範圍。不要只看檔案長度或規則數量判斷是否合併成功。

重複規則、衝突規則與看似合理的排序

完全相同的條件重複出現時，前面的規則通常已決定結果；後面即使使用不同策略，也不會成為「備用策略」。例如連續寫兩條相同 DOMAIN，第一條用 DIRECT、第二條用 PROXY，不代表直連失敗後會自動改走代理。分流比對不是連線失敗後的重試流程。若要更改策略，應修改實際最先符合的規則，而不是在後面追加一條期望生效的規則。

依字母順序整理規則也可能改變其語意。看起來整齊的排序，可能讓原本位於廣泛條件之前的例外移到後面；依規則類型分組也有相同風險。便於維護的順序通常是先寫明確例外，再寫服務網域範圍，接著處理位址範圍與地區分類，最後放兜底規則。但這只是方便檢視的整理方式，不代表所有設定都必須照抄這個固定範本。

用比對表取代主觀推測

修改前可以列出三到五個測試目標，包括必須直連的主機、必須代理的主機、需要拒絕的主機，以及一個應由 FINAL 處理的目標。分別記下預期符合的規則行，再用新連線驗證實際結果。若兩者不一致，先確認實際主機與位址是否符合預期，再逐行檢查條件。這樣既能找出順序錯誤，也能發現網頁重新導向、資源網域變更或位址族不同等問題。

若設定含有外部規則引用，也要檢查引用位置與目前內容。引用名稱相同不代表內容永遠不變；更新後的範圍可能涵蓋原本依賴 FINAL 處理的請求。不能只檢視本機檔案中直接看得到的幾行。更完整的順序範例請見規則優先順序與 FINAL 專題；閱讀後仍應回到目前生效的設定，確認實際排列順序。

General 負責設定整體選項，不是將規則換個格式集中書寫。DNS、網路行為與平台相關參數可能在此設定，但不同客戶端介面與平台實作各有差異，不應直接搬入其他設定中的所有欄位。即使無法識別的鍵值沒有立即引發明顯錯誤，也不能證明它已生效。請先使用目前客戶端能確認支援的設定，再逐項加入確有需求的選項。

DNS 首先解決「位址是什麼」

網域解析會將主機名稱轉換成位址；規則決定請求採用的策略；連線階段再嘗試抵達目標。這三個環節彼此相關，但並不相同。DNS 取得結果不代表目標可連線，符合 PROXY 也不代表 DNS 一定透過同一條路徑完成。遇到問題時，先確認「有沒有取得位址」，再確認「選了什麼策略」，最後確認「連線在哪個環節失敗」，比直接更換整份設定更容易找出原因。

[General]
dns-server = system

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

dns-server = system 是使用系統 DNS 的起始範例，不表示它適合所有網路環境。它的用途是先建立容易理解的基準：保留系統提供的解析方式，只檢查規則是否依預期處理。若現有設定使用其他受支援的 DNS 選項，應記錄具體參數與原本結果，再決定是否暫時切回基準。不了解原設定用途時，不要直接清空 General。

解析結果會改變位址規則的比對依據

同一個網域可能回傳多個位址，也可能因網路位置與快取狀態而回傳不同結果。網域規則以主機名稱為條件時，位址變化通常不會改變網域條件本身；GEOIP 與 IP-CIDR 則直接依賴位址資訊，因此結果變動可能影響規則是否符合。若測試前後的位址已經改變，就不能把策略變化全歸因於剛才移動的規則，也必須記錄當次目標位址。

此外，瀏覽器、應用程式、系統與客戶端可能各自保留快取或連線狀態。修改 DNS 後立即重新整理頁面，不一定會重新解析或建立新連線。可以先結束目標應用程式的目前活動，再發起新請求，並在客戶端紀錄中確認出現新的時間與目標連線。不要以反覆清除所有資料取代觀察；若無法確認快取所在位置，應先保留現況，再從最小範圍開始排查。

不要混淆本機解析與伺服器端解析

某些連線方式可以將主機名稱交由遠端處理，另一些路徑則可能先在本機取得位址；實際行為取決於通訊協定、設定與請求形式。不能只看到 PROXY，就斷定所有解析都在伺服器端完成；也不能只看到本機 DNS 紀錄，就認定服務流量沒有經過代理。應分別核對 DNS 請求與後續目標連線，尤其不要把兩種用途不同的請求當成同一筆流量。

您現有伺服器資訊中的伺服器位址，也可能是網域。若該位址無法解析，客戶端可能連代理端點都無法建立；此時業務網域規則再精確也無法修復。排查連線時應先從伺服器位址解析開始，再檢查連接埠與認證，最後檢查目標網站。將伺服器主機名稱與業務主機名稱記錄在不同項目中，能避免為同一問題反覆修改錯誤的網域規則。

繞過選項與 DIRECT 並非同一層級

General 中某些網路排除或繞過設定，可能讓特定流量不進入一般的 Rule 判斷路徑；DIRECT 則是流量進入分流判斷後的一種策略結果。若請求根本沒有出現在預期紀錄中，應檢查系統網路接管狀態與相關繞過設定，而不是只在 Rule 中新增 DIRECT。具體欄位請以目前客戶端支援的設定說明為準；本文不會將平台相關選項列為通用必填項目。

維護 General 時，建議為每個項目記下用途，例如「使用系統解析作為基準」或「保留現有本機網路行為」。無法說明用途的參數，先保留原值並在副本中單獨測試，不要照著更長的設定逐項補齊。欄位多不代表涵蓋更完整；能說明、能驗證、能復原，才是設定持續可用的基礎。若尚未建立基本連線，請先回到入門指南完成伺服器與連線檢查，再調整解析行為。

Host 與 URL Rewrite 經常同時出現在設定檔中，但作用對象不同。Host 會改變指定主機名稱取得的位址映射；URL Rewrite 則會對符合運算式的可見請求 URL 執行改寫。兩者都不代表「換個網域就能存取相同服務」。目標伺服器是否接受該主機名稱、憑證是否相符，以及應用程式是否跟隨重新導向，仍取決於實際連線與服務行為。

Host：固定映射必須有明確用途

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

這份範例將兩個主機名稱分別映射到文件保留位址，用來展示鍵值格式，不能直接用於實際存取。固定 Host 通常用於使用者自行管理的測試環境；未確認目標位址用途前，不要為了「加速」而任意填入網路上看到的位址。網域可能由多個後端提供服務，固定指向單一位址可能繞過原有的流量調度，也可能在位址調整後持續指向失效目標。

Host 映射通常不會將請求中的主機名稱改成位址字串。請求仍可能帶有原本的主機身分，TLS 驗證也仍須符合相應網域。將網域映射到任意選擇的伺服器，不會讓該伺服器自動提供原本的服務。若憑證不相符，應先核對位址與服務部署，不要以忽略憑證驗證來掩蓋映射錯誤。

Host 不會取代 Rule 的選路判斷

網域有靜態映射，不代表它就會自動使用 DIRECT。請求的策略仍須依據目前模式、可用主機名稱與位址規則判斷。若希望某個自有測試主機使用固定位址並直連，應分別表達這兩項設定目的：Host 提供位址，Rule 指定 DIRECT。將映射與策略分開設定，也方便在測試結束後分別移除，避免留下不易察覺的靜態位址。

URL Rewrite：先了解正規表示式，再選擇動作

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

這個範例會精確比對可見的明文 HTTP URL，並以 302 動作將舊路徑重新導向至新路徑。正規表示式中的句點需要跳脫，否則代表任意字元；開頭的脫字符號與結尾的美元符號則用來限制完整比對範圍。運算式只涵蓋範例中的舊路徑，不會自動涵蓋帶有查詢參數或其他尾端內容的網址。比對條件越寬，越容易連原本不該改寫的請求也一併處理。

302 表示重新導向，不是直接修改目標伺服器上的檔案，也不是永久遷移資料。客戶端收到重新導向後會發出後續請求；新請求可能重新參與分流，並受到快取、應用程式是否跟隨跳轉及目標服務狀態影響。若應用程式忽略跳轉或只接受特定回應，瀏覽器測試成功不一定代表應用程式內部呼叫也成功。

不可忽略 HTTPS 的限制

HTTPS 的路徑與 HTTP 標頭通常包含在加密內容中，一般代理轉送無法直接查看完整 URL。因此，不能只把上述 HTTP 範例改成 HTTPS，就認定一定會生效。處理加密流量需要額外設定並涉及信任範圍；本頁不將其列為基本分流的前提，也不建議為了解決一般規則問題而先擴大憑證信任範圍。若只需要依網域分流，應優先使用網域規則。

改寫也可能形成循環，例如新網址又被另一條運算式改回舊網址，或範圍過寬的運算式再次符合自己的替換結果。測試時應觀察網址變化與連續回應，確認一次跳轉後能夠結束。避免同時啟用多份針對相同目標的改寫來源；若無法說明每條規則的用途，先在副本中只保留一條，確認效果後再逐條恢復。

取消設定時，同時檢查三處狀態

移除 Host 後，既有解析快取與連線可能暫時保留舊位址；移除 URL Rewrite 後，應用程式也可能保留跳轉結果。要完整取消設定，還須還原設定、建立新請求，並確認實際位址與路徑。若問題仍在，不要立刻再新增更多規則，應先判斷目前看到的是舊連線還是新行為。正式服務建議先在使用者自行管理的測試主機上驗證，再決定是否套用到日常設定。

整合前面各章時，目標不是讓檔案中的規則越多越好，而是建立能說明每個重要請求處理方式的設定。先釐清需要哪些例外，再決定預設處理策略；只有確有需求時才調整 DNS 與 Host，URL Rewrite 則應獨立驗證。開始前，應確認您現有訂閱中至少有一台伺服器可以正常使用，避免伺服器故障與分流問題互相干擾。

方便逐行核對的組合範例

[General]
dns-server = system

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

這段範例展示精確例外、拒絕目標、後綴範圍、本機位址、地區分類與最終兜底的排列方式，不含代理端點，也不能取代訂閱作為連線資訊。實際套用前，應將每項條件與自己的目標逐一對照；不符合需求的範例規則不必保留。尤其是 REJECT，只有確認目標確實需要拒絕後，才應加入正式設定。

先確認檔案，再確認模式

1. 在 Config 確認目前選用的檔案，核對剛修改的規則確實存在於該檔案中，並檢查是否有解析錯誤。
2. 將 Global Routing 設為 Config，記錄目前選用的伺服器；測試規則時不要同時切換伺服器。
3. 結束目標應用程式的舊連線後發出新請求，記錄實際主機、目標位址、符合條件與處理策略。
4. 將實際符合的規則與預期行號比較；若不一致，先往上找出涵蓋該請求的條件；若一致，再檢查連線、解析與目標服務。

若所有目標都使用相同策略，優先檢查全域模式與 FINAL 位置；若只有某個主機異常，優先檢查精確網域、跳轉後的主機及位址變化；若整條代理路徑都失敗，先檢查目前的伺服器資訊與網路狀態。不同範圍的問題應從不同方向排查，不能一律新增 DOMAIN-SUFFIX 解決。

依據現象選擇下一步

Connectivity Test 可協助判斷端點是否有回應，但不能取代完整驗證網站請求流程。測試通過後，業務請求仍可能因網域解析、規則、認證細節或目標限制而失敗。反之，某種測試方式未得到預期結果，也不代表所有業務連線都無法使用。應分別記錄測試目標、測試方式與實際業務狀況。

復原、更新與跨裝置使用

每次修改後，至少驗證一個預期符合規則的目標，以及一個不應受影響的對照目標。若出現問題，先回到上一份正常設定，確認問題確實隨修改出現，再一次只還原其中一項。遠端設定更新後也應進行相同檢查，尤其留意新增的廣泛規則、FINAL 位置與 DNS 參數。檔名沒有變，不代表設定行為也沒有改變。

跨裝置使用時，應先移植規則意圖，再確認欄位支援情形與網路環境。行動網路、家用區域網路與桌面網路的位址範圍可能不同，系統網路接管能力也各有差異；相同文字不保證所有裝置都會產生相同紀錄。規則與設定可供參考，但平台相關參數應重新驗證。各平台的取得方式請見下載頁，基本連線流程請參閱入門指南，常見狀況則可繼續查閱常見問題。

描述問題時，保留必要資訊

可重現的紀錄應包含目前模式、選用的設定、已移除敏感資訊的相關規則、實際主機或位址、預期與實際策略，以及修改前後的差異。不要傳送完整訂閱連結、認證欄位或含私人資料的紀錄；若必須提供設定，只截取相關區段並移除憑證。只有能逐行推演請求處理方式，才能判斷問題出在順序、參數還是連線。

最後可用三個問題檢查：請求使用了哪份設定、最先符合哪個條件、符合後的連線在哪個環節失敗。前兩項屬於設定解讀，最後一項則涉及網路與端點驗證。依照這個順序保留證據，通常能避免把所有異常都歸咎於「規則失效」，也能讓下次維護接續既有結論，而不必重新替換整份檔案。