Shadowrocket
規則與設定參考

01 設定檔結構與生效範圍

Shadowrocket 的連線資訊與分流設定各有用途。前者說明如何連線至使用者已有的伺服器，通常包含協定、位址、連接埠與驗證欄位；後者則指定個別請求應採用哪種策略。匯入 Subscribe 不代表已選好規則檔，匯入 .conf 也不代表取得伺服器。維護設定前，請分別確認 Home 中的 SERVER 清單，以及 Config 目前使用的檔案，避免把兩個入口當成同一份資料。

先認識四個段落

設定檔以方括號中的段名劃分作用範圍。[General] 放置全域參數，[Rule] 放置有先後順序的比對項目，[Host] 放置主機名稱對應，[URL Rewrite] 放置 URL 重寫運算式。段名不是說明標題，而是解析器用來辨識後續內容用途的標記。同一行文字放在不同段落，可能會有不同解讀，也可能成為無效參數，因此複製片段時，務必一併確認所屬段落。

[General]
bypass-system = true

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

[Host]
example.com = 192.0.2.10

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

這段範例用來呈現段落界線，不是建議直接啟用的完整設定。example.com 與文件專用位址僅供說明語法，實際請求仍取決於使用者已有的伺服器、目前策略與網路狀況。尤其 [Host] 與 [URL Rewrite] 會改變解析結果或請求目標，初次建立基準時，建議先不加入這兩段的具體項目，待基本連線穩定後再逐項新增。

檔案存在不代表規則已生效

Config 可儲存多份檔案，但疑難排解時必須確認目前實際使用的是哪一份。編輯並儲存後，返回檔案清單確認選取狀態，再到 Home 檢查 Global Routing。若要檢查規則分流，通常應從 Config 狀態開始；Proxy 與 Direct 則用於不同的全域路由選擇。檔案已儲存，不代表每個請求都會依該檔案逐行比對。

編輯前請保留一份可正常運作的副本，並為工作副本取個容易辨識的名稱。名稱只需說明用途，例如「網域規則測試」，請勿將伺服器密碼、訂閱權杖或個人帳號寫入檔名。若同時維護遠端檔案與本機副本，請確認目前編輯的對象；遠端更新可能覆蓋同一檔案中的本機修改。重要的自訂內容應另行記錄，不要只靠記憶重新補寫。

將變更拆分為可驗證的小步驟

每次最好只修改一個層次。若要調整特定網域的連線方向，先只修改對應的 [Rule] 項目，不要同時變更 DNS、Host 與伺服器驗證欄位。如此一來，測試結果改變時，原因較容易鎖定在剛修改的規則。若一次改動多個層次，即使測試結果恢復正常，也難以判斷真正起作用的是哪一處，日後更新設定時便容易失去依據。

閱讀檔案時，先找段名，再找 FINAL，接著檢查預設處理之前有哪些涵蓋範圍較大的規則。這樣比逐字閱讀第一行，更容易掌握整體設定。遇到不熟悉的參數時，先保留原值並查明它控制的是流量接管、名稱解析還是請求比對；不要憑欄位名稱猜測取值，也不要直接把其他設定格式中的相似欄位搬進 .conf。

02 General：全域參數與 DNS 範圍

[General] 中的參數會影響整份設定的執行環境，不是針對個別網域進行判斷。規則寫法正確但實際行為不如預期時，除了檢查策略，也要確認全域設定是否改變流量進入規則系統的方式。尤其要分清楚「系統流量如何被接管」、「網域名稱如何解析出位址」及「最終連線走哪條路徑」這三件事：彼此相關，卻不是同一個開關。

bypass-system 與 skip-proxy

bypass-system = true 用於讓特定系統流量依相應機制略過代理處理。這不等同於啟用 [Rule] 中所有 DIRECT 項目，也不代表整台裝置都採用直連。要判斷某項流量是否參與規則比對，應參考實際請求紀錄與目前的接管條件，而不是只憑這個參數的布林值推斷。

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

skip-proxy 表示需要略過相應代理處理的位址範圍。範例只包含迴圈位址與一個常見的私有網段，無法涵蓋所有家庭與辦公室網路。若路由器、印表機或區域網路服務位於其他位址段，請依裝置的實際位址判斷。一次加入整個私有位址空間，可能讓原本需要透過受控路徑存取的內部服務改變連線方向，因此應先確認裝置所在的網路。

