Shadowrocket
規則與設定完整指南

01 / FILE STRUCTURE

設定檔結構與生效入口

設定檔與伺服器資訊分開管理

Shadowrocket 的伺服器記錄與設定檔用途不同。伺服器記錄保存連線目標、連接埠、協定與驗證參數；設定檔則說明請求如何比對、採用哪種策略，以及如何處理部分解析與請求行為。使用本手冊的前提是使用者已有自己的訂閱或伺服器資訊。匯入伺服器後能選取該伺服器，不代表某份規則已啟用；反過來說，設定檔能正常儲存，也不代表其中的 PROXY 已有可用的連線目標。

開始修改前，先前往 Home 確認選取的伺服器，再到 Config 確認目前使用的設定檔，最後檢查 Global Routing。Config 設定模式才是檢查檔案內分流規則的常用入口。Proxy 與 Direct 用於切換全域路由模式，不能只憑這兩種模式的測試結果判斷某條網域規則是否正確。伺服器、檔案與全域模式這三處應分別記錄，避免修改其中一處後，誤以為另一處的狀態也同步改變。

依分段標題讀取檔案

設定檔採用分段文字格式，以方括號括住的標題標示後續內容所屬區域。[General] 用來放置全域參數；[Rule] 逐行列出比對條件與策略；[Host] 儲存指定網域的靜態對應；[URL Rewrite] 描述符合條件的 URL 處理方式。分段標題本身不是規則，也不會參與請求比對。將一條 DOMAIN-SUFFIX 寫在 [General] 底下，不會因為出現正確的關鍵字就自動成為有效的分流規則。

這段設定只呈現兩種路由意圖：example.com 及其子網域使用 PROXY，其餘流量交由 DIRECT 處理。內容不含伺服器驗證資料，也不提供任何連線服務。範例網域僅用於說明語法，不能據此預期能連線至任何服務。閱讀完整檔案時，先找出所有分段標題，再到 [Rule] 中定位 FINAL；不要只從第一行搜尋某個網域，卻忽略它實際位於哪個區域。

逗號、等號與註解各有用途

[General] 常見寫法是以鍵、等號和值組成，例如 dns-server = system；[Rule] 通常以半形逗號分隔類型、比對內容與策略，例如 DOMAIN,example.com,DIRECT。兩種格式不能互換。編輯時請使用半形標點，避免輸入法將逗號轉成全形逗號。註解可獨立以 # 開頭，用來記錄設定意圖；不要在行尾加上中文備註來解釋規則，另起一行更便於檢查欄位邊界與複製文字。

並非每份設定都需要四個分段。沒有靜態對應時，可以省略 [Host]；不需要處理 URL 時，也不必加入 [URL Rewrite]。從最少參數開始，再逐步加入用途明確的內容，比直接拼接多份檔案的段落更容易驗證。遇到重複分段或重複參數時，應整理為單一且明確的定義，不要依賴重複項目的覆寫行為；進行這類結構整理前，請先保留原始檔案副本。

02 / GENERAL & DNS

General 參數與 DNS 設定

先確認網路範圍，再設定略過範圍

[General] 中的參數會影響後續規則的執行環境。bypass-system = true 用於略過系統相關流量，不等同於將所有 Apple 網域設為 DIRECT，也不應視為可取代 [Rule] 的通用規則。skip-proxy 用來指定略過代理處理的地址範圍；若某個請求在進入規則評估前已被略過，修改後續的 PROXY 規則可能不會得到預期結果。疑難排解時，需一併檢查全域略過設定與 [Rule]，不能只移動規則行。

區域網路裝置通常需要依實際 IP 配置選擇略過範圍。192.168.0.0/16 與 10.0.0.0/8 是私有 IP 範圍的範例，不代表目前使用的網路一定採用這些位址。請先查看裝置的網路資訊與目標服務地址，再決定是否保留相關範圍。範圍設得太大，可能會排除原本需要透過代理連線的內部目標；範圍設得太小，則可能讓列印、儲存或其他本機連線走上不適當的路徑。

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

DNS 解析與路由策略是兩回事

