Shadowrocket
設定與規則參考

設定檔結構與生效範圍

先分清伺服器資訊與設定檔

伺服器資訊包含連線至遠端所需的位址、連接埠、協定及驗證欄位；設定檔則說明如何處理請求、使用哪些規則，以及如何解析網域。將訂閱匯入 Home，不代表 Config 中的規則檔也已更換。反過來，匯入含有 Rule 的檔案，也不會自動補上使用者自己的伺服器憑證。排錯時請先確認這兩種項目，避免在錯誤的位置反覆修改。

在 Config 查看目前選用的設定檔，再開啟內容編輯。匯入、儲存與選用是不同操作：檔案出現在清單中，只能表示檔案已存在；編輯器顯示新內容，只能表示目前正在檢視該檔案。是否由它控制連線，仍須確認目前的選用狀態。修改前記下檔名與選用狀態，儲存後再次確認；必要時先中斷連線再重新連線，讓後續測試使用新設定。

四個區段各自負責什麼

區段標題使用方括號，欄位與規則則寫在相應標題下。General 是一般設定，Rule 負責比對請求與選擇策略，Host 用於靜態網域位址對應，URL Rewrite 則改寫符合條件的 URL。這些區段不能互相取代：把網域對應寫進 Rule 不會變成 Host，把重新導向運算式寫進 General 也不會成為可執行的分流規則。區段名稱與規則關鍵字請保留英文原文。

[General]
bypass-system = true
skip-proxy = 192.168.0.0/16, 10.0.0.0/8, localhost
dns-server = system

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

[Host]
localhost = 127.0.0.1

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

此範例將未命中的請求交給 DIRECT，只有示範網域使用 PROXY，因此不適用於所有代理設定。複製前請先了解末尾策略。General 中的略過範圍也會影響後續處理流程；如果請求已在較早階段略過代理，就不能只靠移動 Rule 中的一行，讓它重新進入規則比對。

編輯、儲存與備份的基本順序

先保留可正常使用的檔案，再複製一份用於測試。每次只修改一個區段或一條規則，儲存後重新選用並測試。若檔案來自遠端網址，也要確認下次更新是否會覆寫本機內容；需要長期保留的修改，應放在可獨立維護的本機副本中，不要仰賴某次更新後暫時留下的差異。備份名稱應能辨識用途，但不必包含帳號、伺服器位址或驗證資訊。

規則參數以逗號分隔，一般欄位或 Host 的鍵值則以等號分隔。不要將中文標點、說明文字或從網頁複製時帶入的特殊空格貼進設定檔。多行範例中的換行是真正的換行，不是畫面自動折行；編輯器顯示的單行內容過長時，可以左右捲動查看，不要任意將規則拆成兩行。註解應另起一行並以 # 開頭，避免把備註加在策略參數後面。

檔案能儲存，不代表語意都正確。拼字無誤但範圍過大的 DOMAIN-KEYWORD，可能正常執行，卻同時比對到不相關的請求；有效的 FINAL 也可能因位置過前而遮住後續規則。驗證時須同時留意語法、選用狀態與實際請求結果，不能只看編輯器是否顯示錯誤。

General 欄位與 DNS 處理

一般欄位不只是規則的前言

General 會決定部分請求如何進入處理流程，以及網域解析使用哪個來源。在理解 Rule 前應先查看這裡，因為連線是否進入代理處理、是否已取得位址、是否保留可供比對的網域資訊，都可能影響後續結果。不要把 General 當成固定範本：適用於某個區域網路的略過範圍，移到另一個網路後可能就不合用。

bypass-system = true 用於讓相關系統流量略過代理處理。這不是「所有請求都直連」的開關，也不等同於 Global Routing 的 Direct。保留此設定時，請留意相關系統請求可能不經過一般規則流程；若某項系統功能異常，應依具體請求與網路環境判斷，不能只憑一次網頁測試推論所有系統流量的行為。

skip-proxy 用來指定略過代理處理的目標範圍，常見對象包括區域網路位址與本機名稱。這種略過與 Rule 中指定 DIRECT 的階段不同。DIRECT 是請求進入規則處理後選用的策略；略過則可能使請求不依一般代理規則流程執行。因此，若記錄中沒有預期的 Rule 命中，請先檢查略過清單，不要立刻把同一條規則複製到檔案頂端。

