Shadowrocket
規則與設定欄位

設定檔結構與生效條件

設定檔不是伺服器清單

設定檔描述用戶端如何處理請求，伺服器資訊則說明如何建立連線，兩者需要分開檢查。匯入訂閱後，若在 Home 看到項目，只能表示伺服器資料已載入用戶端，不能據此認定某份規則檔已啟用。反過來，設定檔能正常儲存，也不代表其中的 PROXY 策略有可用連線。排查時應先區分這兩種資料，避免用替換規則來處理伺服器憑證問題。

在 Config 確認目前選取的設定檔，再檢查 Global Routing 是否設為 Config。此模式會依目前設定檔處理流量，是閱讀本頁 Rule 範例的前提。切換為 Proxy 或 Direct 後，請求處理路徑會改變，不能再用同一套規則命中預期來判斷設定檔是否正確。檔名僅供識別，名稱相同不代表內容相同；同時有多個檔案時，更要確認選取狀態與實際儲存的文字。

依區段劃分職責

區段名稱放在方括號內，決定後續各行要依哪種語法解析。General 常見格式為鍵和值；Rule 常見格式為以英文逗號分隔的規則欄位；Host 則將網域對應至位址。把網域規則貼到 Host 區段，或把一般設定貼到 Rule 區段，即使文字看起來完整，也無法達到預期效果。編輯時先找到區段名稱，再插入內容，比只搜尋某個關鍵字更可靠。

[General]
dns-server = system

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

[Host]
router.example.com = 192.168.1.1

上方檔案包含三個職責不同的區段。網域後綴規則用來選擇連線策略，Host 行則指定某個主機名稱的解析位址，兩者不是同一種覆寫設定。範例採用 DIRECT 作為預設策略，是為了清楚呈現比對範圍，並非所有情境都適合使用這個預設值。若要更換預設策略，應先確定未命中規則的請求應如何處理，再確認所選連線是否可用，不要只憑檔名判斷用途。

建立可復原的編輯流程

修改前先匯出或保留目前設定檔副本，並為測試檔取一個能辨識用途的名稱。開啟副本後，每次只修改一個設定區段或一組密切相關的規則。儲存後，再確認 Config 中目前選取的項目；若編輯的是另一個檔案，單純儲存文字不會自動切換正在使用的設定檔。測試結束後記下修改目的，成功就保留，失敗則還原至已驗證的副本，不要繼續疊加不確定的欄位。

設定文字中的標點也屬於語法。規則使用英文逗號，鍵值設定使用英文等號，位址範圍使用斜線；從富文字複製時，應檢查是否混入全形標點、不可見空格，或因換行而截斷欄位。編輯器中的長規則視覺折行，不一定代表實際換行；應以檔案中的真實行為準。註解可用來說明規則用途，但不能取代策略欄位，也不要把連線密碼寫進說明文字。

遠端設定更新與手動修改也要考量覆寫關係。若編輯的是由遠端來源更新的檔案，下次更新可能改動本機內容。先確認檔案來源及 App 內的更新方式，再決定是否建立本機副本來維護自己的規則。訂閱更新通常針對伺服器資料，設定更新則針對設定文字，不能因兩者都使用網址就視為同一項操作。儲存與移轉流程可繼續參閱設定備份與換機移轉筆記。

General 與 DNS 解析範圍

分開理解一般設定與規則選擇

General 描述設定檔的一般行為，不會像 Rule 一樣逐條比對。這裡的設定可能影響網域解析、位址處理與連線環境，但不能把它當成另一份分流清單。檢查不熟悉的欄位時，先在 App 內相應的設定編輯或說明中確認是否支援，再判斷值是否有效。其他文字中曾出現某個鍵名，不代表目前 App 一定能識別；用途不明的欄位不宜直接加入正在使用的設定檔。

DNS 負責將主機名稱解析為位址，Rule 則依請求資訊選擇策略。解析成功不等於代理連線成功，策略選對也不代表解析結果正確。例如網域規則已命中 PROXY，但伺服器連線失敗，問題仍可能出在連線參數；又例如請求採用 DIRECT，卻取得無法存取的位址，就應繼續檢查解析來源與目標服務。分別驗證這兩個環節，才能縮小修改範圍。

先保留簡單的解析基準