dns-server = system 表示使用系統 DNS 設定，適合作為建立基準的寫法。DNS 的用途是將網域解析為 IP 位址，路由規則則負責決定請求採用哪種策略。網域能解析，不代表選取的伺服器能連線至該位址；請求命中 DIRECT，也不代表 DNS 查詢必然使用使用者預期的路徑。請分別檢查解析結果、規則命中情況與最終連線，避免將所有連線逾時都歸咎於 DNS。

變更 DNS 前，先確認要解決的問題：是網域沒有解析結果、解析結果不如預期，還是已完成解析但連線失敗。若問題只出現在單一目標，應檢查該目標與 [Host] 對應，不要立即更換整份檔案的 DNS 設定。若多個網域都無法解析，再檢查目前網路的系統 DNS 是否可用。加密 DNS 位址、引導解析與連線路徑之間也可能互相依賴，不能只看位址形式就判定設定適合目前網路。

規則是否觸發解析，取決於比對條件

DOMAIN 類規則主要依據網域進行判斷；IP-CIDR 與 GEOIP 則需要可供判斷的目標 IP 位址。請求以網域發起時，地址類規則可能會涉及解析流程。為 IP-CIDR 加上 no-resolve，表示避免為該地址規則額外進行網域解析，不是關閉整個用戶端的 DNS。這適用於明確的地址連線，或避免特定地址規則觸發解析的情境；但也可能使尚未取得 IP 位址的網域請求無法命中這條規則。

應用程式與系統可能會快取解析結果，網頁連線也可能重複使用既有連線。變更 DNS 後，直接重新整理同一個頁面，不一定能觀察到新的解析記錄。驗證時應重新發起連線，必要時重新連線 Shadowrocket，並留意記錄中對應的時間與目標。先保留一份可用的 dns-server = system 設定作為對照，每次只修改一項與解析相關的參數，才能分辨新設定的效果與舊快取造成的表面變化。

若問題只在切換 Wi-Fi 與行動網路後出現，請分別記錄兩種網路下的狀況。系統 DNS、本機地址範圍與伺服器連線狀態都可能隨網路改變。此時不宜擴大 skip-proxy 來掩蓋問題，也不要一再加入重複的 DNS 參數。先還原可用的基準設定並確認網路差異，再查閱疑難排解中的連線排查說明；確認需要長期修改後，再將參數寫入日常使用的設定檔。

03 / DOMAIN MATCHING

DOMAIN 系列規則的適用範圍

DOMAIN 只比對指定網域

DOMAIN 用於精確比對網域。DOMAIN,api.example.com,PROXY 只適用於 api.example.com，不會自動涵蓋 example.com，也不會因為其他網域含有相同文字就涵蓋 otherexample.com。規則欄位應填入主機名稱，不要填入通訊協定、路徑、連接埠或查詢參數。直接將完整網頁網址填入 DOMAIN 的比對欄位，會混淆 URL 與網域兩個層次；若需求與路徑有關，應先確認是否屬於 URL 處理，而不是擴大網域規則的範圍。

精確規則適合為特定服務入口設定例外，例如整個 example.com 使用 PROXY，但 status.example.com 需要 DIRECT。這條例外必須放在範圍較廣的 DOMAIN-SUFFIX 前面。若後綴規則先命中，後面的精確規則就不會參與判斷。優先順序取決於規則所在行的位置，而非 DOMAIN 看起來比 DOMAIN-SUFFIX 更精確；用戶端不會自動依精確程度重新排列檔案。

DOMAIN-SUFFIX 依網域層級比對

DOMAIN-SUFFIX,example.com,PROXY 會比對 example.com 及其子網域，例如 www.example.com 與 a.b.example.com。後綴比對依據網域層級邊界，不等同於任意文字包含，因此 otherexample.com 並非其子網域。後綴欄位通常不需要在前面加句點，也不必加星號。將 *.example.com 當成一般後綴範例複製，容易把萬用字元的用法套用到不相符的規則語法。

[Rule]
# 精確例外放前面
DOMAIN,status.example.com,DIRECT
# 主網域與子網域放後面
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