[General]
bypass-system = true
skip-proxy = 192.168.0.0/16, 10.0.0.0/8, localhost
dns-server = system

system 的意義與測試基準

dns-server = system 表示使用系統提供的 DNS 來源，不代表固定使用某一台解析伺服器。切換不同 Wi-Fi 或行動網路後，系統取得的解析設定可能改變；區域網路中的名稱也可能只有目前網路的解析服務能識別。先以 system 作為基準，有助於判斷目前網路能否解析目標，再決定是否需要在自己的環境中指定其他解析來源。

DNS 負責將名稱解析為位址，規則則負責決定請求採用哪種策略，兩者彼此相關，但功能不同。DOMAIN 規則可依已知網域比對；GEOIP 或 IP-CIDR 針對位址，可能需要解析結果。若記錄顯示解析失敗，代表尚未取得所需位址，不能直接解讀為 PROXY 伺服器無法使用，更不能靠新增 FINAL 修復尚未取得的解析結果。

區分應用程式請求與解析請求也很重要。目標網頁使用 PROXY，不足以證明所有 DNS 查詢都經過相同路徑；實際解析行為還會受到應用程式、系統快取與設定選項影響。需要精確判斷時，請查看實際記錄與目前設定，不要只從規則行的策略名稱推測解析流程。若涉及伺服器網域，也要先確認伺服器本身能成功解析，避免把連線入口失敗誤認為目標網站分流失敗。

變更 DNS 前後的範圍檢查

外部網域可以解析、內部網域卻無法解析時，先確認是否已離開提供內部解析的網路；所有名稱都無法解析，但已知位址仍可直接連線時，再集中檢查 DNS 來源。不要同時修改 DNS、伺服器與 Rule，否則即使恢復連線，也無法判斷是哪個變更生效。每次修改後，請在相同網路下用相同目標建立新連線重測，並記錄結果。

DNS 快取可能讓修改效果延後顯現。系統、用戶端與應用程式都可能保留先前的結果，瀏覽器也可能沿用既有連線。儲存設定後只重新整理頁面，不一定會發出新的解析請求。請先中斷舊連線並重新連線，再重新開啟目標應用程式；只有在問題仍存在且確有必要時，才進一步檢查系統網路狀態。不要把一次快取命中當成新設定已驗證。

IPv4 與 IPv6 也要分開觀察。網域可能同時回傳兩種位址，若目前網路對其中一種位址的連線能力較差，就可能發生解析成功但連線逾時。此時應查明實際使用的位址與命中規則，不要只是更換解析來源。與其堆疊多個來源不明的欄位，不如保留可正常運作的基準，先對照「名稱、位址、策略、連線結果」四項資訊。

DOMAIN 系列規則的範圍

精確網域與網域後綴

DOMAIN 依指定網域比對，適合只處理一個明確的主機名稱。例如只讓 api.example.com 使用 PROXY，而不改變同一網站其他名稱的行為時，應優先考慮精確規則。參數填入網域本身，不要加上協定、路徑、連接埠或查詢字串。把完整網頁網址填入 DOMAIN 看似更精確，實際上卻不是此規則預期的比對對象。

DOMAIN-SUFFIX 依網域層級的後綴比對，example.com 可涵蓋該網域本身及其子網域，例如 www.example.com 和 api.example.com。它不是不受邊界限制地比對任意字串尾端，網域名稱之間的點號層級很重要。填寫後綴時通常直接使用網域，不必自行加上星號，也不要在參數後接上網頁路徑。

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

此順序會先比對 api 的精確規則，再涵蓋其他 example.com 請求。若將 DOMAIN-SUFFIX 放在前面，api 請求也會先被範圍較廣的規則比對；後面的 DOMAIN 不會因為「更精確」就自動優先。精確程度是編排規則時的判斷依據，不是規則引擎自動重新排序的條件。

為什麼關鍵字規則要謹慎使用

DOMAIN-KEYWORD 會依網域中出現的關鍵字比對，適用於確實需要以字串範圍比對的情況。它不會判斷網站歸屬，也不理解某個詞是否代表特定服務。關鍵字 example 可能出現在不同層級、不同後綴的名稱中，因此涵蓋範圍通常比 DOMAIN-SUFFIX 更廣。若能用明確網域或後綴表示，請優先採用範圍較窄、容易檢查的規則。

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