這裡的略過處理與 [Rule] 中的 DIRECT 不能簡單視為重複設定。前者可能影響流量是否進入後續處理，後者則是在規則層選擇直連策略。若某項區域網路規則始終沒有請求紀錄，可先檢查流量是否已被全域略過；若是如此，調整該規則的位置通常無法改變更早階段已做出的處理決定。

分別檢查 DNS 結果與路由策略

dns-server = system 表示使用相應的系統解析來源，適合用來建立容易理解的基礎設定，但不代表它在所有網路環境中都能解析使用者需要的名稱。DNS 負責將主機名稱轉換為位址，PROXY 或 DIRECT 則決定連線路徑。網域規則命中 PROXY，不足以證明名稱解析來源符合預期；解析成功也不足以證明目標連接埠可以建立連線。

設定其他解析伺服器時，只使用自己清楚其用途、權限與可連線性的位址。不要為了讓單次測試成功，就接連疊加多個來源；不同的解析結果、快取與網路切換會讓問題更難重現。先記錄系統解析結果，再保持路由規則不變並比較其他設定，才能判斷問題是否真的出在解析層。

位址規則可能觸發解析動作

網域條件通常可直接依請求中的主機名稱判斷；GEOIP 或 IP-CIDR 條件則需要目標位址資訊。若請求一開始只有網域名稱，判斷某些位址規則時可能需要先進行解析。規則項目帶有適用的 no-resolve 選項時，代表不要只為了比對這條規則而主動解析網域，不是「整個連線過程都不需要 DNS」。這項差異會直接影響網域請求能否命中位址類規則。

已有位址資訊的請求與尚未解析的網域請求，即使存取同一項服務，也可能經過不同的比對流程。維護者應在規則旁記下使用 no-resolve 的目的，例如減少規則判斷階段額外觸發的解析，而不是把它當成每條 IP 規則都要加上的固定裝飾。若要依最終位址決定策略，就應接受並驗證相應的解析前提。

網路變更後的檢查順序

iPad 或 iPhone 從一個 Wi-Fi 網路切換到另一個網路後，先確認基本網路可用，再重新檢查解析結果與區域網路連線。同一個私有位址在不同網路中可能指向不同裝置，不能把上次可用的結果當成永久事實。On Demand 控制連線觸發條件，不能取代 DNS 或 [Rule] 設定檢查；即使連線已自動建立，仍應確認新請求實際採用的策略。

維護全域參數時，設定數量應與用途相符。若一條具體網域規則就能解決問題，就不必先調整所有解析路徑；若修正一個私有網段即可，也不必擴大整份略過清單。儲存前確認英文逗號、等號與位址前綴；儲存後用新請求重新測試，避免舊連線與快取掩蓋修改效果。

03 Rule：網域條件與比對範圍

[Rule] 常見的行格式為「規則類型、比對內容、目標策略」。欄位以英文逗號分隔，網域欄位不填協定標頭、路徑或連接埠。例如要依 example.com 分流，只需填入主機名稱，不應寫成完整網頁網址。網域規則比對的是請求目標名稱，不是網頁標題、頁面內容或網址列中的所有文字。

DOMAIN：限定完整主機名稱

DOMAIN,example.com,DIRECT 只會比對完整名稱 example.com。其他名稱即使包含相同文字，也不會因此自動套用此規則；api.example.com 也不會自然納入。若要為特定 API 或登入主機指定策略，DOMAIN 的比對範圍較明確，通常適合放在涵蓋範圍較大的後綴規則之前。

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

在這組規則中，api.example.com 會先命中第一行並採用 DIRECT；example.com 與其他符合後綴條件的子網域則會繼續比對第二行，採用 PROXY。若調換前兩行，範圍較廣的後綴條件會先命中，後面的精確例外便不會生效。規則系統不會自動將比對更精確的 DOMAIN 移到前面，書寫順序就是實際判斷順序的重要依據。

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

