Shadowrocket
規則與設定檔參考

設定檔結構

Shadowrocket 的設定檔通常以 .conf 儲存，並以方括號標示不同段落，再於各段填入相應內容。它不是逐項抄錄所有開關的文字記錄，也不等同於伺服器訂閱。閱讀時先找出段落名稱，再確認該段接受的欄位格式；同一句文字放在不同段落，可能不會生效，甚至造成解析錯誤。判斷設定是否正確，不能只看關鍵字。

各段落的用途

[General] 存放一般行為與解析相關選項，常見格式為欄位名稱、等號和值。[Rule] 存放依序檢查的分流規則，常見格式為類型、匹配內容與策略。[Host] 提供指定主機名稱的靜態位址對應。[URL Rewrite] 用於改寫符合條件的請求網址。段落名稱及其上下文，比檔案中的空白行數量更重要。

不要把這四個段落視為固定的處理流水線：請求不一定會先經過所有 General 欄位，再依序經過 Host 與 Rewrite。General 會改變用戶端行為，Host 會影響名稱解析，Rule 決定流量策略，Rewrite 則處理可識別的請求網址。各項功能的執行條件不同；調換檔案段落的前後位置，不代表改變網路處理順序。只有規則清單內的排列順序會直接影響優先級。

[General]
dns-server = system

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

[Host]
# 僅在需要固定對應時新增記錄

[URL Rewrite]
# 確認目標請求後再新增改寫

分開管理訂閱與設定檔

伺服器訂閱主要用來取得及更新連線項目，設定檔則主要描述這些連線如何處理請求。匯入自己的訂閱後，Home 中出現伺服器，不代表已啟用任何分流檔案；同樣地，匯入含有 PROXY 的規則，也不會自動產生可連線的伺服器。若規則可解析但無法建立連線，應分別檢查伺服器選取狀態與設定檔是否生效，不要反覆匯入同一個檔案。

遠端設定檔是另一種需要分開管理的內容。更新時，本機修改是否保留，取決於實際採用的更新與編輯方式。重要修改請先另存副本，再執行重新整理；不要假設訂閱更新會同步修正規則，也不要將伺服器訂閱失效視為本機規則損壞。訂閱更新相關操作可另參閱訂閱更新方法，本頁則著重說明設定檔本身。

設定檔可能包含伺服器憑證、私人位址、請求記錄相關設定或改寫目標。分享檔案前應逐段檢查，不只移除看得見的伺服器名稱，也要檢查 URL 參數、註解與靜態對應。排錯時通常只需提供相關幾行規則、目前模式與錯誤現象，不必傳送完整訂閱網址。範例中的 example.com 是教學用網域，請勿替換成他人的實際服務資訊後公開分享。

編輯、儲存與啟用

在 Config 中找到準備修改的設定檔，先確認它是否為目前使用的檔案，再建立可還原的副本。修改完成後儲存，並確認目前選用的設定檔仍是剛才編輯的檔案。檔名相同不代表內容相同；重新下載的遠端副本，也可能與本機編輯版本同時存在。比對檔案內容比只看清單名稱更可靠，尤其是在測試多種設定方案時。

編輯純文字時，請保留英文逗號、方括號與等號，不要用中文標點取代。規則最好每行一條，註解另起一行並以 # 開頭，避免在策略後隨意加上說明文字。若編輯器自動換行，只要沒有插入真正的換行字元，通常仍是一條規則；複製時則要確認長網址沒有被拆開，才能正確讀取完整欄位。

首次驗證建議從少量規則開始。先保留一個明確的網域條件與 FINAL，確認結果後再加入 IP、Host 或 Rewrite。修改後若出現異常，還原副本比繼續疊加修補更容易找出原因。後續範例都只展示局部語意，不要求將所有範例合併使用；實際檔案只保留符合目前目的、用途明確的項目。

General 與 DNS

General 是排查設定行為的起點，但不宜整段複製不理解的欄位。設定檔可以匯入，只代表文字可讀取，不代表每個欄位都符合目前環境。應先確認欄位在 App 內對應的設定與說明，再判斷是否需要覆寫預設行為。排查網路解析問題時，尤其要分清楚名稱查詢失敗、取得的位址無法連線，以及連線策略選錯這三種情況。