[General]
dns-server = system

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

dns-server = system 表示使用系統 DNS 作為這項設定的解析來源。範例重點在建立容易還原的基準，不是保證所有網路環境都會得到相同結果。使用系統解析時，目前網路的 DNS 設定會影響結果；切換網路後，解析結果與連線狀況都可能改變。比較兩次測試時，必須記錄網路環境是否一致，否則容易把網路差異誤認為規則修改造成的效果。

若要調整 DNS 伺服器，應先確認自己的網路需求及目前 App 接受的值格式，再修改單一設定。不要同時更換解析來源、加入 Host 對應並重排規則，否則難以判斷成敗原因。解析服務位址與代理伺服器位址不是同一個欄位，把現有訂閱位址填入 DNS 設定也不會匯入伺服器。設定完成後，應重新送出請求，並參考記錄確認取得的位址是否符合預期。

網域、位址與 no-resolve

只要請求中有可用的網域名稱，網域規則就能參與比對；位址規則則需要目標位址資訊。若請求只有網域名稱、尚未取得位址，某些位址比對條件可能需要先進行解析，因此規則順序可能影響是否觸發額外解析。排查解析延遲時，不應只檢查 DNS 設定；也要確認前面的位址規則是否為了判斷命中而觸發解析，以及原本可以先比對的網域規則是否被排在後面。

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

no-resolve 是位址規則的選用修飾欄位，可避免為了比對這條規則而主動解析網域。它不代表整份設定檔停用 DNS，也不表示後續連線不需要解析。如果用戶端已掌握目標位址，仍可依現有位址檢查這條規則；若沒有位址，就不應期待它透過額外解析將網域歸入某個網段。不要把它加到所有規則末尾，網域規則和 FINAL 也不會因此產生新的含義。

位址類型與快取造成的差異

同一個主機名稱可能回傳多個位址，也可能同時回傳不同位址類型。只設定一條 IPv4 網段規則，不會自動涵蓋 IPv6 目標；反過來，設定了 IPv6 位址規則，也不代表網路一定能連線。應先觀察實際使用的目標位址，再確認規則是否涵蓋該位址。為了排除單次故障而任意停用某個位址類型，可能掩蓋目標網路或連線設定問題；相關開關應依 App 內說明確認。

修改解析設定後，舊連線、App 快取與系統快取都可能繼續影響觀察結果。重新整理頁面不一定會建立新連線，既有連線也不會因文字改動就必然重新執行完整比對。測試時應關閉或結束相關請求，再重新發起一個容易辨識的存取；必要時依 App 內提供的操作更新解析狀態。記錄網域、回傳位址、命中策略與連線結果，比只記下「能開啟」或「無法開啟」更適合用來比較。

DOMAIN 系列的範圍與寫法

精確比對與後綴比對

DOMAIN 用來比對完整網域名稱，DOMAIN-SUFFIX 則用來比對指定網域及其子網域。兩者的差異主要在涵蓋範圍，而非哪一種天生有較高優先順序。只需處理單一主機時，精確比對較容易限制影響；需要處理整個網域樹時，後綴比對較容易維護。先列出要納入及排除的主機，再選擇規則類型，避免只因寫法較短就擴大分流範圍。

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

這個範例讓 api.example.com 使用 PROXY，其他屬於 example.com 的主機則使用 DIRECT。例外必須放在涵蓋範圍較廣的規則之前，因為該主機也符合後綴條件。若交換前兩行，後綴規則會先命中，下面的精確規則就不會再決定這次請求。精確比對的類型名稱不會自動越過前面的規則；優先順序仍須透過文字排列表達。

網域欄位應填入主機名稱，不包含協定、路徑、查詢參數或連接埠。存取網址中的頁面路徑並非 DOMAIN 的比對值，直接貼上完整頁面網址通常無法表達預期的主機比對。若要依路徑變更網址，應查看 URL Rewrite，而不是在網域規則中加入斜線。編輯完成後，先將欄位拆成類型、比對值與策略三部分，確認各自的用途都清楚。

控制關鍵字比對範圍