DOMAIN-SUFFIX,example.com,PROXY 用於涵蓋 example.com 及其子網域，例如 a.example.com 和 b.a.example.com。這裡的後綴依網域標籤邊界判斷，不應將 notexample.com 視為同一個網域。常見的錯誤寫法是加上星號，以為必須使用萬用字元；這種類型的規則直接填入網域後綴即可，不需要改成正規表示式。

若同一網域體系中的主機都採用相同策略，後綴規則很合適；但一個網站的完整功能可能還依賴其他獨立網域。登入、圖片、檔案與統計請求不一定都在同一個後綴下，因此「首頁能開啟、附件卻無法載入」不一定代表後綴規則失效。請先查看失敗資源實際使用的主機名稱，再判斷是否需要新增獨立規則。

DOMAIN-KEYWORD：依名稱中的片段判斷

DOMAIN-KEYWORD,example,DIRECT 會比對網域中含有 example 字串的請求，比對範圍較單一後綴更難憑直覺掌握。它可能涵蓋不同組織的主機名稱，也可能漏掉名稱完全不同的相關資源。除非確實需要如此寬泛的條件，否則優先使用完整網域或後綴條件，以減少日後難以解釋的誤命中。

從請求紀錄找出條件

新增規則前，先確認實際請求的主機名稱，不要從頁面名稱推測。一個 App 可能會連線至多個後端服務，網址列顯示的網域也可能只是入口。請對失敗的操作執行一次可重現的測試，再查看同一時段的目標名稱，據此選擇 DOMAIN 或 DOMAIN-SUFFIX。若紀錄只顯示目標位址，就暫時無法憑空補出確切網域條件。

比對國際化網域名稱時，請留意畫面上顯示的名稱與網路實際使用的編碼形式可能不同；應以用戶端紀錄中實際參與判斷的主機名稱為準。複製位址時，也要移除尾端路徑、查詢參數與多餘空白。網域規則不是 URL Rewrite，將路徑寫入 DOMAIN 欄位，不會自動取得路徑比對能力。

維護多條網域規則時，應分開記錄「業務目的」與「語法範圍」。例如，目的可能是讓某個自有測試服務使用指定路徑，但實際條件仍應填寫具體主機名稱。只留下「工作網站」這類註記，幾個月後便很難說明為何要使用寬泛的關鍵字。保留命中依據與選擇原因，通常比不斷新增互相重疊的項目更有助於長期維護。

04 IP、GEOIP 與 USER-AGENT 條件

網域條件依名稱比對，位址條件則依連線目標的 IP 比對。兩者描述的對象不同，不能假設某個網域永遠對應固定位址，也不能假設同一位址只服務一個網域。內容傳遞、負載平衡與網路位置都可能改變解析結果。因此，只有在目標確實以位址範圍管理時，才適合以 IP 規則作為主要判斷方式。

IP-CIDR：認識位址與前綴長度

IP-CIDR,192.168.0.0/16,DIRECT 表示比對一段 IPv4 位址範圍。斜線後的數字是網路前綴長度，不是連接埠或位址數量。前綴越長，涵蓋範圍通常越小；單一 IPv4 位址可用 /32 表示。編輯前應確認目標所屬網段，不要只因位址開頭相似，就任意擴大到更大的範圍。

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

192.0.2.10 與 2001:db8::/32 是文件範例，不是真正可連線的服務。IP-CIDR6 用於 IPv6 位址條件，不能直接把 IPv6 位址填入 IPv4 規則並期待系統自動轉換。若服務同時回傳兩種位址，只檢查 IPv4 規則可能會漏掉實際使用的 IPv6 連線；請先查看紀錄中的目標位址類型，再判斷需要哪種規則。

區域網路規則與實際拓樸

家庭與辦公室網路常見私有位址，但實際配置方式取決於網路管理設定。印表機無法連線時，先確認裝置的實際位址、子網路與網路隔離設定。若裝置位於另一個隔離網路，即使規則選擇 DIRECT，也不會自動建立跨網段路由或取得存取權限。規則只能選擇現有路徑，無法替路由器建立不存在的網路連線。

對於帶有 no-resolve 的位址規則，請再次確認請求是否已有目標位址。如果請求仍以網域名稱進入判斷，這個選項可能使位址條件無法透過額外解析取得所需資訊。此時應依實際目的選擇保留 no-resolve、補上具體網域規則，或驗證允許解析後的行為，不要盲目將同一網段複製成多條規則。