這裡使用關鍵字規則是為了展示不同範圍，不代表實際設定檔必須同時包含三種寫法。登入名稱先採用 DIRECT，接著網域及子網域使用 PROXY，其餘含有該關鍵字的名稱再由第三行處理。實際維護時應刪除沒有明確需求的廣泛規則，以減少誤比對與排錯成本；規則較多不代表設定更準確。

網域規則命中所需資訊

處理請求時必須取得可用的網域資訊，網域規則才能依名稱運作。若應用程式直接連線至 IP，或相關階段無法關聯原始網域，規則引擎可能只能繼續檢查位址規則。使用者在瀏覽器網址列輸入網域，不代表後續每條連線都保留相同名稱；頁面也可能載入圖片、API、字型或其他資源網域。

若首頁能開啟但部分資源失敗，請從記錄中找出實際失敗請求的網域，而不是只為首頁名稱重複新增規則。一個網站頁面通常依賴多個網域；這些網域是否應採用相同策略，應依實際請求判斷。不要為了省事而用短關鍵字涵蓋所有相似名稱，也不要從一次成功存取推論所有依賴項目都已涵蓋。

測試時準備一個應該命中的名稱，以及一個不應命中的名稱，分別觀察採用的策略。前者用來確認規則是否生效，後者則檢查範圍是否過廣。使用 DOMAIN-SUFFIX 時，應同時檢查根網域與子網域；使用 DOMAIN 時，則確認相鄰子網域不會被誤納入。正反兩組請求比只測試一個成功頁面，更容易找出範圍錯誤。

網域大小寫通常不是排錯重點，但建議統一書寫設定參數，方便檢查。國際化網域、特殊名稱或應用程式實際使用的正規化形式，應以記錄中可見的比對對象為準。不要根據網頁顯示名稱猜測規則參數；標題、連結文字與實際連線主機可能完全不同。修改後請保留測試依據，下次遇到類似問題時，才能判斷是規則改變，還是請求對象改變。

IP-CIDR、IP-CIDR6 與 GEOIP

位址網段不是網域分類

IP-CIDR 適用於 IPv4 位址範圍，參數由網路位址與前綴長度組成。192.168.0.0/16 表示該私有位址網段，而非單一主機；若只需比對一個 IPv4 位址，請在相應位址後使用 /32。撰寫規則前先確認實際目標位址與遮罩，不要把路由器位址誤當成整個網路，也不要為涵蓋一台裝置就擴大到所有私有網段。

IP-CIDR6 用於 IPv6 位址範圍，前綴長度同樣決定涵蓋範圍。fc00::/7 涵蓋 IPv6 唯一本機位址範圍，::1/128 則僅表示迴路位址。IPv4 與 IPv6 規則不能互相取代；同一網域若取得兩類位址，只寫 IPv4 網段不會自動限制 IPv6 連線。排錯時請檢查記錄中的實際位址類型。