DOMAIN-KEYWORD 會檢查網域中的關鍵字，其涵蓋範圍通常比後綴規則更難從文字判斷。相同字串可能出現在互不相關的主機名稱中，因此不適合用來取代明確的網域範圍界線。關鍵字也不是正規表示式；將句點、星號或括號依正規表示式的方式填入，不能因此期待它進行正規表示式比對。若已有明確的網域清單，優先使用能準確描述目標範圍的條件來組織規則。

[Rule]
DOMAIN,keep.example.com,DIRECT
DOMAIN,ads.example.com,REJECT
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT

範例先用前兩行保留直連例外並拒絕一個精確主機，之後才由關鍵字規則處理其他符合條件的網域。這裡的 ads.example.com 僅為語法範例，不代表任何實際內容分類。拒絕該主機也可能影響頁面載入所需的資源，使用前應確認目標用途。若誤拒絕造成頁面空白，應從實際請求記錄找出相依關係，而不是立刻新增涵蓋範圍更廣的允許規則。

子網域、別名與請求可見資訊

一個頁面可能會連線至多個主機，包括介面、圖片、驗證與靜態資源。只為瀏覽器網址列中的網域設定規則，不會自動讓其他主機採用相同策略。發現部分內容載入失敗時，應列出失敗請求所對應的主機，分別檢查是否落在目前的後綴範圍內。也不要只因某項服務使用相同目標位址，就把它與其他位址相同的網域視為同一個網域規則範圍。

網域別名與解析鏈應和原始請求主機分開看待。看到 DNS 結果指向另一個名稱，不代表所有比對都一定改為檢查該名稱；實際可見資訊應以目前的請求記錄為準。直接存取位址時，用戶端可能沒有足夠的網域資訊供 DOMAIN 系列命中，此時應檢查位址規則與預設策略。不要只憑網頁標題或 App 名稱推斷請求使用的主機名稱。

驗證後綴規則時，至少分別檢查根網域、一個子網域及一個範圍外網域。再為前置例外發起獨立請求，確認記錄中的策略確實不同。若為了臨時測試加入精確規則，應在測試記錄中說明原因，完成後再決定保留或刪除。例外逐漸增加時，定期合併重複行並移除過期主機，比無止境地在檔案頂端新增規則更容易維護與還原。

位址規則與 USER-AGENT 條件

IP-CIDR 與位址範圍

IP-CIDR 以網段描述 IPv4 位址範圍，斜線後的數字是前綴長度，不是連接埠號碼，也不是要比對的位址數量。前綴越長，範圍越小。檢查規則前，應先確認目標位址屬於哪個網路，而不是只比較前幾個字元。多個範圍重疊時，仍依規則位置選擇策略，因此較小範圍的例外要放在涵蓋它的較大範圍之前。

[Rule]
IP-CIDR,192.168.1.10/32,REJECT,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

範例第一行只比對一個 IPv4 位址，後續兩行則分別比對常見的私有位址範圍。第一行放在較大範圍之前，因此該位址會先被拒絕；若移到後面，就會被既有的 DIRECT 規則涵蓋。私有位址規則不代表同一位址在任何網路中都指向同一台裝置；切換網路後，它可能對應另一台主機。使用這些範圍時，應依目前的區域網路與自己的連線環境判斷。

IP-CIDR6 用於 IPv6 位址範圍，不能以 IPv4 寫法取代。範例中的範圍與 IPv4 私有位址並非一一對應，只是用來說明不同位址類型需要分別設定。同一服務可能同時有兩種位址，實際命中哪條規則取決於目標位址。排查時應記錄完整位址，尤其不要因介面顯示網域名稱，就忽略最後使用的是哪種位址類型。

GEOIP 不是網域分類

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

GEOIP 依據位址的地理資料庫資訊進行比對，不能以網域後綴、頁面語言或網站名稱取代判斷。同一網域使用不同的分流位址時，比對結果可能隨實際位址而改變。它適合表達位址分類條件，不適合保證某項業務永遠採用同一策略。若需明確處理某個網域，應將網域規則放在地域規則之前，以明確條件設定例外。

位址資料庫可能與服務實際部署情況有所差異，地域比對結果也不代表服務營運者所在地。遇到結果與預期不同的請求時，應先核對目標位址與記錄，再決定是否新增精確網域規則。為了修正單一網域而改變所有地域流量的策略，通常會擴大影響範圍。需要解析才能取得位址的請求，也應配合上一章的 DNS 與 no-resolve 範圍一併判斷。