GEOIP：依位址資料庫分類

GEOIP,CN,DIRECT 會依目標 IP 的地理歸屬分類結果判斷，CN 是地區代碼。它判斷的不是網頁語言、使用者所在地、網站註冊地，也不是內容服務所面向的地區。中文頁面可能使用不同地區的位址，國際化服務也可能解析到本地的分發位址，因此 GEOIP 不應用來辨識業務身分。

資料庫分類有其限制，也可能變動，不能把單次命中視為永久結論。若要穩定處理某個明確服務，可將具體網域例外放在 GEOIP 之前；若要依大範圍條件分類其餘位址，再使用 GEOIP。分類結果不如預期時，請記錄目標 IP 與當時的解析結果，再檢查資料庫及規則順序，不要直接認定伺服器協定有問題。

USER-AGENT：可見請求資訊的限制

USER-AGENT 依請求中的 User-Agent 資訊比對，例如 USER-AGENT,ExampleClient*,DIRECT 表示前綴模式。它不是依 App 顯示名稱辨識所有連線，也不是系統層級的 App 識別碼。只有在用戶端能取得相應請求資訊、請求確實包含該欄位，且符合支援的比對方式時，這項條件才有判斷依據。

加密連線中的 HTTP 欄位通常無法直接從外層連線讀取，因此不要假設 USER-AGENT 能可靠比對所有 HTTPS 請求。也不要為了讓這條規則命中而擴大憑證信任或解密範圍。本手冊的基礎設定不依賴這類操作；若能用明確網域達成目的，請優先採用較容易驗證的網域條件。

組合這些類型時，先確認「目前實際可見的是什麼」：主機名稱、IPv4、IPv6，或可讀取的請求欄位。若規則所需的資料不存在，即使語法正確也不保證會命中。將資訊可見性與比對語法分開檢查，可避免反覆調整一條無從判斷的規則。

05 PROXY、DIRECT、REJECT 與比對順序

規則前半段描述「哪些請求」，末尾策略則說明「如何處理」。PROXY、DIRECT 與 REJECT 是本頁採用的基本策略關鍵字，請保留英文原文。PROXY 使用目前適用的代理路徑，DIRECT 直接建立連線，REJECT 則拒絕符合條件的請求。它們不是延遲等級，也不會依存取結果自動切換。

策略不能取代伺服器設定

PROXY 需要可用的使用者伺服器資訊與相應的選取狀態。即使規則命中 PROXY，若驗證資料、連接埠或協定參數有誤，連線仍可能失敗。DIRECT 同樣需要基礎網路能連線至目標，不代表請求一定成功。REJECT 會主動拒絕請求，適合用於明確不希望送出的請求；但若套用在重要介面，可能影響登入、同步或內容載入，請先確認其相依關係。

先命中的規則先決定策略

一般的 [Rule] 順序比對會由上而下進行，第一條符合條件的規則便會決定策略。後續規則不會因為比對更精確，就自動覆蓋前面的結果。所謂「優先順序」，首先取決於位置，而不是規則名稱看起來多專業或欄位多長。編輯規則時，應將特定例外放在寬泛條件之前，讓讀者能依檔案順序理解每次判斷。