同一個網頁可能同時請求頁面主網域、圖片網域、驗證網域與 API 網域。只替網址列中的網域加上規則，不代表這些相依項目都會採用相同策略。請先從連線記錄找出實際請求的主機名稱，再決定要使用多條 DOMAIN，或使用能合理涵蓋這些網域的 DOMAIN-SUFFIX。不要把多個不相關的目標濃縮成過短的關鍵字，否則排查單一頁面時，可能連帶改變其他應用程式的流量路徑。

DOMAIN-KEYWORD 比對網域包含的文字

DOMAIN-KEYWORD,example,PROXY 會依網域是否包含 example 文字進行判斷，涵蓋範圍可能遠大於 example.com。它也可能比對到包含該文字的其他網域，不要求相同的註冊網域層級。關鍵字適用於範圍明確、確實需要文字比對的情境；若只是要涵蓋某個主網域及其子網域，應優先使用 DOMAIN-SUFFIX。關鍵字越短，越需要確認是否會意外命中其他目標。

將規則意圖寫成可驗證的條件

加入網域規則前，先用一句話描述範圍，例如「只有 status.example.com 直連」，再將描述與實際欄位逐一核對。若描述提到「所有子網域」，應確認是否該使用後綴規則；若提到「路徑為某個目錄」，則表示網域規則不足以表達需求。對於國際化網域，應核對請求記錄中實際出現的主機名稱，避免顯示名稱與設定文字不一致。不要只憑網頁標題或應用程式名稱猜測網域。

驗證時，分別存取需要命中的目標與不應命中的目標，完成正反兩組測試。記錄主機名稱、命中的規則與策略，不要只記錄頁面能否開啟。頁面成功可能是因為 DIRECT 也能連線，不能據此證明 PROXY 規則已生效；頁面失敗也可能是伺服器或目標服務造成。修改後若發現不相關的請求也被導向 PROXY，先縮小關鍵字範圍，再檢查行的順序，不要繼續在檔案末尾疊加同類規則。

04 / ADDRESS & REQUEST

GEOIP、IP-CIDR 與 USER-AGENT

IP-CIDR 依地址與前綴比對

IP-CIDR 用於 IPv4 地址範圍，例如 IP-CIDR,192.168.0.0/16,DIRECT。斜線後的數字代表前綴長度，不是連接埠或要比對的地址數量；前綴越長，範圍越小。單一 IPv4 位址可用 /32 表示。修改網段規則時，應一併核對目標的實際地址與網段邊界，不能只憑地址開頭相似就認定目標位於該範圍。前綴寫錯，可能會將大量不相關的請求套用相同策略。

理解區域網路範圍的處理方式時，也要一併檢查 [General] 中的 skip-proxy。若某個範圍已被全域略過，在 [Rule] 再寫入相同範圍的 DIRECT 可能只是重複設定，不能證明規則引擎命中了該行。若要確認某條規則的行為，應先釐清請求是否進入規則判斷。日常設定可保留必要的保護性直連，但應在註解中說明用途，不要把重複項目當成提高優先順序的方法。