USER-AGENT 的適用條件

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

USER-AGENT 依據可取得的請求標頭資訊進行比對。此處的 ExampleClient* 是用來說明萬用字元寫法的範例模式，不是真實 App 識別字。它不是依 App 名稱比對，也不是依裝置程序選擇策略。只有在能看到相關請求資訊時，這種條件才有判斷依據；不能假設所有 App 連線都帶有相同請求標頭，更不能把它當成穩定分類某個 App 全部流量的方法。

加密請求中的內部標頭欄位並非自然可見。不要為了讓 USER-AGENT 規則命中，就任意新增憑證或變更 HTTPS 處理設定；這類操作涉及獨立的信任與存取範圍，必須先確認授權與用途。一般網域分流先使用 DOMAIN 系列即可。即使某次測試看到了請求標頭，也不能據此認定背景連線、其他介面或後續請求都符合相同條件。

整合規則時，先放明確的主機例外，再依需求加入位址範圍與地域條件；若使用請求標頭條件，則需另外確認其可見性與比對範圍。排查未命中原因時，應區分三種情況：欄位不存在、欄位存在但值不符、前面的規則已命中。三種情況的處理方式不同，不能一概靠調整萬用字元解決。將每條規則所需的資訊寫進維護說明，可減少日後反覆猜測。

策略、Global Routing 與比對順序

先看模式，再看策略

Global Routing 決定目前採用哪種整體處理模式。Config 依設定檔分流，Proxy 採用代理模式處理，Direct 則採用直連模式；實際效果仍須配合 App 目前設定與請求類型觀察。確認正在使用 Config 後，才能用 Rule 文字中的逐條比對來解釋本章範例。切換模式可用於定位問題，但不能取代規則修正；測試結束後應恢復原本明確選定的模式。

介面中的 Proxy 與規則中的 PROXY 位於不同層級，不能因名稱相似就認為兩者完全相同。前者是整體模式選擇，後者則是規則命中後採用的策略。DIRECT 不會透過所選代理連線至目標，但仍要求目標位址與本機網路可以連線。REJECT 用來明確拒絕請求，不應視為連線失敗後自動採用的備用策略；請求遭拒後不會因為失敗而繼續往下尋找允許規則。

命中即停止，例外放前面

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

這份範例由上而下檢查。介面主機先使用 PROXY，指定主機先被 REJECT，其餘網域樹使用 DIRECT；只有前面的網域條件尚未決定結果時，後續位址條件才有機會決定策略。規則類型不會自動排序，也沒有「越具體就一定優先」的隱含權重。文字位置是表達優先順序的重要方式；新增例外時，應檢查所有可能先行命中的規則，而不只看緊鄰的上一行。

常見的「網域優先、位址兜底」是維護者安排的順序，不是任何設定檔都會自動遵循的機制。把位址規則放在較前面，有時會先決定原本預期依網域處理的請求，也可能影響解析需求。實際情況取決於可用的請求資訊與具體條件。閱讀陌生檔案時，應依照實際順序檢查，不要根據分組註解推斷優先順序；註解即使寫著例外，若規則排在較廣泛的條件之後，仍然無法生效。

FINAL 的位置與意義

FINAL 是不帶額外比對值的預設規則，常見寫法為 FINAL,PROXY 或 FINAL,DIRECT。應將它放在規則清單末尾，讓前面的明確條件先完成選擇。若把 FINAL 放在中間，後續規則就失去預期的比對機會；重複新增多個 FINAL 也不會形成輪流嘗試的備援鏈。決定預設策略前，應先確認未列出條件的請求應如何處理。

PROXY 命中後連線失敗，不代表用戶端會自動改用 DIRECT，也不代表會繼續比對下一條 Rule。規則負責決定策略，連線結果則是後續環節；只有另外明確設定的相關機制才可能改變後續行為。若要檢查代理是否可用，應單獨測試自己現有的連線，並核對驗證與傳輸參數。用範圍寬泛的直連規則掩蓋代理故障，會讓記錄中的「頁面載入成功」失去原有的驗證意義。

依用途安排維護順序