[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，其餘請求交由 PROXY 處理。它沒有涵蓋所有特殊用途位址，也不能取代 General 中的略過設定。不要看到「本機網段直連」就認為所有區域網路名稱都能連線：名稱仍須解析到正確位址、網路須允許連線至相應裝置，目標服務也必須正常運作。

no-resolve 控制是否觸發解析

no-resolve 用來避免為了比對該位址規則而額外觸發網域解析。它不是 DIRECT 的別名，也不會停用整份設定的 DNS。若目前請求已帶有可供比對的位址，規則仍可依位址判斷；若只有網域且尚未取得所需位址，就不要預期這條規則會主動解析後再命中。是否加上此參數，應依需要比對的請求型態決定。

對於本來就透過 IP 存取的區域網路裝置，使用 no-resolve 的網段規則較容易理解；若透過內部名稱存取裝置，還須確認解析流程能取得本機位址。若為了「減少解析」而替所有位址規則加上此參數，可能會改變原本依賴解析結果的比對流程。結果不同時，先確認檢查這條規則時請求是否已有位址，不要只比較最後網頁能否開啟。

GEOIP 依位址資料庫判斷

GEOIP 會依 IP 位址的地理位置資料庫進行判斷，GEOIP,CN,DIRECT 是常見的語法範例。它不會依網頁語言、網域後綴、帳號地區或使用者所在地分類。中文頁面可能使用多個不同歸屬的位址，同一網域也可能由分散式服務回傳不同位址。因此 GEOIP 適合作為較廣泛的位址分類層，不能證明某項服務一定應直連。

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

將網域例外放在 GEOIP 前，可讓該網域先套用明確策略；接著由位址範圍與地理位置規則處理其餘請求，最後用 FINAL 收尾。若將 GEOIP 放在所需網域例外前面，且位址條件已符合，請求可能會先命中位址規則。所謂「網域優先」需要透過順序設定，並非規則類型會自動保證。

資料庫中的位址歸屬與當下網路是否可連線，沒有必然關係。命中 GEOIP 後連線失敗，可能是本機網路無法連至目標，也可能是目標服務異常，不能因此認定資料庫語法無效。需要穩定例外時，可依可確認的網域撰寫更具體的規則；不要只為固定某次測試結果，就把暫時解析到的位址永久擴大為大型網段例外。

位址規則也容易受到連線重用影響。修改網段策略後，應用程式可能繼續使用原有連線，記錄中也就沒有新的比對項目。請重新建立連線，再確認目標 IP、規則類型與最終策略。若同一名稱多次解析得到不同位址，應保留這些差異，判斷是位址池變動還是規則範圍遺漏，不要反覆移動 FINAL。

策略、Global Routing 與比對順序

分開看設定策略與介面模式

規則中的 PROXY、DIRECT、REJECT 是請求處理策略；Home 中 Global Routing 的 Config、Proxy、Direct 則是整體路由模式。兩組名稱相關，但不要混為一談。使用 Config 時，應著重檢查目前設定檔中的 Rule；切換為 Proxy 或 Direct 後，就不應再用一般設定模式下逐條分流的預期解讀測試結果。排錯記錄應先註明目前模式。

整體模式不代表系統層級略過、略過範圍等限制會消失。比較三種模式，是為了區分伺服器連線與設定比對問題，不是要證明每項系統請求都經過相同處理流程。測試結束後，請切回預期的 Config 狀態再驗證規則；否則即使編輯檔案正確，也可能看不到預期的分流結果。

三種常用策略的實際意義

PROXY 會將命中的請求交給目前的代理連線，前提是已有可用的伺服器資訊。規則寫成 PROXY 只表示選擇代理策略，不代表伺服器已通過驗證，也不保證遠端能連上目標。DIRECT 會從目前網路直接連線至目標，但不代表一定能成功；本機路由、解析與目標服務仍可能出問題。REJECT 則拒絕符合條件的請求，適合用於明確需要阻擋的對象，不應用來掩蓋原因不明的連線故障。

若設定檔引用其他命名策略，應先確認目前檔案確實定義並支援該名稱，不要把伺服器備註任意當成策略關鍵字。本文範例只使用三種基本策略，減少對檔案外部項目的依賴。伺服器備註、訂閱名稱與規則策略分屬不同層次，名稱相似不代表可以互換。

由上而下檢查，首次命中即停止

Rule 依檔案順序逐條檢查，符合條件的規則會決定該請求採用的策略，後續一般規則不會繼續替它尋找「更理想」的比對結果。建議將明確例外放在前面、範圍較廣的分類放在後面，最後以 FINAL 處理其餘請求。這種編排方便檢查，但關鍵仍在實際涵蓋範圍；看似具體的關鍵字規則，也可能比後面的後綴規則範圍更廣。

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

blocked 網域先遭拒絕，api 網域先使用 PROXY，其餘 example.com 網域則使用 DIRECT。若將第一行與後綴規則對調，阻擋例外就會被後綴規則遮蔽。若把 FINAL 放在開頭，它會提前處理剩餘請求，後續規則便難以依原意執行。檢查順序時，應逐行模擬請求符合哪些條件，而不是只搜尋檔案中是否出現目標網域。

FINAL 不帶比對目標，通常寫成 FINAL,PROXY 或 FINAL,DIRECT，並放在 Rule 結尾。它指定預設策略，不代表所有請求都必須由它處理。要判斷 FINAL 是否合適，先想清楚「前面規則未分類的請求應如何處理」，再確認自己已有的伺服器是否可用。兩種結尾策略都沒有脫離使用情境的通用答案。

維護時可按「阻擋例外、精確網域、網域後綴、位址分類、末尾策略」分組，並在各組前加入註解。每次新增規則，都要檢查既有規則是否已涵蓋新目標；重複行通常無法提高可靠性，反而會讓修改者誤以為後面的行能覆蓋前面的決定。刪除重複項目前，也要確認參數完全相同，避免誤刪刻意設定的不同範圍。

Proxy 模式可用但 Config 不可用時，優先檢查命中規則、DIRECT 分支、REJECT 與 DNS 關聯；兩者都失敗時，再檢查伺服器資訊與網路。Direct 可用也不代表所有目標都適合直連，只能說明當時測試的目標可透過該連線路徑到達。記錄同一目標在三種模式下的結果，才能進行有效比較。

Host 靜態對應與位址範圍

指定名稱對應，不選擇策略

Host 用於將指定網域對應至靜態位址。它改變的是名稱所對應的位址資訊，不會直接選擇 PROXY 或 DIRECT，也不能取代 Rule。若要指定某個內部服務的位址並讓它直連，應分別設定位址對應與策略；只寫 Host 就期待請求自動直連，或只寫 DOMAIN 就期待網域解析到指定位址，都是混淆了兩種功能。

[Host]
localhost = 127.0.0.1
intranet.example.com = 192.168.1.20

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

此處的內部網域名稱與位址只是教學範例，只有在使用者自己的網路確實提供相應服務時才有實際用途。範例網域不會因為寫入設定檔就產生伺服器，靜態對應也不會替使用者啟動目標服務。使用前先確認裝置位址、服務連接埠與目前網路，再決定是否保留這類對應，避免把範例誤當成可直接使用的功能入口。

localhost 指向目前裝置

localhost = 127.0.0.1 表示 IPv4 迴路位址，指向發出請求的本機，不是路由器，也不是代理伺服器。在手機上存取 localhost，不會自動連到另一台裝置上的服務。若教學要求連線至自己的區域網路裝置，請使用實際可連線的位址或正確的內部名稱，並確認服務監聽範圍允許其他裝置連入。

私有位址只在相應的網路路由中有意義。在家用 Wi-Fi 可用的 192.168.1.20，切換網路後可能不存在，也可能指向完全不同的裝置。將內部名稱固定對應至私有位址前，應考量適用範圍；若設定檔長期用於多種網路，靜態對應可能讓名稱持續指向失效位址，造成固定逾時，而非 DNS 查詢失敗。

Host 無法略過 TLS 身分驗證

HTTPS 連線仍會檢查目標憑證是否與請求主機相符。將網域指向另一個位址，不會讓新位址上的任意憑證自動獲得信任；伺服器也可能依主機名稱選擇網站。若設定對應後出現憑證錯誤，請確認位址是否屬於該服務、憑證是否涵蓋原始名稱，不要把錯誤解讀為「Host 沒有生效」。解析成功與身分驗證成功須分別判斷。

同一個 IP 可以託管多個網站，網域仍用於區分請求目標。因此，不能把「可以連上該 IP」當成「對應至它的任何網域都能正常運作」。檢查內部 HTTPS 服務時，應同時確認名稱、位址、連接埠與憑證。本文不要求變更憑證信任設定來配合靜態對應；請優先使用自己的服務已設定好的名稱與正確位址。

靜態對應、快取與動態服務

對採用動態位址或分散式服務的網域，固定位址可能破壞原本的流量調度。某次解析結果可以連線，不代表適合長期寫入 Host。服務調整後，舊位址可能不再提供相同內容，而靜態對應仍會持續覆蓋正常解析流程。若沒有明確的維護依據，不建議只為縮短一次解析時間，就固定公共服務網域的位址。

應用程式可能保留自己的解析結果或既有連線，部分請求也不一定使用相同的解析流程。修改 Host 後，請建立新連線並查看實際目標位址；若記錄仍出現舊位址，先排除快取與連線重用，再判斷是否選錯設定檔。不要只因編輯器顯示新對應，就認定目標應用程式已使用該設定，也不要預設所有應用程式的行為都相同。

刪除對應後，正常解析也可能暫時受到舊快取影響。還原時請保留原始檔案，移除單一對應、儲存並重新選用，再用相同目標重測。若名稱恢復正常但某個位址仍無法連線，表示先前問題較可能是靜態位址失效；若仍無法解析，則回到 DNS 章節檢查系統來源與網路環境。

長期維護 Host 時，每條對應都應有明確用途。可在獨立註解行記錄「本機測試服務」或「內部固定位址」等原因，不要填寫帳號憑證。裝置重新取得位址、網路網段調整或服務遷移後，都應重新確認。Host 項目越少且越明確，就越容易找出失效項目，也越不容易影響與測試無關的正常請求。

URL Rewrite 與 USER-AGENT 的適用範圍

改寫 URL 與選擇路由是兩回事

URL Rewrite 會比對並改寫可見的請求 URL，Rule 則會依請求條件選擇策略。將一個位址重新導向至另一個位址，不代表它會採用 PROXY；新位址產生的請求仍須依目前路由設定處理。了解這一點，就能避免「改寫成功但目標仍無法開啟」時只調整正規表示式，卻漏查新目標的網域規則、解析與連線狀態。

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

這一行示範將符合條件的 HTTP 位址重新導向至 HTTPS 位址。左側是正規表示式，中間是目標 URL，最後是重新導向狀態碼。^ 限定從字串開頭開始比對，\. 表示字面上的點號；網域後的斜線有助於限定主機邊界。若未跳脫，正規表示式中的點號可以代表其他字元，可能比對到原本不打算處理的名稱。

明確保留路徑與查詢參數

上方的簡短範例沒有指定保留原路徑與查詢參數，因此不適合直接套用於需要保留業務參數的請求。若目標位址含有 API 路徑、搜尋參數或驗證資訊，重新導向至固定首頁會改變請求內容。撰寫改寫規則前，先列出輸入與預期輸出，再決定是否需要擷取群組；不要先複製一條範圍廣泛的運算式，再只憑頁面剛好能開啟就判斷正確性。

[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302

此範例使用擷取群組與 $1 參照，表示保留斜線後的內容。它仍只是語法範例：目標服務必須支援 HTTPS，用戶端也必須依重新導向行為繼續發出請求。遇到編碼字元、查詢參數或多次跳轉時，請查看實際請求結果，確認新位址符合預期。重新導向不是伺服器內部的路徑改寫，也不會改變遠端服務原本提供的內容。

302 與永久重新導向的快取語意不同。測試期間使用暫時重新導向較容易觀察變化，但仍須留意瀏覽器與應用程式自己的快取。設定生效後，若目標又被其他規則導回原位址，可能形成循環；若瀏覽器提示重新導向次數過多，請檢查每次跳轉的來源與目標，不要只修改最後一條規則。每次先保留一條容易理解的改寫規則進行驗證。

HTTPS 可見性與處理限制

一般 HTTPS 請求的路徑與標頭都位於加密連線中，不能因為用戶端承載了連線，就假設所有欄位都能供改寫使用。若要處理 HTTPS 內容，需額外設定 MITM、網域範圍與憑證信任，也可能受到應用程式憑證驗證方式限制。本文的精簡片段不包含這些設定，不應解讀為能直接改寫任意 HTTPS 應用程式。

即使具備內容處理條件，也應限制在使用者了解且確實需要測試的網域，不要為了讓一條規則命中就擴大到所有請求。含有登入參數、工作階段資訊或個人資料的 URL 不應複製到公開筆記。若目前只是要排除連線失敗，請先檢查 Rule、DNS 與伺服器，通常沒有必要先進入內容改寫層；路由排錯與內容修改應分開處理。

USER-AGENT 並非通用的應用程式識別方式

USER-AGENT 是 Rule 中依可見 HTTP 請求標頭比對的類型，不會依應用程式名稱識別所有連線。若加密流量中的相關標頭無法檢視，就不能期待它命中；應用程式也可能使用不同識別字、多個網路元件，或不提供可用的此欄位。因此，它適用於有明確請求樣本的情況，不適合當成「某個應用程式的所有流量」的通用替代規則。

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

此處的 ExampleClient 是教學用識別字，星號表示比對模式中的萬用範圍。只有實際可見欄位符合此模式時，第一行才會生效；未符合條件的請求會繼續比對後續規則。將此行放在前面，表示命中的請求會先採用 DIRECT，即使它後續也符合網域後綴條件。編排前請確認這種優先順序符合需求。

驗證 USER-AGENT 或 URL Rewrite 時，先確認比對對象可見，再確認運算式符合條件，最後確認結果正確。三個環節應分別記錄。沒有命中記錄時，不要立刻擴大萬用範圍；欄位不可見、請求根本沒有重新發出、設定檔尚未選用，都可能造成相同現象。先用一般網域規則建立路由基準，再逐項加入內容相關條件，測試過程會更容易還原。

設定驗證、排錯與維護流程

先建立可重複的測試基準

開始排錯前，記錄目前網路、Global Routing 模式、選用設定檔、目前伺服器與測試目標。不要將不同 Wi-Fi、不同目標及不同伺服器的結果混在一起比較。若使用者已有的訂閱剛更新，請先確認 Home 目前選取的仍是預期伺服器；設定文字沒有改變，也可能因訂閱內容或選取項目不同而產生不同結果。

Connectivity Test 可協助判斷伺服器測試結果，但單次測試成功不代表所有目標都能連線，也不表示 Rule 一定如預期命中。測試工具與目標應用程式可能使用不同的請求路徑。請將測試結果作為基準資訊，再透過目標的新連線核對網域、位址與策略。連線開關已開啟，只代表用戶端進入連線狀態，不能取代目標請求的成功驗證。

依處理流程逐步定位

第一步確認已選用正確檔案；第二步確認 Global Routing 使用 Config；第三步檢查 General 是否讓目標略過一般處理流程；第四步查看實際比對的網域或 IP；第五步確認命中規則與策略；最後檢查所選連線路徑的結果。依此順序可避免前提尚未成立就討論後續規則，也能區分「未進入比對」與「已命中但連線失敗」。

查看記錄時，請找出同一時間產生的新請求。舊記錄中的策略可能來自修改前的設定；連線重用也可能沒有觸發完整的新比對流程。重新連線後再開啟目標，可減少這類干擾。若仍沒有預期記錄，請繼續確認目標是否實際發出請求、是否透過 IP 直接連線，以及是否受到略過設定影響，不要直接新增重複規則。

用最精簡規則驗證單一假設

若懷疑網域規則範圍不正確，請複製可正常使用的設定檔，只保留必要的 General、目標精確規則與 FINAL，暫時移除相關關鍵字規則、Host 和 URL Rewrite。精簡檔案不是長期設定，而是用來驗證單一假設。若精確規則能穩定命中，再依序恢復後綴、位址分類與其他例外，找出是哪個部分改變了處理結果。

[General]
dns-server = system

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

此範例仍需要使用者已有可用伺服器。若在 Proxy 模式下也失敗，繼續擴充 Rule 沒有明確意義，應回頭檢查伺服器與網路。若精簡規則成功、完整設定卻失敗，請比較兩份檔案中提早命中的範圍、靜態對應與 DNS 設定。每次只恢復一組並記錄首次出現差異的位置，通常比一次加入所有內容更快找到問題。

保護資訊並保留還原能力

分享排錯資料前，請移除訂閱網址、驗證欄位、個人網域、敏感路徑，以及可能識別帳號的查詢參數。可以保留規則類型、目標類別、策略與錯誤現象，並以示範網域取代真實對象。截圖或記錄也可能含有憑證，不要因為它們不是設定檔就忽略檢查。說明基本規則語法不需要公開自己的訂閱。

長期維護時，請保留最近可正常使用的本機副本，記錄每次修改的目標與測試結果。遠端設定更新後，重新檢查選用狀態、FINAL、General 與重要例外，不要只比較檔名。新增規則容易、刪除卻困難時，可先逐組檢查用途；對於無法說明原因的廣泛規則，應先在副本中驗證移除效果，而不是持續增加新例外來補救舊問題。

基本操作請回到快速入門操作流程；介面與規則用語可查閱術語表。開關已開啟但網頁無法載入時，請依伺服器、模式、DNS 與規則排錯指南逐項檢查；系統授權異常可參閱新增 VPN 設定提示說明。這些入口處理不同問題，不必為同一現象同時重新進行購買、匯入與設定。