從最少欄位開始

dns-server = system 表示使用系統提供的 DNS 解析來源。這適合作為比較基準，但不代表所有網路環境的結果都必然一致：系統取得的解析伺服器會隨 Wi-Fi、行動網路或上游路由環境改變。測試時也要記錄目前使用的網路；否則同一份檔案兩次測試結果不同，可能只是解析路徑改變，並非設定未儲存。

[General]
dns-server = system

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

本段範例只用來釐清網域規則與系統解析的關係，不是通用建議方案。若既有設定檔包含其他 General 欄位，不必為了符合範例而全部刪除。請先備份，再一次只修改一個欄位，觀察失敗現象是否改變。用戶端全域設定與檔案欄位實際如何作用，仍應以目前 App 顯示及請求記錄為準，不能根據單一範例推論所有選項的覆寫關係。

設定檔中的布林值、位址清單與數字參數，都必須符合各自欄位的要求。不要在值後加上中文說明，也不要依其他軟體中的同名欄位猜測可用值。尤其是略過代理、排除路由與 DNS 設定，名稱看似相近，影響的層次卻不同；如果某條流量根本沒有進入用戶端，繼續調整 Rule 順序通常不會帶來預期效果。

網域解析與規則命中

DOMAIN 與 DOMAIN-SUFFIX 可利用已知主機名稱判斷條件；IP-CIDR 與 GEOIP 則需要目標位址資訊。若用戶端為了評估 IP 規則而解析網域，DNS 失敗可能讓這類條件無法如預期參與判斷。某條規則帶有 no-resolve 時，表示不會只為了該 IP 條件額外發起解析，不是禁止整個請求使用 DNS，更不是強制所有連線改用數字位址。

App 也可能直接連線至 IP，或透過自己的機制取得位址，此時用戶端未必掌握原始網域。不能因為瀏覽器網址列顯示某個網域，就認定每條底層連線都帶有可用網域；網頁可能同時請求多個資源主機。檢查請求記錄時，應逐一區分主站、靜態資源與 API 請求，觀察規則實際判斷的是網域還是位址，再選擇合適條件。

解析成功後仍可能無法連線。例如回傳的位址在目前路徑上無法連線，或 PROXY 使用的伺服器無法存取該目標。更換 DNS 後現象暫時改變，也不足以證明根本原因已解決；位址快取、連線重用與目標的多位址回應都會影響觀察結果。應在相同網路下重複測試，並比對實際連線位址，而不只是確認網頁第一次能否開啟。

IPv6、快取與驗證範圍

支援 IPv6 的網路可能同時回傳不同位址類型的結果。只寫 IPv4 網段規則，不會自動涵蓋 IPv6 連線；反過來，限制位址類型也不能取代修正錯誤的路由與解析。排查時先確認失敗連線使用哪種位址，再決定是否新增 IP-CIDR6 或檢查上游支援情況。不要把所有雙堆疊異常都歸因於網域規則；網域條件與位址可達性是兩回事。

快取可能讓剛修改的設定看起來毫無變化。DNS 快取會保存解析結果，瀏覽器與 App 也可能重用既有連線；即使儲存新規則，舊連線也不一定會重新執行完整匹配。驗證前請結束相關請求，必要時重新連線用戶端，再發起新的連線。連續重新整理頁面不一定會產生全新的解析與連線，記錄中的時間與目的位址更值得參考。

如果多個網域都無法解析，先還原可用的 General 基準設定並檢查目前網路；如果只有某個網域異常，先核對拼字、Host 覆寫與該網域本身的解析結果。若同一目標在 Direct 下可存取、在 Proxy 下失敗，應檢查伺服器路徑，不要繼續盲目更換解析來源。完整連線排查順序請見已開啟連線卻無法上網。

網域規則類型

網域條件適合用來設定依網站或服務名稱分流。常用的 DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD 並非三種等價寫法：它們的匹配範圍逐步擴大，誤匹配的風險也各不相同。選擇前先釐清需求是指定單一主機名稱、網域及其子網域，還是所有包含特定文字的主機名稱，再用範圍最小的條件實現，而不是先寫寬泛關鍵字，再補上一堆例外。

DOMAIN 精確匹配