建議依序整理精確例外、網域範圍、區域網路位址、其他位址分類與 FINAL，並註明各組用途。順序並非固定範本，重點是能說明每個例外為何放在目前位置。遇到重複規則時，不要只刪除看起來相同的主機，也要確認策略是否不同，以及是否刻意覆寫。放在大範圍規則之前的精確例外可能有其用途；放在大範圍規則之後且範圍、策略相同的重複行，通常只會增加維護負擔。

比較 Config 與 Proxy 的測試結果時，應同時記錄命中的規則與所選連線。若 Proxy 可以連線而 Config 失敗，優先檢查分流至 DIRECT 或 REJECT 的條件；若兩者都失敗，則繼續檢查連線與網路。Direct 成功也不能證明代理參數正確。更多模式說明請參閱Global Routing 三種模式筆記；修改時仍應以 App 內的實際記錄為準。

Host 對應與區域網路範圍

對應位址，不是選擇策略

Host 用來為指定主機名稱設定位址對應，解決的是「這個名稱對應哪個位址」，而不是「這項請求使用哪條連線」。完成對應後，仍須檢查適用規則與目前模式。尤其不要因主機名稱在 Host 中指向區域網路位址，就認定請求一定會直連；前置網域規則仍可能選擇 PROXY。讀取設定檔時，應一併檢查 Host 與 Rule，但分別理解兩者職責。

[Host]
router.example.com = 192.168.1.1
service.example.com = 192.168.1.20

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

範例明確為兩個主機指定位址，並以精確網域規則設定直連意圖。這只適用於自己有權存取，且目前網路中確實存在的對應裝置。範例位址不是所有網路都能存取的公開入口；若目前區域網路使用不同網段，照抄也無法連上服務。設定對應前，應先確認目標裝置的位址、連接埠與服務均正常，再將網域名稱作為方便辨識的存取名稱。

分別處理主機名稱、連接埠與路徑

Host 左側填入主機名稱，右側填入對應位址，不要混入頁面路徑、協定前綴或連接埠。位址對應不會修改 App 請求的連接埠，也不會把一般網頁請求轉換成另一種協定。目標服務若只監聽特定連接埠，存取端仍須使用正確方式。若對應已生效但服務無法連線，下一步應檢查連線目標與服務監聽狀態，而不是繼續在 Host 值中拼接路徑。

Host 也不是後綴規則，不能因為設定了一個特定主機的對應，就認定所有子網域都會得到相同結果。需要處理多個主機時，應逐一確認 App 支援的寫法與各自的目標，先使用明確的主機名稱建立可驗證的結果。一般分流通常不需要 Host；若只是要讓某個網域走代理，應以 Rule 設定策略並保留正常解析，避免手動固定位址而增加維護工作。

HTTPS 名稱檢查仍然存在

將主機名稱對應至某個位址，不會取代請求中的主機身分，也不會讓目標憑證自動適用於該名稱。HTTPS 連線仍可能檢查憑證名稱與信任鏈，目標服務也可能依主機名稱選擇網站。對應後若出現憑證錯誤，應確認服務是否真正支援這個名稱，不應把停用驗證當成一般修復方式。位址可連線、網域對應與憑證有效是三個獨立條件。

管理自己服務時，可依伺服器端設定安排正確的主機名稱與憑證，再於目前網路中驗證。若服務並非由自己管理，任意固定解析位址可能導致連到錯誤節點，或在位址變更後持續失敗。網路分流服務常會透過解析回傳不同位址，長期保留某次觀察到的位址可能破壞正常調度。若沒有明確需求，建議先移除測試用對應，讓正常解析恢復。

切換網路後的維護與還原

區域網路對應最常見的限制是切換網路。同一個私有位址在不同網路中可能不存在，也可能對應另一台裝置；離開原本網路後，對應設定不會因用途不再成立而自動改成公開位址。測試成功後，應記錄適用的網路與服務，並考慮是否要在其他網路停用相關設定。只憑一次成功記錄，不足以證明這項對應在行動網路或其他區域網路中仍然正確。

排查時先確認目前網路，再直接檢查目標位址的服務是否可連線，接著確認對應後的網域請求是否使用預期位址與策略。若直接連位址就失敗，優先處理網路或目標服務；若位址可連線但網域無法使用，檢查名稱、憑證與 App 的請求方式；若兩者都正常但策略錯誤，則檢查前置 Rule。分層驗證可避免在 Host 中反覆修改位址，卻漏掉真正影響結果的規則。