[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
GEOIP,CN,DIRECT
FINAL,PROXY

IP-CIDR6 與 no-resolve 的適用範圍

IP-CIDR6 用於 IPv6 地址範圍，不能將 IPv6 文字直接填入 IP-CIDR，並期待以相同方式處理。fc00::/7 是本機 IPv6 範圍的範例，不代表所有 IPv6 請求都應使用 DIRECT。目標網域可能同時取得 IPv4 與 IPv6 的解析結果，因此只觀察其中一種地址，可能會遺漏實際連線路徑。若出現「同一網域有時命中、有時不命中」，應先檢查請求使用哪一種地址，再決定是否補上相應規則。

no-resolve 是地址規則的附加參數，用於避免為比對該行而主動解析網域。對於明確以地址發起的請求，已有地址可直接用於判斷；對於尚無地址可供比對的網域請求，這個參數可能導致該行無法命中。這不是語法錯誤，而是適用情境不同。不要為了縮短解析流程，機械式地替所有地址規則加上 no-resolve；也不要將它視為強制直連或強制使用遠端 DNS 的策略。

GEOIP 不等於網域歸屬

GEOIP,CN,DIRECT 依據目標 IP 的地區分類進行判斷，不是依據網域後綴、網頁語言或服務品牌。相同網域可能解析到不同地區的地址，地址資料庫的分類也不代表即時網路品質。若服務需要穩定的特定網域策略，應先用 DOMAIN 或 DOMAIN-SUFFIX 明確設定，再將 GEOIP 放在較後面處理其餘流量。否則地址變動時，同一服務可能在不同網路下採用不同策略。

USER-AGENT 依賴可讀取的請求欄位

USER-AGENT 比對可讀取的 HTTP 請求中 User-Agent 的內容，不會依應用程式顯示名稱辨識處理程序。範例 USER-AGENT,ExampleClient*,DIRECT 表示前綴比對的意圖，但只有在能讀取該請求欄位時才有判斷依據。一般加密連線中的 HTTP 請求標頭通常無法直接讀取；應用程式確實傳送這個欄位，不代表用戶端一定能以此進行規則比對。它不適合用來取代所有應用程式的分流規則。

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

為了讓 USER-AGENT 生效而啟用請求解密，會帶來額外的信任與相容性要求，並非初次設定分流的必要步驟。若需求能以網域規則表達，請先使用網域規則。地址規則與請求特徵規則都應有清楚的驗證前提：是否有可供判斷的地址、請求欄位是否可讀取，以及前面的規則是否已先命中。逐項確認這些條件，比將規則從檔案底部移到頂部更有依據。

05 / POLICY & PRIORITY

PROXY、DIRECT、REJECT 與比對順序

策略說明命中後的處理方式

規則類型決定檢查哪些內容，策略則決定命中後如何處理。PROXY 會將請求交由代理路徑處理；在簡單設定中，通常使用目前選取的伺服器。若檔案包含策略群組或其他關聯設定，還需確認實際選取的成員。DIRECT 表示直接連線至目標，不經由代理伺服器轉送，但流量仍受目前網路、DNS 與目標服務狀態影響。REJECT 表示拒絕符合條件的請求，不應視為連線失敗時自動切換的備援策略。

設定檔中的 PROXY、DIRECT、REJECT 是策略關鍵字；Home 中的伺服器選擇，以及 Global Routing 的 Proxy、Direct 則是介面狀態。兩者大小寫與使用位置不同，不能混為一談。將某條規則改成 PROXY，不會自動修正伺服器密碼、連接埠或協定參數。若所有命中 PROXY 的請求都失敗，應優先檢查代理連線路徑，而不是逐條將規則改成 DIRECT 後，就認定問題已解決。

Global Routing 三種模式

此表用於設定測試模式，不代表在所有情況下都能忽略系統略過設定與其他全域設定。疑難排解時，可短暫使用 Proxy 或 Direct 比較連線路徑；驗證完成後應切回 Config，再對照目前檔案檢查規則命中情況。否則，「修改檔案後沒有變化」可能只是因為仍停留在全域代理或全域直連模式。記錄測試結果時，應一併寫下模式與目標，方便區分同一目標在不同路由條件下的表現。

命中第一條規則後停止，不會自動改用後續規則

[Rule] 會由上而下檢查，第一條符合條件的規則決定採用的策略。較具體的規則應放在較通用的規則前面；這是編排原則，不代表用戶端會自動排序。若前面的 DOMAIN-KEYWORD 已比對到某個網域，後面的 DOMAIN 即使更精確也無法覆蓋。同一個比對條件若重複出現，後續項目通常只是無法觸及的重複規則，應予以整理，不要期待後寫的內容自動取代前面的內容。

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

在此範例中，status.example.com 會命中第一行，後續的後綴規則不再參與判斷；blocked.example.com 會命中 REJECT；其他 example.com 子網域使用 PROXY；其餘請求再由 GEOIP 判斷，最後交由 FINAL 處理。請求命中 PROXY 後若連線失敗，不會因此繼續往下尋找 DIRECT。規則判斷與連線執行是前後兩個階段，連線結果不會反過來改變已完成的第一條規則比對。

FINAL 必須明確表達預設意圖

FINAL 不需要比對欄位，寫法為 FINAL,PROXY 或 FINAL,DIRECT。它會處理前面沒有命中的請求，應放在 [Rule] 最後。放在 FINAL 後面的規則不會有機會處理這些剩餘請求。設定預設策略前，先確認「沒有特別列出的目標應走哪條路徑」，再據此設定；不要因為複製的檔案採用某個預設策略，就直接照搬。兩條 FINAL 也不能構成主備路徑，第二條不具備故障切換功能。

加入 REJECT 時，範圍應盡量明確，並單獨測試。同一頁面的統計、圖片、驗證與服務 API 可能共用網域，過於寬泛的拒絕規則可能造成頁面能開啟但功能異常。應先確認是否確實需要拒絕、能否以精確網域表達，再觀察相關請求。要還原時，請刪除或停用自行加入的拒絕規則，並重新建立連線；不要在後面加上 DIRECT，試圖抵銷已先命中的 REJECT。

06 / HOST & URL REWRITE

Host 對應與 URL Rewrite 的適用範圍

Host 會變更地址對應，不會直接決定策略

[Host] 用於指定網域與地址的靜態對應，例如 lab.example.com = 192.168.1.20。它回答的是「這個網域應取得哪個地址」，而非「請求應使用代理或直連」。使用這類對應後，仍需檢查 [Rule] 如何處理網域或目標地址。此範例適合說明由使用者自行管理的本機服務；只有確認該地址確實對應預期目標時才應採用，不要直接將範例地址用於連線至真實網站。

[Host]
lab.example.com = 192.168.1.20

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

靜態對應會固定解析結果，因此目標地址變更時也需要更新對應的映射記錄。若原服務透過多個地址分配負載，將其固定為單一地址可能會使連線略過正常的分配流程。修改前請先保留原始解析資訊，並確認網域、地址與使用目的相符。只在一台裝置上成功，不代表此對應適用於其他網路；例如離開指定 Wi-Fi 後，本機地址可能無法連線，此時應檢查網路範圍，而不是不斷重試相同對應。

地址對應無法取代憑證與服務身分

透過網域連線至 HTTPS 服務時，連線目標地址與憑證所對應的網域是兩項不同條件。[Host] 會變更地址，不會讓服務憑證自動適用於任意網域，也無法修正伺服器端的名稱設定。若出現憑證錯誤，應確認服務本身已為該網域提供正確憑證，不能將靜態對應當成略過驗證的方法。還原對應並重新建立連線，有助於區分原本的服務問題與自行固定地址所造成的影響。

URL Rewrite 使用正規表示式描述目標

[URL Rewrite] 使用 URL 比對運算式與對應的處理動作。以下範例會將特定路徑重新導向至另一個路徑，302 表示暫時重新導向回應。這不是代理策略，也不會自動將 PROXY 改成 DIRECT。規則中的 example.com 只是文字範例，不是外部服務入口。使用前應確認該動作適用於目前的請求環境，並從單一具體路徑開始驗證，避免寫出涵蓋整個網域所有路徑的寬泛運算式。

[URL Rewrite]
^http://example\.com/legacy$ http://example.com/current 302

運算式中的 ^ 限定起點，$ 限定終點，網域中的句點則以反斜線寫成 \.，避免被正規表示式解讀為任意字元。此範例只會比對以 /legacy 結尾且沒有其他查詢參數的完整網址；/legacy/ 或含查詢參數的請求不符合相同條件。若需要保留路徑或參數，應先了解擷取群組與替換之間的關係再擴充，不要隨意使用 .* 將所有內容都納入比對範圍。

先確認 HTTPS 的可讀取範圍限制

一般 HTTPS 連線不會直接揭露完整的 HTTP URL 路徑。對這類請求套用路徑層級的重寫，通常需要額外設定請求解密與憑證信任；僅在檔案中加入 [URL Rewrite]，不代表路徑已可讀取。部分應用程式也會進行額外的憑證檢查，啟用相關功能可能影響相容性。若沒有明確需求，請維持預設連線行為；網域分流不需要為了路徑重寫而同時加入解密設定。

重新導向會產生新的存取目標，新請求需要重新評估路由與服務條件。若目標又被另一條重寫規則改回原路徑，就可能形成循環。驗證時應記錄原始 URL、命中的運算式、回應位置與最終目標，不能只看瀏覽器最後顯示的頁面。先停用其他重寫規則，單獨測試一條規則，再逐項恢復，有助於區分規則互相影響與目標服務自行重新導向。若持續跳轉，應先還原重寫設定，不要擴大正規表示式範圍。

07 / EDITING WORKFLOW

設定修改流程與常見規則寫法

複製目前檔案，進行最小幅度修改

修改前先保留目前可用的設定，並使用易於辨識用途的名稱區分原始檔案與測試檔案。先寫清楚要變更的目標、比對範圍與預期策略，再到 Config 開啟對應檔案編輯。儲存後確認測試檔案已設為目前使用的設定，Global Routing 也已設為 Config，接著重新發起目標請求。不要同時更換伺服器、DNS、預設策略與多條規則，否則結果改變時將難以確認是哪項修改造成的。

使用者既有的伺服器訂閱與遠端設定可能有不同的更新入口。更新伺服器列表，不代表本機規則一定也已更新；重新取得遠端設定，則可能覆蓋先前對檔案所做的本機修改。編輯遠端內容前，先確認儲存與更新方式，並將自己的規則意圖保存在副本或獨立紀錄中。不要只靠檔名記住自行新增了哪些內容，最好用獨立註解說明每組規則的用途。

預設直連，僅代理指定網域

若需求是讓明確列出的網域使用代理，其餘流量直連，可採用以下結構。DOMAIN-SUFFIX 會涵蓋範例主網域及其子網域，FINAL,DIRECT 則明確處理其餘請求。加入新目標前，先確認現有後綴範圍是否已涵蓋；若已涵蓋，就不必重複加入相同策略。若服務相依項目使用其他網域，應依據實際連線記錄補充，不要猜測較寬泛的關鍵字來涵蓋所有可能目標。

[General]
dns-server = system

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

預設使用代理，為特定目標設定直連例外

另一種需求是將未特別列出的請求交由代理處理，同時保留區域網路或特定網域的直連例外。此結構必須先確認目前伺服器可用，因為 FINAL,PROXY 會讓其餘請求依賴該連線路徑。地址例外與網域例外應分別寫清楚，不要為了單一內部網域就擴大所有私有地址範圍以外的規則。若日常設定已包含全域略過，應先對照相關參數，再判斷是否需要重複加入網段規則。

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

這兩種結構都不是固定的推薦方案，而是用來表達不同的預設意圖。兩者不能直接合併成兩條 FINAL；合併前必須先決定最終預設策略，再將需要的具體規則放在它之前。若只想變更單一網域，不應順便修改整份設定的預設策略。驗證例外時，先確認目標是否命中具體規則，再檢查另一個未列出的目標是否採用 FINAL，完成兩組互相補充的測試。

合併檔案時先處理衝突，再整理長度

整理自行保存的多份設定中的規則時，先依類型與比對範圍找出重疊項目。若條件完全相同但策略不同，應決定哪一條符合目前意圖；若精確網域與後綴規則重疊，應保留正確的例外順序；若關鍵字與後綴規則重疊，則需確認關鍵字範圍是否過廣。規則數量多不代表涵蓋更精確，重複與無法命中的項目只會增加查閱負擔。整理後仍應保留單一且明確的 FINAL。

將完整檔案分成局部例外、服務網域、地址範圍與預設策略四組，是方便人工查閱的整理方式，並非必須採用的固定順序。各組之間可用註解說明意圖，但實際優先順序仍由行的位置決定。若某條地址例外必須優先於範圍廣泛的網域條件，就應依實際需求調整位置。每完成一組整理，都使用相同目標重新測試並記錄結果，避免一次重新排序後無法還原原有行為。

本頁不重複說明匯入入口與伺服器欄位的操作細節。需要重新整理既有記錄時，可先查閱訂閱匯入方式；需要了解協定欄位時，請參閱協定與參數說明。不要透過修改規則來彌補驗證或傳輸參數錯誤，這些問題發生在不同層級。

08 / VERIFICATION

規則命中驗證與疑難排解

每次測試記錄四項資訊

驗證規則時，至少記錄目標主機名稱或地址、目前的 Global Routing 模式、命中的規則或策略，以及最終連線結果。頁面能否開啟只是最後一項，不能取代前面的路由證據。在目前連線或記錄中查看目標與策略時，應以應用程式實際顯示的內容為準；不同請求可能對應多個網域與多條連線。先選擇一個可重複發出請求的明確目標，再追蹤相應的新記錄，避免把背景請求誤當成測試目標。

Connectivity Test 可用來檢查連線狀態，但無法證明某個網頁的所有相依項目都採用預期規則。確認伺服器可連線後，仍需發出實際目標請求並查看命中情況。修改規則後，既有連線可能仍會維持，瀏覽器也可能使用快取內容；必要時請重新連線並建立新工作階段。比較修改前後的結果時，應維持網路、伺服器與目標一致，只變更要驗證的規則，避免其他條件改變影響觀察結果。

設定沒有變化時，先檢查生效流程

若編輯後完全沒有變化，請依序從檔案、模式與規則順序三個層面排查。先確認儲存的是目前使用的檔案，而不是同名副本；再確認 Global Routing 設為 Config；最後從 [Rule] 頂部逐行檢查，是否已有更早的條件涵蓋目標。特別留意範圍廣泛的關鍵字、較大的網段與提早出現的 FINAL。不要因為新加的行語法正確，就跳過前面的規則；第一條命中的規則決定整份有序清單的結果。

命中正確，不代表連線一定成功

若記錄已顯示預期策略，問題就應轉向檢查實際連線路徑。PROXY 失敗時，請確認 Home 中選取的伺服器是否仍可使用，以及驗證欄位、連接埠、傳輸條件是否與現有資訊相符；DIRECT 失敗時，請檢查目前網路能否直接連線至目標；若為 REJECT，則應確認拒絕是否本來就是預期行為。不要將明確的連線失敗繼續當成規則優先順序問題。必要時可短暫使用 Proxy 與 Direct 進行對照，再切回 Config 重新測試。

只有部分功能失敗時，請分開檢查頁面主請求與後續 API。登入、檔案上傳、圖片載入與持續連線可能使用不同網域或連線方式，單一頁面成功並不代表所有相依項目都正常。先檢查是否有 REJECT 命中關鍵 API，再查看相依請求是否落入不符合預期的 FINAL。若只有特定傳輸方式失敗，應回頭檢查伺服器與協定支援，不要以擴大網域比對範圍取代傳輸層疑難排解。

以最精簡設定定位問題，再還原完整檔案

最精簡設定保留必要的 [General]、一條目標規則與一條 FINAL，暫時移除自行加入的 Host、重寫規則與範圍廣泛的關鍵字。此設定用於確認基本比對是否符合預期，不代表使用者應永久捨棄原有設定。若最精簡檔案正常運作，請逐組還原原有內容，直到問題再次出現；若仍然失敗，先檢查目標名稱、解析結果與伺服器連線路徑。每輪只還原一組，才能將問題定位到特定條件，而不只是知道完整檔案有問題。

還原時應一併恢復設定內容與測試模式，並重新發起連線。記錄問題時可包含目標、網路類型、規則片段與錯誤描述，但應移除訂閱連結中的驗證參數、伺服器密碼與其他私密欄位。直接將真實驗證資料複製到疑難排解記錄，會讓原本局部的連線問題演變為資訊外洩風險。保留足以說明結構的範例文字，即可討論規則順序、分段位置與欄位數量。

首次連線與 VPN 設定授權問題，請返回快速入門；購買、恢復與系統需求請參閱已購項目恢復說明，系統需求以 App Store 頁面標示為準；更多常見狀況請查看疑難排解。本頁說明設定機制，不將應用程式購買、伺服器連線與規則比對混為同一類問題。