DOMAIN,example.com,PROXY 表示對 example.com 這個主機名稱使用 PROXY。它不會因為 api.example.com 屬於同一網站，就自動涵蓋該子網域。精確規則適合單獨處理登入 API、下載主機或已確認的請求目標，範圍容易說明，也方便在記錄中核對；缺點是網站新增資源網域時，需要重新判斷是否補上規則。

規則中的網域不要包含通訊協定、連接埠與路徑。將完整網址填入 DOMAIN，會把原本屬於 URL 的內容混入主機條件。造訪 example.com 的特定頁面時，規則不會依賴路徑文字；若要區分同一主機上的兩個目錄，單靠網域規則無法做到。應先確認 App 是否提供適合該需求的請求處理功能，不要把路徑寫進 DOMAIN 並期待它部分匹配。

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

在這個範例中，api.example.com 先匹配精確規則，使用 DIRECT；其他屬於 example.com 的主機則交由後面的後綴規則處理。這個結果來自排列順序，而不是 DOMAIN 天生優先於 DOMAIN-SUFFIX。若兩行對調，前面的後綴規則就會先涵蓋該主機；只有未匹配該規則的請求，才會繼續檢查後續條件。

DOMAIN-SUFFIX 的網域邊界

DOMAIN-SUFFIX,example.com,PROXY 用於匹配 example.com 本身及其子網域，例如 www.example.com 與 api.example.com。它依照網域後綴邊界處理，不應理解為任意字串的結尾比對；notexample.com 並不是 example.com 的子網域。撰寫後綴規則前，請確認輸入的是要涵蓋的網域，而不是從瀏覽器複製的完整網址。

不要為了模仿萬用字元而在後綴前隨意加上星號。這個類型名稱已經說明匹配方式，直接填入 example.com 即可。後綴越短，涵蓋範圍通常越大；若條件擴及公用後綴或範圍很廣的組織網域，可能影響大量與目標無關的請求。維護設定檔時應加上註解，說明涵蓋目的，方便日後判斷寬泛規則是否仍有必要。

單一網站的資源不一定都放在主網域下。圖片、付款、身分驗證或檔案下載可能使用獨立網域；新增主站後綴後仍有部分功能失敗，不代表 DOMAIN-SUFFIX 本身失效。應在請求記錄中找出失敗的實際主機，確認確實屬於要處理的服務，再新增範圍明確的條件；不要只根據頁面上的品牌文字猜測資源網域。

DOMAIN-KEYWORD 的適用範圍

DOMAIN-KEYWORD,example,PROXY 會匹配網域中包含 example 的情況，範圍比後綴條件更廣，也可能涵蓋並非同一組織的主機。它適合用在命名特徵穩定、且能接受涵蓋範圍的情境。使用短字詞、常見詞或品牌簡稱作為關鍵字，容易產生意外結果；用於封鎖時尤其要謹慎，誤匹配會直接導致無關服務無法使用。

整理既有設定檔時，先列出關鍵字規則目前匹配到的主機，再判斷能否改用幾條精確規則或後綴規則。這麼做不是為了單純增加行數，而是將原本模糊的意圖轉化為可驗證的範圍。臨時排錯時，優先使用已觀察到的完整主機名稱；確認有效後再決定是否擴大範圍，避免把偶然匹配誤當成完整方案。

這三種類型都只描述條件，不決定請求最終能否成功。匹配到 PROXY 後仍需要可用的伺服器；匹配到 DIRECT 後仍受目前網路影響；匹配到 REJECT 則會主動拒絕請求。若記錄顯示規則已命中，應轉而排查策略與連線路徑，不必繼續調整網域寫法。若完全沒有相關記錄，也要確認請求是否進入用戶端，以及是否重用了舊連線。

IP 與識別範圍

位址規則用於處理明確的目標 IP 或網段，常見類型包括 IP-CIDR、IP-CIDR6 與 GEOIP。這類規則適合描述網路範圍，不等同於網域所屬組織，更無法取代完整識別 App 行為。同一服務可能使用多個位址，同一共享位址也可能承載多個網域。撰寫前先判斷要控制的是名稱、網段，還是某類可識別的請求，避免混淆不同面向。

IP-CIDR 與 IP-CIDR6