刪除或修改對應後，應重新發起請求，並留意既有連線與解析快取可能保留舊結果。維護副本時，在註解中寫明每項對應的用途與還原方式，不要記錄裝置憑證。若某項對應只是暫時用於診斷，測試結束後就應從常用設定檔移除；若要長期保留，則應定期確認目標位址是否變更。設定用途限定得越明確，日後檢查時就越容易判斷哪些內容仍有必要。

URL Rewrite 的語法與作用範圍

重寫 URL，不是網域分流

URL Rewrite 以正規表示式比對請求網址，再依設定執行相應重寫。它與 Rule 的用途不同：Rule 選擇處理策略，重寫則改變符合條件的網址行為。若只需要讓某個主機使用 DIRECT 或 PROXY，不應加入重寫區段；只有明確需要將一種存取網址導向另一種網址，且了解 App 如何處理這類請求時，才應建立相應規則。

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

這個範例比對指定主機的 HTTP 網址，並用擷取內容組成 HTTPS 目標；末尾的 302 表示重新導向狀態碼。比對條件、目標與狀態碼以空格分隔，不沿用 Rule 的逗號格式。此範例僅用來說明結構，不代表該網域實際提供相應服務，也不應直接套用於任意網站。實際設定必須針對自己明確獲准存取且可驗證的對象。

錨點、跳脫與擷取群組

正規表示式開頭的 ^ 限定從網址開頭比對，末尾的 $ 限定比對至結尾；網域中的句點需以反斜線跳脫，避免被解讀為任意字元。括號會形成擷取群組，目標中的 $1 則參照第一組內容。檢查規則時，應逐一說明這些符號的作用，不要只把整個運算式當成固定字串複製。少了跳脫字元或錨點，都可能擴大原本預期的比對範圍。

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

第二個範例只處理指定主機下以 /old/ 開頭的路徑，其他路徑不符合此條件。擷取內容會用於組成目標，因此要檢查實際輸入包含哪些內容。查詢參數、編碼字元與結尾斜線都可能影響比對結果，不能只用一個短網址推斷所有請求都正確。若組成的目標多出斜線、遺失參數或形成無效網址，應調整運算式，而非藉由更換代理策略處理。

重新導向會產生新的請求

重新導向回應通常會要求存取端再次請求目標網址；新請求可能涉及不同主機、協定或路徑，因此還要重新考量後續策略與服務行為。原始請求採用 DIRECT，不代表新目標也會採用 DIRECT；若目標主機改變，應分別檢查兩次請求命中的規則。在疑難排解記錄中看到多個請求不一定代表錯誤，重點在於它們是否形成符合預期、有限且明確的跳轉流程。

務必避免把目標再次改寫成會命中相同條件的網址，否則可能造成跳轉循環。檢查時至少列出原始網址、重寫目標，以及目標是否再次符合條件。範圍較廣的正規表示式若排在前面，也可能先處理後續的精確條件，因此應先放範圍較小的特例，再放已驗證的一般規則。正規表示式越來越複雜時，拆成幾個容易說明的條件，通常比繼續增加巢狀結構更容易排查。

HTTPS 可見資訊與存取範圍

一般連線轉送無法直接讀取加密請求中的完整路徑與標頭欄位，因此不能假設針對 HTTPS 路徑的重寫規則自然可見。處理 HTTPS 內容時，需要另外了解 App 內相關設定、憑證信任與目標範圍；本頁的簡單範例並不要求啟用這些功能。只為了修復一般連線故障就新增內容處理設定，會讓問題從規則分流擴大到信任與相容性，應避免混在一起排查。

即使有權管理目標服務，也應只處理明確需要的主機與路徑，並保留原設定作為還原基準。重寫可能影響驗證跳轉、跨主機請求、表單送出及伺服器端網址檢查。先以一般讀取請求驗證網址變化，再檢查實際業務流程；不要用單次頁面成功載入取代完整驗證。若網址含有敏感參數，測試記錄只保留必要且已遮蔽的結構，不要匯出完整存取資料。