[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 使用 DIRECT；blocked.example.com 會被 REJECT；其他符合 example.com 後綴的名稱則使用 PROXY。前述網域條件都不符合時，才會繼續檢查私有網段與 GEOIP。即使某個 example.com 解析出的位址屬於 CN，也已在較前面的後綴規則中決定策略，不會再被後續 GEOIP 改成 DIRECT。

FINAL 是預設處理，不是補丁

FINAL 沒有網域或位址條件，常見格式為 FINAL,PROXY 或 FINAL,DIRECT，應放在用來處理其他請求的位置。若把 FINAL 放得太前面，後面的普通比對項目便沒有機會生效。維護時應保留一條用途明確的最終策略，並說明選擇理由；不要同時留下多條方向不同的 FINAL，期待它們互相補足。

兩種預設方向都有明確的適用前提。FINAL,DIRECT 表示未特別指定的流量採用直連；FINAL,PROXY 表示未特別指定的流量走代理路徑。選擇時應考量既有伺服器能力、業務範圍與故障影響，不應將任何一種視為普遍正確。修改預設策略前，先測試常用服務，並確認哪些流量會因此改走其他路徑。

區分路由模式與規則策略

Global Routing 中的 Config、Proxy、Direct 是介面模式；規則中的 PROXY、DIRECT 則是設定關鍵字。兩者文字相關，但不能混為同一個設定欄位。檢查規則時，請先切回 Config；若暫時使用 Proxy 或 Direct 進行比較，請確認是否要切回原模式，避免下次測試仍處於全域模式，卻誤以為某條規則有所變更。

測試 REJECT 時尤其要控制範圍。先用自己能辨識的單一測試主機確認命中紀錄，再考慮擴大到整個後綴。不要以寬泛關鍵字一次拒絕大量請求，再用「頁面看起來好像更快」作為判斷依據。關鍵資源可能到稍後的同步、付款確認或工作階段更新才會用到，短時間內看起來正常，並不代表相依關係已完整驗證。

06 Host 與 URL Rewrite：對應與重寫

[Host] 與 [URL Rewrite] 都可能改變存取結果，但作用層級不同。Host 處理名稱對應到哪個位址；URL Rewrite 處理符合條件的 URL 如何改寫或重新導向；[Rule] 則決定請求使用哪種策略。將這三個層次分開理解，才能判斷為何頁面目標改變、憑證發生錯誤，或分流條件沒有如預期出現。

Host：指定主機名稱的解析結果

example.com = 192.0.2.10 表示為該名稱指定位址。這不代表存取網域會變成這個數字位址，也不會自動變更 HTTP Host、TLS 使用的服務名稱或遠端憑證。伺服器仍須能正確處理原本的名稱。若只填入一個可連線的 IP，但對端沒有提供該網域的服務，可能會顯示錯誤頁面或憑證不相符的提示。

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

範例中的兩個對應彼此獨立，不應假設根網域項目會自然涵蓋所有子網域。若要指定多個名稱，應分別確認各自的目標與用途。對應位址應來自自己可管理且能驗證的環境；若長期將經常變動的公用服務固定到舊位址，可能會讓原有的負載分配與故障轉移失效。

Host 常用於自有測試環境，或明確的名稱解析修正，不適合用來試探未知位址。疑難排解前，先從工作副本中移除或停用相關對應，並與系統解析結果比較。若恢復一般解析後連線正常，接著檢查對應目標是否過期、連接埠是否開啟，以及憑證名稱是否正確；不要直接新增更多代理規則。

URL Rewrite：以有限範圍指定目標變更

URL Rewrite 的常見格式包含比對模式、替換目標與處理方式。以下範例示範將 example.com 的 HTTP 位址重新導向至對應的 HTTPS 位址。這裡僅說明格式；實際部署前，應確認目標服務支援 HTTPS，且重新導向不會與伺服器現有邏輯衝突。使用實際業務位址時，請先在工作副本中以單一入口測試。

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

比對部分將句點寫成 \.，是為了將它限定為字面上的句點。若直接寫成 example.com，正規表示式中的句點可能代表任意字元，導致比對範圍擴大。開頭的 ^ 限定從字串起始位置比對，網域後的斜線也有助於限定主機邊界。重寫規則應盡可能精確描述目標，不要用過於寬泛的運算式涵蓋所有請求。

重寫不代表能通用修改加密內容

用戶端能否讀取完整 URL，取決於請求形式與可見資訊。HTTPS 路徑通常位於加密層中，不能假設加入 URL Rewrite 後就能比對任何 HTTPS 路徑。外層可見的連線目標與完整 HTTP 請求並不相同。若只需要變更連線策略，請回到 [Rule] 使用網域或位址條件，不必引入請求內容處理。

本頁不將擴大憑證信任或解密範圍列為基礎設定步驟。若功能需要額外的請求可見性，請先了解其權限界線與適用對象，再依 App 內說明判斷。不要為了修復一般連線失敗而加入來源不明的憑證，也不要把服務驗證失敗誤認為 URL Rewrite 能力不足。

重新導向循環與重複條件

若一條規則將位址 A 改成 B，另一條規則或伺服器又將 B 改回 A，就可能形成重新導向循環。瀏覽器不斷跳轉或提示重新導向次數過多時，應逐一停用重寫規則，並記錄每次 Location 的變化。單純切換 PROXY 與 DIRECT 可能改變連線狀況，卻無法修正目標彼此指回的邏輯問題。

組合維護時，先驗證一般 DNS 與路由，再啟用 Host，最後單獨啟用重寫。若同時修改三個層次，就很難判斷最終位址來自解析、重新導向還是頁面本身的請求。請為每項變更記錄用途與復原方式，測試結束後移除暫時性對應，避免日後誤將測試項目當成長期業務需求。

07 常見規則組合與設定維護

設定是否容易維護，不在於規則數量多寡，而在於能否用少量條件說明每個請求的處理結果。開始組合前，先確認預設方向：大部分請求直連、只有指定網域使用代理；或大部分請求使用代理、只保留明確的直連例外。這項決定會反映在 FINAL，接著再依比對範圍由小到大，將具體例外放在前面。

組合一：直連為預設，指定網域使用 PROXY

以下設定用來說明「只有特定名稱使用代理路徑」的結構。api.example.com 是精確的直連例外，其他符合 example.com 後綴的請求使用 PROXY，其餘請求則由 FINAL,DIRECT 處理。重點不在範例網域本身，而在例外、網域集合、區域網路與預設處理之間的排列順序。

[General]
bypass-system = true
dns-server = system

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

若目標服務實際使用其他獨立網域，這份範例不會自動辨識它們。新增條件應以請求紀錄為依據，不要只把服務名稱當成關鍵字，就一次涵蓋所有名稱相似的主機。若 App 需要多個請求才能完成操作，請驗證完整流程，包括開啟、登入、讀取與提交，而不只是確認入口頁面能顯示。

組合二：代理為預設，保留明確的直連範圍

另一種結構會讓未被例外涵蓋的請求使用 PROXY。這需要使用者已有的伺服器能處理相應流量，並且清楚哪些請求仍須走本機路徑。範例保留一項網域例外與一個私有網段，再依位址分類使用 GEOIP；是否保留 GEOIP，應根據實際需求決定，而不是只因常見設定中經常出現。

[General]
bypass-system = true
dns-server = system

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

這兩份設定代表不同的維護方向，不應直接首尾相接。拼接後，第一份中的 FINAL 會先結束判斷，第二份多數項目便沒有機會生效。合併設定時，先刪除各片段原有的預設項目，整理具體規則與重複條件，最後只保留一條符合整體目標的 FINAL，並逐項驗證合併後的行為。

分開更新訂閱與設定檔

Subscribe 更新通常涉及既有伺服器清單，設定檔更新則可能變更規則、參數或策略引用。更新其中一項，不代表另一部分也已正確同步。若清單中的名稱有所變更，而自訂設定引用了特定名稱，就應確認該名稱仍然存在。本頁使用基本的 PROXY 關鍵字，是為了讓規則意義不依賴教學範例中的特定伺服器名稱。

訂閱網址可能包含存取權杖，應視為敏感資訊。分享疑難排解資料時，只保留必要的規則與目標類型，並移除完整訂閱網址、伺服器驗證欄位與個人識別資訊。若想了解分享連結與訂閱網址的差異，可接著閱讀節點連結格式說明；兩者的匯入與更新方式不同，不能只因都能複製為文字，就視為同一種項目。

儲存、切換與復原

在 Config 中編輯或匯入後，先確認檔案能正常開啟，再確認目前選取的項目。儲存並返回 Home，檢查 Global Routing 是否為 Config，接著建立新請求進行測試。若需要重新建立連線，應先結束可能受影響的操作，再依 App 目前的介面切換連線；持續中的長連線可能仍沿用原先建立時的路徑。

復原時應依據已驗證可運作的副本，而不是只說「刪掉剛才的內容」。每次修改都應記錄目的、涉及的段落、測試對象與觀察結果。若遠端設定更新覆蓋了本機修改，先還原工作副本並確認基本連線，再決定要重新合併哪些項目；不要在故障狀態下連續匯入多個來源不明的設定。

用戶端一次性買斷 ≠ 連線服務方案。Shadowrocket 的購買與使用者既有的連線服務分開管理；本站不提供、不銷售、不推薦節點或訂閱。如需確認 App 的取得管道與開發者資訊，請參閱App Store 正版核驗說明。用戶端僅於 Apple 平台發行，系統需求請以 App Store 頁面標示為準。

08 規則驗證與疑難排解流程

排查問題時，首先要區分「沒有連線」、「已建立連線但請求失敗」及「請求成功但連線方向不正確」。這三種情況需要不同的判斷依據。Home 顯示連線狀態，只表示用戶端處於相應的工作狀態，不保證每個目標都能連線；Connectivity Test 提供測試結果，也不能單獨證明特定業務請求命中了預期規則。

第一步：建立可重複的測試項目

選定一項明確操作，例如開啟自己已知的測試頁面，並記錄目標主機名稱、目前網路與失敗現象。每次只執行這一項操作，以減少背景請求干擾。若問題只在登入或上傳時出現，就測試該步驟，不要只反覆重新整理首頁。不同階段可能連線到不同目標，首頁成功不能取代後續介面的驗證。

接著記錄目前使用的檔案、Global Routing、伺服器選擇與最近一次修改。若問題在切換網路後出現，請分別在原網路與新網路重測。尚未保存證據前，不要連續重新安裝或重設所有設定；這會清除可用來解釋問題的狀態，使原本只是「某條規則有所變動」的問題，變成大範圍的重新設定。

第二步：確認設定是否參與判斷

檢查 Config 中實際選取的檔案，確認編輯內容已儲存，再檢查 Home 的 Global Routing。若目前仍是 Proxy 或 Direct，測試結果只能用來比較全域路徑，不能據此判定 [Rule] 中的某項條件失效。切回 Config 後建立新請求，確認目標、命中條件與策略是否符合檔案中的順序。

Global Routing: Config
Config: 目前的工作副本
Target: api.example.com
Expected Rule: DOMAIN,api.example.com,DIRECT
Expected Policy: DIRECT

這是紀錄格式，不是用戶端執行紀錄。實際結果應以本次測試為準，不要把預期值當成觀察結果抄下來。若紀錄中找不到目標請求，請檢查測試是否沿用了既有連線、目標是否被其他全域條件提前略過，以及觀察時間是否對應剛才的操作。

第三步：依症狀縮小範圍

命中錯誤規則時，先找出前面第一條符合條件的規則。常見原因包括 DOMAIN-KEYWORD 範圍過大、後綴規則排在精確例外之前，以及 FINAL 出現在檔案中段。調整順序後重新發送請求，不要繼續在檔案末尾新增重複規則；已由前面條件處理的請求，不會因此重新判斷。

命中正確策略但連線失敗時，請改為檢查該路徑所需的條件。PROXY 應檢查使用者已有伺服器的位址、連接埠、協定與驗證資訊；DIRECT 應檢查基礎網路與目標連線狀況；REJECT 則先確認拒絕是否符合維護者的原意。若是驗證失敗，新增網域規則通常沒有幫助；若目標已被拒絕，更換 DNS 也不會讓它自動改用其他策略。

第四步：區分快取、舊連線與設定錯誤

網域解析結果與既有連線可能暫時沿用先前的狀態。修改規則後，優先用可控制的新請求驗證；必要時依 App 提供的操作重新建立連線，再檢查結果。不要把每次快取變化都解讀成設定隨機生效。記錄「修改前、儲存後、新請求後」的觀察結果，有助於區分編輯問題與連線生命週期。

若只有特定 App 發生問題，請檢查它是否使用獨立網域、不同位址類型或特殊傳輸方式。測試頁面成功，不代表所有協定路徑都可用；延遲數字也不等同於完整的使用體驗。如需了解測試結果與伺服器選擇，可閱讀延遲測試與節點判斷方法，並以自己已有的清單作為測試範圍。

第五步：整理出可供複查的結論

排查結束後，保留最精簡的有效修改，並將測試期間暫時切換的 Global Routing 恢復原狀。結論應說明是哪項條件導致問題、修改了哪一行、如何驗證，以及如何復原。若仍無法確定原因，請保存已去識別化的設定片段與實際現象，繼續查閱常見問題；若要重新進行首次授權與匯入流程，請返回快速入門教學。