CIDR 使用斜線後的前綴長度描述位址範圍。在 IPv4 中，192.168.0.0/16 涵蓋對應的私有位址網段；192.0.2.10/32 則只代表單一 IPv4 位址。前綴長度不是連接埠，也不是任意的範圍編號。輸入時應使用符合網路範圍的位址，避免將主機位址與不理解的前綴隨意組合，意外涵蓋更大的網路。

[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
IP-CIDR6,2001:db8::10/128,PROXY,no-resolve
FINAL,PROXY

IPv6 使用 IP-CIDR6，單一位址可用 /128 表示。範例中的 2001:db8::10 是文件範例位址，並非實際伺服器；fc00::/7 是 IPv6 本機位址範圍，是否需要這類規則仍取決於網路配置。設定 DIRECT 不代表系統一定能連上目標；本機路由、裝置防火牆、服務監聽位址與用戶端接管範圍，都會影響最終結果。

無法存取區域網路印表機或管理頁面時，先確認連線的是目標實際位址，再檢查請求是否進入用戶端。若某些位址由系統直接處理，Rule 中看不到它們並不異常。反之，為私有網段設定 DIRECT 也不代表能找到所有裝置：自動探索使用的廣播或多點傳播機制，與連線至特定位址並非同一回事，應分開驗證。

GEOIP 與 no-resolve

GEOIP,CN,DIRECT 會依目標 IP 的地理分類結果匹配 CN。它判斷的是位址資料庫中的分類，不是網頁語言、使用者所在地、網域後綴或網站營運者。資料庫內容可能過時，服務位址也可能變動，因此 GEOIP 不能保證某個網站永遠採用固定策略。對於確定需要例外處理的網域，將精確規則放在前面通常更容易核對。

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

帶有 no-resolve 的 IP 規則，不會只為了判斷這項條件而額外解析尚無位址資訊的網域。如果請求本來就以 IP 為目標，或已有可用位址資訊，仍可能匹配。因此這個參數不是「略過所有 IP 規則」，也不會提高某條規則的優先級。是否加入，應取決於是否願意為這項判斷額外解析，以及是否接受其相依條件。

網域規則與 GEOIP 同時存在時，前面的網域條件命中後，後續地理條件通常不會再決定該次策略。若希望某個網域固定使用 PROXY，應將明確例外放在寬泛的位址分類之前。若只是想減少解析步驟，便機械式地為所有規則加上 no-resolve，可能使原本依賴解析結果的分流失效；進行最佳化前，先建立正確且可重現的基準。

USER-AGENT 的可見性

USER-AGENT 依據可識別的請求標頭內容進行匹配，不應當作 App 名稱規則。它通常適用於用戶端能讀取相關 HTTP 資訊的情況；範例 USER-AGENT,ExampleClient*,DIRECT 以模式表示一類請求標頭。這裡的名稱只是教學用值，只有實際記錄中存在相應內容才有意義；不能把手機桌面上的 App 名稱填進去，就期待用戶端自動依 App 分流。

一般 HTTPS 連線中，請求標頭位於加密內容內；有網路連線資訊，不代表能讀取 User-Agent。不要只為了讓規則命中，就任意啟用額外的內容處理或安裝憑證。一般分流先使用可觀察的網域與位址條件；只有在清楚了解可見範圍、處理條件與隱私影響後，才考慮更細緻的請求級匹配，並先在受控目標上驗證。

若某條 USER-AGENT 規則始終未命中，請依序檢查請求標頭是否可見、模式是否符合實際文字、前面是否已有規則命中，以及請求是否仍在重用舊連線。不要直接將未命中歸因於通訊協定不支援，也不要用寬泛關鍵字暫時掩蓋問題。規則能匹配哪些內容，取決於用戶端當時取得的資訊，而不是設定檔中寫了多少識別條件。

策略與運作模式

規則的最後一個主要欄位通常是策略。PROXY、DIRECT 與 REJECT 代表不同的處理結果，但所需資訊並不相同：PROXY 需要可用的代理路徑，DIRECT 透過目前網路直接連線，REJECT 則主動拒絕。理解這些詞之前，應先確認 Global Routing 目前選擇的模式；否則即使 Rule 內容正確，也可能未依設定模式處理請求，繼續修改檔案只會增加排查成本。

PROXY、DIRECT 與 REJECT

PROXY 表示將命中的流量交由代理路徑處理。常見的基本設定會使用 Home 中目前選取的伺服器，因此應先確認該伺服器本身能否連線。規則中的 PROXY 不包含伺服器位址、密碼或通訊協定參數；每行都寫上它，也不會自動修正錯誤的連接埠、驗證資訊或伺服器狀態。連線失敗時，應分別記錄「規則已命中」與「代理連線成功」這兩件事。

DIRECT 表示不經由該代理路徑直接存取目標，但不代表流量完全不受系統網路機制影響。目前網路的 DNS、預設路由、其他 VPN 設定與上游限制，仍會影響連線。使用 DIRECT 存取區域網路資源時，也要確認裝置目前確實連上可存取該網段的網路；切換至行動網路後，原本可連線的私有位址通常不會只靠這條規則就繼續可用。

REJECT 用來拒絕命中的請求，適合用於範圍明確且已確認可以封鎖的目標。它不是修復故障的策略，也不能只憑網域名稱判斷內容一定有害。規則範圍過廣時，頁面主體可能仍能顯示，但登入、驗證碼或檔案傳輸會失敗。新增封鎖規則後，應檢查完整服務流程，不能只看首頁是否開啟就認為沒有副作用；保留還原方式也比不斷新增例外更重要。

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

Global Routing 的三種模式

Global Routing 中的設定模式對應 Config，依目前選用的設定檔分流；代理模式對應 Proxy，透過代理路徑處理此模式涵蓋的請求；直連模式對應 Direct，使用直接連線路徑。這三者是運作模式，不是 Rule 中的三條規則，也不能與 PROXY、DIRECT、REJECT 簡單一一對應。尤其 Direct 模式不代表系統會自動在目前檔案開頭加入一條規則。

表中的模式不代表能繞過系統權限、接管排除項目或其他網路界線。若請求沒有進入用戶端，切換模式未必會改變其路徑。若介面另有 Scene 等入口，應依該入口的設定核對實際狀態；不能只憑名稱推斷目前生效的是哪份規則。排錯時先切回明確的 Config、Proxy 或 Direct，再對照記錄繼續處理。

在 Config 下失敗、Proxy 下成功，只能表示值得檢查分流或設定相關環節，不能立刻斷定某條網域規則寫錯。DNS、Host、拒絕規則與預設策略都可能造成差異。在 Proxy 下也失敗時，應優先檢查選用的伺服器與目標路徑。每次切換後都建立新連線，並測試相同目標，對照結果才有參考價值。

自訂名稱與實際目標

有些設定檔會使用策略組或特定伺服器名稱作為規則目標。這些名稱必須對應目前設定檔中可識別的項目，不能任意填寫標籤。保留他人檔案中的群組名稱，卻沒有相應定義，可能造成匯入提示或執行異常。基礎排錯時，可先在副本中改用理解的內建策略縮小範圍，再依據 App 對自訂策略的實際支援逐步還原，避免一次搬入整套複雜結構。

檢查設定檔時，不要只搜尋 PROXY。規則可能指向名稱相近的策略組，而群組內最終選用的項目也可能與 Home 目前選取的項目不同。應一併確認規則目標、群組選擇與最終連線伺服器，不能只看到「代理」二字就認定路徑一致。分享問題時，可用中性名稱取代私人伺服器標識，但應保留各項目之間的對應關係，避免去識別後失去排錯線索。

模式測試結束後，應切回原本預計使用的模式，並確認目前設定檔仍為選用狀態。暫時使用 Proxy 讓網頁恢復，不代表 Config 中的問題已經消失；忘記切回也會讓直連例外失去原本用途。首次選取伺服器與開啟連線開關的順序，請回到入門指南查閱；本頁只討論模式與規則的範圍。

匹配順序與預設規則

閱讀 Rule 的關鍵是由上而下檢查：前面第一條有效匹配會決定策略，而不是替所有條件評分後挑出最精確的一條。類型名稱、條件長度與策略名稱本身都不會自動提高優先級。要判斷請求為何走某條路徑，先找出能匹配它的第一條規則，再檢查後續項目是否因此未參與判斷；不要只搜尋檔案中最後出現的目標網域。

例外規則排在寬泛條件之前

若希望 example.com 及其子網域預設使用 PROXY，但 api.example.com 使用 DIRECT，應將精確例外放在後綴條件之前。這是便於維護的排列方式，不是固定語法要求。反過來說，若明確希望所有子網域都使用相同策略，就不必保留已被前文覆蓋的精確項目；移除不再生效的規則，有助於避免維護者誤以為它仍在控制請求。

[Rule]
# 先匹配精確例外
DOMAIN,api.example.com,DIRECT

# 再處理同一網域的其他請求
DOMAIN-SUFFIX,example.com,PROXY

# 最後處理其他請求
FINAL,DIRECT

關鍵字規則尤其要留意排列位置。若在上方加入 DOMAIN-KEYWORD,example,REJECT，上例中的 api.example.com 會先被拒絕，後面的 DIRECT 不會「修正」結果。遇到意外狀況時，應檢查目標規則之前的所有寬泛條件，而不只是查看目標附近幾行。規則越多，越要以註解說明每組範圍與例外，不能指望類型名稱取代文件說明。

位址規則也遵循相同的閱讀方式。若某網域的明確條件已命中，後續 GEOIP 不會再決定這次策略；若前面的 IP 判斷需要位址資訊，解析行為也會影響能否命中。排序時不只要考慮邏輯涵蓋範圍，也要考慮資訊是否可取得。先確定要表達的語意，再評估解析成本；不要為了少一次查詢，就把重要例外移到失效的位置。

FINAL 是最後的預設規則

FINAL,PROXY 表示未匹配前述規則的請求使用 PROXY。FINAL 不需要額外的網域或位址參數，後面的文字就是策略。它應放在相關規則清單末尾；若提早出現，後續項目對已進入預設處理的請求便失去作用。檔案中若有多個 FINAL，不要把它們當成逐層回退機制，應整理成一條意圖明確的末尾預設規則。

FINAL 使用 DIRECT 或 PROXY，取決於設定目標，沒有哪種寫法天生正確。大量直連例外搭配 FINAL,PROXY，與少數代理網域搭配 FINAL,DIRECT，代表不同的預設範圍。比較兩份設定檔時，應一併檢視前面的例外項目與末尾策略；只比較 FINAL 一行，會忽略真正決定大部分請求的條件，也容易誤解設定檔作者的意圖。

預設規則不會自動處理連線故障切換。請求命中 PROXY 後若連線失敗，不代表用戶端會繼續嘗試後面的 DIRECT 或另一條 FINAL；後續規則不是備援伺服器清單。若需要在伺服器層級選擇或復原，應查看相應的選擇機制，而不是在相同網域後再加一條不同策略。理解分流判斷與連線失敗後的處理是兩回事，才掌握得了規則行為。

衝突、重複與合併規則

條件與策略完全相同的重複項目，通常只會增加閱讀負擔；條件相同、策略不同的項目，則應確認哪一條先出現，以及保留它的理由。不能直接依字母順序排列整個 Rule，因為這會改變例外與寬泛條件之間的關係。整理前先依用途分組，例如明確拒絕、單一網域例外、網域集合、位址範圍與預設規則，再在各組中處理真正等價的重複項目。

合併兩份設定檔時，不要直接把第二個 Rule 段及其 FINAL 接到第一份後面。應先整理各自的用途，確認是否有互相覆蓋的網域、不同的策略名稱與重複的預設規則，再組成清楚易懂的清單。遠端規則內容變更時，也要重新確認新增條件是否擴大涵蓋範圍；「過去可用」不代表更新後的匹配關係仍然相同。

驗證排序時，可在副本中只保留一組衝突條件，使用同一目標反覆建立新請求，觀察記錄中的命中類型與策略。若移除上方的寬泛規則後結果改變，問題很可能出在涵蓋關係；若結果完全不變，則要檢查是否編輯了錯誤檔案，或仍未使用 Config 模式。縮小規則清單以取得證據，比不斷把規則移到最上方更容易得出穩定結論。

Host 與 URL Rewrite

Host 與 URL Rewrite 都可能改變存取結果，但作用層次不同。Host 為主機名稱指定位址，URL Rewrite 則處理符合條件的請求網址。兩者都不能取代代理伺服器選擇，也不能用來填入訂閱內容。排查時應將它們與 Rule 分開檢視：請求可能正確命中 DIRECT，卻因 Host 指向舊位址而失敗；也可能先被改寫請求目標，導致後續觀察到不同的網域。

Host 靜態對應

在 Host 段中，常見的靜態對應寫法是 example.com = 192.0.2.10。左側是主機名稱，右側是位址，不需填入通訊協定或網頁路徑。此處的 192.0.2.10 是文件範例位址，不能直接用於實際網站。實際設定應填入你有權管理或已確認的位址，只為需要固定對應的主機設定；不要猜測整個網站的所有資源網域都使用同一個位址。

[Host]
# 文件範例位址，僅用於展示格式
example.com = 192.0.2.10
api.example.com = 192.0.2.20

固定對應會改變解析結果，但不會自動改變 TLS 使用的網站身分。存取 HTTPS 時，目標伺服器仍須正確處理相應網域，並提供符合要求的憑證。只將網域指向一個能回應的位址，不代表網頁一定可用；若位址屬於其他服務，可能出現憑證錯誤、預設頁面或拒絕連線。不要忽略憑證檢查來掩蓋錯誤對應，應改回正確目標。

Host 也不能取代連接埠設定。同一台伺服器的不同連接埠可能對應不同服務，而靜態主機對應只描述名稱與位址的關係。如果問題是 App 連上錯誤的連接埠，應在相應的連線設定或目標 URL 中修正。排錯時先記錄原始主機名稱、解析出的位址與實際連接埠，再分別核對；只確認網域能否解析，無法判斷最終連線是否指向正確服務。

URL Rewrite 的條件與結果

URL Rewrite 規則通常以正規表示式描述要匹配的 URL，再指定替換目標與相應動作。以下範例示範將指定教學網域的 HTTP 網址重新導向至 HTTPS，並保留捕獲的路徑。這只用來說明格式；複製前必須了解匹配範圍與替換結果。在無法觀察相應請求內容的情況下，即使寫入規則，也不代表它會處理每一條連線。

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

正規表示式中的 ^ 限定起始位置，\. 表示字面上的句點，(.*) 捕獲後續內容，替換中的 $1 則引用第一組捕獲內容。句點未跳脫會擴大匹配範圍，缺少主機邊界的表示式也可能涵蓋非預期目標。不要為了讓規則「更容易生效」而刪除邊界；應使用具體請求逐項推演可能產生的替換結果。

重新導向可能讓用戶端再次存取新網址，因此要檢查是否形成迴圈。例如兩條規則分別將甲網址改寫成乙網址，又將乙網址改回甲網址，就會造成重複請求而非恢復存取。若涉及查詢參數，也要確認捕獲範圍是否保留必要內容，避免認證流程或分頁請求遺失參數。驗證時應從簡單、可控的 HTTP 目標開始，不要直接套用在登入或付款流程。

處理範圍與復原方式

一般 HTTPS 的路徑與請求標頭受到加密保護；用戶端取得目標網域資訊，不代表能讀取完整 URL。本章不要求為了改寫而新增憑證或內容解密設定。若需求只是決定某個主機使用 PROXY 或 DIRECT，使用 Rule 更直接；只有明確需要改變可識別的請求網址時，才考慮 Rewrite，不要把它當成更強的網域分流規則任意疊加。

排查時分別停用 Host 對應與 Rewrite 項目，不要同時刪除兩個段落後就斷定其中一項有問題。先還原原始解析，確認目標位址正確；再於未改寫狀態下測試請求；最後逐條恢復改寫，記錄首次出現差異的步驟。這樣能分辨舊位址、正規表示式範圍、迴圈與目標服務行為，也能避免把正常重新導向誤判為代理連線故障。

長期保留的對應與改寫規則應定期檢查。服務搬遷後，固定 IP 可能失效；網站調整路徑後，舊正規表示式可能不再匹配，或開始涵蓋新的服務網址。註解中應說明用途與驗證方式，但不要寫入實際憑證。無法說明用途的項目，先在副本中停用觀察，不要只因它來自舊設定檔就永久保留；維護的目標是讓行為清楚且可還原。

驗證與設定檔維護

設定驗證的目標不是不斷增加規則，而是讓每次變更都有可觀察的原因。開始前記錄目前網路、Global Routing 模式、選用的伺服器與設定檔，再選擇一個穩定且明確的測試目標。如果這些條件同時改變，就很難判斷結果來自哪項修改。建議保留已知可用的基礎副本，先將新規則加入測試副本，確認後再用於日常連線。

建立精簡且易於判讀的設定

最小化設定只需保留待測條件與一條明確的 FINAL，不必一次納入所有段落。測試網域例外時，先不要加入 Host 與 Rewrite；測試解析時，先避免混入大量位址條件。這不是要求長期採用極簡規則，而是減少同一現象背後的可能原因。只有能用一句話說明某一行的用途，才容易判斷應該保留、移動或刪除。

[General]
dns-server = system

[Rule]
# 驗證指定主機是否使用代理路徑
DOMAIN,example.com,PROXY
FINAL,DIRECT

範例設定只能證明指定條件下的行為，不代表適用於所有存取需求。使用前請確認已有可用的伺服器，並在 Config 模式下測試。若沒有實際存取教學網域的需求，可改用自己正在排查且有權存取的目標，但只填入主機名稱。測試成功後再逐步還原其他規則，每次新增一組並重複驗證，就能直接找出首次引發異常的修改。

排查區域網路問題時，以已知位址測試服務連接埠，比只看自動探索清單更有參考價值；排查網頁問題時，則應分別檢查頁面主體、登入與靜態資源。頁面成功開啟，不代表整個網站都使用相同策略。記錄中應找出真正失敗的請求，確認其主機名稱、位址與時間，而不是將同時發生的所有背景連線都視為故障。

依據證據判斷失敗階段

第一階段，確認請求是否進入用戶端。完全沒有記錄時，檢查連線開關、系統權限、接管範圍與舊連線重用，不要先修改規則。首次授權相關問題可參閱新增 VPN 設定提示說明。看到請求後再進入第二階段：確認網域或位址資訊是否完整，以及實際命中的規則是否符合目前檔案的排列。

第三階段，檢查策略對應的連線路徑。命中 PROXY 但連線失敗，檢查選用的伺服器、通訊協定參數與目標可達性；命中 DIRECT 但失敗，檢查目前網路與目標服務；命中 REJECT，則先確認是否預期封鎖。Connectivity Test 有助於觀察伺服器連線狀態，但測試目標與實際服務目標不同，其結果不能直接證明所有網頁都能存取。務必分開記錄工具測試結果與實際請求。

第四階段，排除快取與狀態差異。完成修改後先儲存並確認檔案仍為選用狀態，結束舊請求，必要時重新連線，再存取相同目標。比較時保持網路不變，不要同時從 Wi-Fi 切換至行動網路並更換伺服器。若只有某種網路異常，優先追查該網路的解析與路由差異；若所有網路都異常，再檢查設定檔共用部分或目標服務本身。

備份、更新與問題記錄

維護記錄應寫清楚修改目的、涉及的規則與驗證方法，不要只留下「修復網路」這類結論。例如：「將指定主機的 DOMAIN 例外移至後綴條件之前，重新連線後命中 DIRECT。」這比只說「移動規則有效」更容易重現。分享記錄時，應移除私人訂閱參數與認證資訊，只保留說明問題所需的結構與去識別目標。

更新遠端設定檔前，先儲存本機修改；更新後比對 General、Rule、Host 與 Rewrite 是否有實質變更，不要只看檔案長度。更新伺服器訂閱時，則另行確認項目是否仍存在及目前選取是否改變，勿混淆這兩種更新。若使用自己的維護檔案，應明確規劃自動更新內容與手動例外的管理方式，避免下次重新整理時覆蓋剛完成的修正。

需要復原時，切回已知可用的設定檔副本，並重新確認模式與伺服器；不要只還原最後一行，就假設所有狀態都已復原。還原後使用相同目標重新驗證，再決定是否繼續測試。若仍無法定位，可依常見問題的分類繼續查閱，並附上最小重現步驟。完整安裝與取得問題請參閱下載頁的安裝放行說明；本頁的規則修改不能取代系統安裝與權限設定步驟。