維護時應為每條重寫規則記錄用途、比對範圍與撤銷方式。規則失效後，先停用該行並確認原始網址能否正常存取，再判斷是服務變更還是運算式問題。同時修改 Rule 與重寫規則時，很難判斷是哪一層改變結果，因此應分兩輪測試。若實際需求只有主機分流，請改用網域規則；若不需要重寫，設定檔完全可以不含這個區段，不必為了結構完整而新增無作用的內容。

設定驗證、分層排錯與還原

建立容易說明的測試設定檔

驗證應從已知可用的狀態開始，而不是從不斷新增欄位的複雜檔案開始。先確認自己現有的伺服器能完成基本連線，再於副本中保留必要的一般設定、少量明確規則及一個 FINAL。暫時移除與本次目標無關的 Host 與重寫規則，並不是認定它們有錯，而是為了減少變數。基準穩定後，再逐組恢復；每恢復一組，就用相同請求觀察一次。

[General]
dns-server = system

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

這份範例可用來檢查精確代理例外、明確拒絕、後綴直連及預設代理四種結果。它仍只是語法範例；實際驗證時，應換成自己有權存取且狀態已知的目標，不要以範例網域是否提供網頁來判斷用戶端是否正常。每個測試目標只用於驗證一項用途，盡量避免同時依賴多個未知介面。如此出現差異時，才能定位至特定條件，而非整份檔案。

儲存不代表已重新測試

儲存後重新確認目前的 Config、Global Routing 與連線，再結束原有測試請求並發起新請求。既有長連線可能延續先前路徑，App 快取也可能直接顯示舊內容，因此頁面沒有變化時，不能立刻判定新規則無效。查看 App 內的連線或記錄時，請核對請求主機、目標位址、命中條件與實際結果，確保查看的是修改後產生的資料。

區分語法、比對與連線故障

語法問題通常會導致設定檔無法正常載入、某行遭忽略，或設定未如預期被識別。先檢查英文標點、區段位置、額外欄位與實際換行，再將最近加入的內容從副本移除以供比較。比對問題則會表現為請求採用不同策略，應從清單頂端找出第一條符合條件的規則。若請求沒有網域或位址資訊，也應將「條件所需資訊不足」視為獨立原因，而非只懷疑欄位拼字。

策略正確但連線失敗時，繼續檢查伺服器、解析、目標服務與本機網路。Connectivity Test 有助於觀察連線狀況，但單次測試不能取代對所有協定及業務請求的驗證。應依自己的服務資料逐項核對現有伺服器參數，包括位址、連接埠、驗證及傳輸相關設定。不要因延遲測試有結果，就認定所有目標都可存取；也不要因單一目標失敗，就更改整份分流設定的預設值。

應單獨辨識遭拒絕造成的故障。命中 REJECT 後目標無法存取，是此策略的直接結果，不是代理連線品質問題。若拒絕影響到不希望阻擋的業務，應縮小比對範圍或調整前置例外，並重新測試頁面相依項目。網域關鍵字規則尤其需要檢查誤命中；修正時優先改用明確主機條件，不要用涵蓋整個網域樹的允許規則來抵銷範圍過廣的拒絕條件。

還原與變更記錄

每次修改記錄三件事：原先的現象、變更了哪些行，以及用哪些請求驗證結果。記錄應足以協助日後重現問題，不需要保存真實訂閱網址、驗證資訊或完整存取記錄。匯出設定檔前，先確認其中是否包含自己的敏感資料；提供疑難排解片段給他人查看時，只提供相關區段與已遮蔽的請求條件。設定範例中的明確示例值，應始終與真實憑證分開管理。

更新遠端設定檔或訂閱後，先確認哪些資料發生變化，再沿用原本的測試清單。伺服器資料變更可能影響 PROXY 連線，規則變更則可能影響比對，不能把兩種更新混在一起下結論。若新狀態無法使用，請還原至已驗證的本機副本，並確認目前選取狀態確實已切回；舊檔案仍保留在清單中，不代表已完成還原。恢復後再逐項找出差異，不要繼續在故障檔案中累積臨時修補。

本頁說明設定機制；首次匯入、開啟連線與基本驗證，請返回快速入門教學；需要簡短了解欄位名稱時，請參閱概念速查。購買、原帳號恢復與商店相容性相關事項，請查看已購項目恢復說明，不要透過修改設定處理。將問題歸回所屬層級，再以最小幅度修改進行驗證，是維持設定檔長期易讀的基本做法。