Shadowrocket
規則與設定檔參考

01 · 設定檔結構與編輯注意事項

開啟 Config，先確認目前選取的設定檔，不要只看清單中最近匯入的檔案。進入該檔案的編輯畫面，確認看得到設定區段與現有規則後再開始修改。儲存後返回清單，確認選取標記仍指向這份檔案；若修改的是另一份副本，即使內容完全正確，目前的連線也不會套用該副本。Config 管理的分流設定與 Home 中的伺服器清單用途不同，不能視為同一份資料。

各設定區段的用途

Shadowrocket 的文字設定以方括號區段名稱編排，區段名稱獨占一行，後續內容都屬於該區段，直到出現下一個區段為止。General 放置基本行為參數，Rule 放置依序檢查的條件，Host 用於指定主機名稱與位址的對應，URL Rewrite 則放置請求網址改寫或重新導向規則。不要只因某一行看起來像網域就放進 Host；先判斷這一行是用來決定路徑、指定解析結果，還是改變請求網址。

以下是用來說明結構的最小範例，只展示基本參數與 Rule，不含伺服器設定，也不能取代你的完整設定。PROXY 是否有可用目標，仍須在 Home 確認。範例網域僅供說明；實際驗證時，請改用自己有權測試且清楚其存取結果的目標，不要反覆開啟範例網址來判斷伺服器是否正常。

[General]
dns-server = system

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

保留原始檔案，再建立測試副本

編輯前，先匯出或複製目前可用的設定，並為副本取一個容易辨識用途的名稱。備份至少應能還原原有的 General、Rule 與自訂 Host 內容，也要另外確認伺服器清單是否已儲存。匯出內容可能包含訂閱網址或驗證資訊，不要直接將整份檔案貼到公開討論區。需要求助時，只保留相關規則、已遮蔽的目標資訊及實際錯誤狀況。

判斷欄位是否可用，應一併檢查儲存結果、App 內編輯器說明與請求記錄。保留英文半形逗號、等號與區段名稱；中文標點、不可見空白，或從排版文件複製的特殊引號，都可能使設定無法如預期解析。若剛儲存就出現錯誤，先復原最後一次修改，再逐行還原；不要同時改寫多個設定區段碰運氣。

分清訂閱更新與設定更新

既有訂閱通常用來更新伺服器項目；遠端設定則可能更新分流規則或基本參數，兩者不可混為一談。更新伺服器後，Rule 不一定會改變；重新取得遠端設定後，也可能需要重新核對本機編輯內容。先確認更新入口的位置、遠端內容類型與儲存目標，再決定是否操作。訂閱網址請向你的服務商取得；本頁不提供網址，也不評價任何服務商。

若 App 內的編輯畫面與本文範例不完全相同，請以目前欄位說明為準，並先保留原有可用參數。系統需求請以 App Store 頁面標示為準；App 更新透過 App Store 完成，不必更換整份設定檔。設定檔負責網路行為，App Store 負責取得與更新 App，兩者應分開維護。

02 · Global Routing 與比對順序

檢查規則前，先在 Home 開啟 Global Routing，確認目前使用哪種模式。Config 依設定檔分流，Proxy 讓流量走代理，Direct 則直接連線。需要依 Rule 分流時，請選擇 Config，再發出新的請求並查看記錄。只在 Config 編輯規則，卻維持 Proxy 模式，接著發現所有請求仍走代理，不能據此判定 Rule 語法有誤；路由模式會決定這些規則是否參與目前的判斷。

先命中不等於「最長規則優先」

閱讀 Rule 時，應由上往下檢查；第一條符合條件的規則會決定這次採用的策略。後面的規則即使描述得更精確，也不會自動推翻先前的命中。將精確網域規則放在較寬泛的後綴規則前面，是手動安排優先順序，不是程式自動排序。調整時要檢視整段內容，不能只確認想用的規則「已經寫在檔案裡」。

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

在這段範例中，api.example.com 會先命中第一行；其他屬於 example.com 的子網域才會繼續比對第二行。若調換前兩行，api.example.com 會先符合後綴條件，精確網域規則就沒有機會參與判斷。排查這類問題時，記下目標主機名稱、第一條命中的條件與最終策略，再依順序往前找涵蓋範圍較大的規則。

FINAL 處理其餘請求

FINAL 不需要再填入網域或位址參數；它負責處理先前都未命中的請求，因此應放在 Rule 最後。它不是「失敗後自動切換」的指令，也不會檢查代理是否能連線。FINAL,PROXY 表示將剩餘請求交給 PROXY；若 PROXY 對應的伺服器無法使用，請求仍可能失敗，FINAL 不會自動修復故障路徑。

不要在中間放置 FINAL，再把例外規則寫在它後面。中途的兜底規則會先接收剩餘請求，後續項目即使成功儲存，也無法實現預期的例外。同樣不建議保留多條互相矛盾的 FINAL 作為備援方案。先決定剩餘請求應走哪條路徑，再用一條清楚的結尾規則表達。

記錄中的位址不一定是最初存取的網域

開啟一個網頁時，可能會產生主頁、圖片、API 與資源檔等多個連線。只看到其中一筆 IP 請求走了 PROXY，不能據此認定主網域規則失效。請在 Data 的請求或連線記錄中，找到與測試時間及目標主機名稱相符的項目，再檢查比對資訊。若記錄只顯示目標 IP，還需確認請求是否帶有網域資訊，以及是否沿用既有長連線。

儲存規則後，既有連線可能繼續使用先前選定的路徑。建議依序儲存設定、確認選取的檔案、重新建立連線，再觸發目標請求；必要時關閉相關 App 後重新開啟。不要只是不斷重新整理同一頁面，因為快取可能讓畫面看似更新，實際上卻沒有產生要觀察的新連線。測試結論必須對應一筆可辨識的新請求。

03 · DOMAIN 系列規則寫法

先從請求記錄複製實際主機名稱，再選擇比對方式。網域規則的條件欄不填完整 URL，也不附上 https://、路徑、查詢參數或連接埠。例如目標是 https://api.example.com/status，DOMAIN 的條件應填 api.example.com，而非整段網址。若要依路徑區分，屬於另一種需求，不能把路徑接在 DOMAIN 後面達成。

DOMAIN：只比對指定主機名稱

DOMAIN 適合單獨處理明確的主機名稱。DOMAIN,example.com,DIRECT 不會因為文字相同就自動涵蓋 api.example.com，也不會包含名稱中有 example 的其他網域。若要為登入 API、更新入口或某項內部服務設定例外，先確認實際主機名稱，再使用精確比對。若服務使用多個主機名稱，請逐一記錄，不要假設一次存取只對應一個位址。

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

這段範例明確列出兩個主機名稱，再為其餘後綴設定預設處理方式。login.example.com 的精確規則與後綴規則目前都指向 PROXY，看起來重複，但在維護時能標示這是需要特別留意的入口；若沒有這種維護需求，刪除策略相同的冗餘項目會讓設定更容易閱讀。精簡前仍應確認沒有其他依賴順序的例外。

DOMAIN-SUFFIX：依網域層級涵蓋

DOMAIN-SUFFIX,example.com,PROXY 用來比對 example.com 及其子網域。它依網域邊界判斷，不是任意文字包含關係：api.example.com 屬於這個範圍，notexample.com 則不屬於。條件通常直接填 example.com，不要自行加上星號，也不要把它當成正規表示式。若要縮小範圍，可填 api.example.com 作為後綴，並明確決定是否要涵蓋其下層主機名稱。

後綴規則可涵蓋同一服務網域下的多個入口，但同一網頁的資源不一定都在同一個網域。若登入正常、圖片卻載入失敗，應檢查圖片請求的實際網域，而非一再擴大主網域規則。簡單地把所有觀察到的網域合併成一個過於寬泛的關鍵字，可能會影響原本無關的請求。先整理失敗項目，再決定要新增精確規則或另一個明確的後綴規則。

DOMAIN-KEYWORD：比對範圍通常比預期更廣

DOMAIN-KEYWORD 會比對網域文字中的關鍵字，不要求關鍵字剛好是完整的網域標籤。DOMAIN-KEYWORD,example,PROXY 可能同時命中多個彼此無關、但含有這段文字的網域。只有在明確需要這種廣泛比對時才適合使用，不應用來取代所有 DOMAIN-SUFFIX。排查時，優先將寬泛關鍵字縮小為實際觀察到的主機名稱，以減少誤比對造成的干擾。

規則條件中不要加入中文註解、末尾多餘逗號，或從瀏覽器複製來的句尾標點。策略應放在規定的最後欄位，說明文字則另起一行，避免被誤認為欄位內容。若設定編輯器支援分別填寫類型、條件與策略，逐欄輸入通常比直接貼上長行更容易找出錯誤；儲存後仍應回到文字檢視確認結果。

分開驗證比對範圍與策略效果

測試網域規則時，先保持策略不變，只確認目標是否命中該規則；確認條件正確後，再更改 PROXY 或 DIRECT。如此才能分辨「沒有比對到」與「已比對到但連線路徑失敗」。若同時更換條件、伺服器與 DNS，無論成功或失敗，都無法確認是哪項修改造成，也會讓後續復原失去明確依據。

04 · IP、GEOIP 與 USER-AGENT

網域條件無法涵蓋所有請求。有些 App 會直接連線到 IP 位址，有些連線記錄則沒有可供規則使用的主機名稱；這時才需要搭配 IP-CIDR、IP-CIDR6 或 GEOIP 判斷。先確認實際目標位址與位址家族，再選擇條件。不要只根據瀏覽器網址列推斷底層連線一定帶有網域，也不要把單一位址規則當成對整個網站永久有效的身分識別。

IP-CIDR：位址與前綴長度

IP-CIDR 的條件由網路位址和斜線後的前綴長度組成。192.168.0.0/16 表示一個位址範圍，192.168.1.20/32 則只涵蓋一個 IPv4 位址。前綴數字越大，涵蓋範圍通常越小。規則涵蓋的是連線目標位址，不是目前 iPhone 的本機位址；若要讓某台內部裝置直連，應填入該裝置所在的目標範圍，而非任意複製裝置本身的位址。

[Rule]
IP-CIDR,192.168.1.20/32,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR6,fd00::/8,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

範例先列出單一內部位址，再列出較大的私人位址範圍，方便日後新增例外。實際環境可能使用其他內部網段，應以網路設定及管理員提供的資訊為準。將私人位址設為 DIRECT，只代表在路由層選擇直連，不會自動取得存取權限；裝置仍須連上可到達該網段的網路，目標服務也必須監聽相應連接埠並允許存取。

IP-CIDR6 與 IPv6 排查

IP-CIDR6 用於 IPv6 位址範圍。範例中的 fd00::/8 只示範一種本機位址範圍寫法，不代表所有 IPv6 位址都應直連。若同一主機名稱同時回傳兩類位址，只設定 IPv4 規則可能無法涵蓋實際使用的 IPv6 連線。先從記錄確認連線使用哪一類位址，再決定是否新增規則；不要把停用整個位址家族當成一般修復方式。

部分 IP 類規則可使用 no-resolve 參數，避免只為檢查該規則而主動解析網域。它的用途是限制比對過程觸發的解析，不是取消請求所需的所有 DNS 行為。若請求仍只有網域、沒有可用的目標 IP，這類規則可能不會如預期命中。使用前請確認目前的編輯器支援此參數，並分別驗證使用與不使用參數的結果。

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

GEOIP 依據位址資料庫，不依據語言

GEOIP,CN,DIRECT 表示依目標 IP 的地理歸屬分類選擇 DIRECT，不是依頁面語言、網域後綴或使用者所在地分類。網域可能使用分散式位址，資料庫的歸屬資訊也可能有差異，因此不能據此推斷服務營運地點或保證連線速度。若只有少數明確服務需要設例外，通常將已驗證的 DOMAIN 規則放在前面，比擴大整類 GEOIP 條件更容易維護。

網域規則與 GEOIP 同時存在時，順序仍然重要。前面的網域條件一旦命中，後面的位址歸屬不會自動重新選擇策略。若記錄顯示請求套用了 GEOIP，先確認前面的網域條件是否涵蓋實際主機名稱，再檢查目前連線是否保留網域資訊。只更新位址資料庫而不核對請求對象，可能無法解決問題。

USER-AGENT 不能取代 App 識別

USER-AGENT 會依據可取得的請求標頭欄位進行比對，例如 USER-AGENT,ExampleClient*,PROXY 展示了含萬用字元的條件寫法。它不是依 App 名稱分流，也不保證所有連線都能讀取這個欄位。許多加密請求的標頭無法直接取得，不應為了這類規則就貿然啟用解密。若記錄中沒有可比對的欄位，應優先尋找明確的網域條件，並保留 FINAL 處理其餘請求。

05 · PROXY、DIRECT、REJECT 與協定參數

規則前半段回答「哪些請求」，末尾的策略則說明「如何處理」。PROXY、DIRECT、REJECT 是常見的三種策略關鍵字，大小寫與拼字都應維持一致。不要混淆策略名稱與伺服器協定：Shadowsocks、VMess 或 Hysteria2 說明伺服器連線使用哪種協定，並不是能在 Rule 中直接取代 PROXY 的通用動作。先確認條件命中，再沿著策略指向檢查實際連線目標。

PROXY 與 DIRECT 的適用範圍

PROXY 通常會將請求交給目前選取的代理；實際目標還要視 Home 的選擇，以及設定檔中是否有策略群組而定。DIRECT 則使用直連路徑，但不代表可以略過網路環境、系統權限或解析程序。某個目標能直連，不代表代理參數正確；代理能連線，也不代表所有內部位址都適合交由代理處理。請依服務所在位置與自己的使用目的選擇。

若目前設定檔包含具名策略群組，規則末尾也可能引用群組名稱；此時要確認群組確實存在、名稱完全一致，且群組內有可用成員。不要從其他檔案複製群組名稱後，就假定它會自動建立。本文範例統一使用基本策略，方便獨立閱讀；若你的完整設定使用群組，請保留原有結構並據此安排例外規則。

REJECT 表示主動拒絕請求

REJECT 用於明確拒絕符合條件的請求，不是「測試失敗後改走其他伺服器」。只有在確定目標應被阻擋時才使用。若不小心將登入所需網域設為 REJECT，App 可能會一直等待、按鈕沒有反應或部分資源缺漏，不一定會清楚顯示拒絕訊息。排查時先找出遭拒絕的項目，確認條件是否過於寬泛，再決定刪除或縮小範圍。

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

這組規則以三種不同主機範圍示範處理方式，不是建議將真實登入網域加入拒絕清單。blocked.example.com 先被拒絕，internal.example.com 設為直連，其餘 example.com 子網域則交由代理。只要順序不同，結果也可能改變。為每個例外保留簡短的維護說明，記下設定原因，會比累積大量無法解釋的拒絕規則更容易長期管理。

僅核對自己已有的多協定參數

匯入伺服器後，先確認協定類型，再核對位址、連接埠與驗證欄位。Shadowsocks 的加密方式與密碼、VMess 和 VLESS 的身分欄位，以及 Trojan 的密碼與 TLS 設定，各有不同用途，不能只因欄位位置相似就互相替換。優先使用你自己的服務商提供的完整參數；若資訊缺漏，請向提供方確認，不要自行猜測。

TLS 相關連線失敗時，應檢查伺服器名稱、憑證條件與系統時間，不要將略過憑證驗證當成預設排錯方式。Hysteria2 的使用情境還需留意 UDP 是否實際可達；單次測試有回應，不代表所有傳輸方式都正常。不同協定應分別驗證成功條件，不能以一台伺服器的結果推定另一台設定正確。

若 PROXY 請求失敗而 DIRECT 成功，請記錄所選伺服器、協定類型與失敗階段，再回到 Home 檢查對應項目。若所有目標都無法透過同一台伺服器存取，應優先排查伺服器與網路，而非替每個網站新增規則。若只有單一目標失敗，再檢查該目標是否涉及額外網域、特殊連接埠或伺服器端存取限制。

06 · General、DNS 與 Host 對應

DNS 負責將主機名稱解析為可連線的位址，Rule 則決定如何處理請求。兩者彼此相關，但功能不同。網頁無法開啟時，先確認是否取得位址，再看連線到哪裡，最後檢查採用的策略。只修改 DNS 無法修復密碼錯誤，只修改 PROXY 也無法保證不存在的網域能解析。分階段記錄故障狀況，可避免反覆測試無關欄位。

dns-server 與系統解析環境

General 中的 dns-server = system 表示使用系統提供的解析設定，是理解欄位用途的基本範例，不是適用所有網路的通用建議。系統解析環境會隨 Wi-Fi、行動網路及網路管理設定而變化。修改設定檔的解析選項前，先記錄目前使用的網路與既有 DNS 設定；日後切換網路發現結果不同時，才有原始條件可供比較。

[General]
dns-server = system

[Host]
lab.example.com = 192.168.1.20

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

這段範例將 lab.example.com 指向內部裝置，並設定該網域直連。只有在你確實管理該名稱與裝置的測試環境中才適用。Host 負責位址對應，DOMAIN 負責選擇策略；少了後者，請求仍可能依其他 Rule 走代理。反過來說，只設定 DIRECT 而沒有正確解析，主機名稱也不一定會指向該裝置。

Host 不會變更憑證與服務身分

將主機名稱對應到指定 IP 後，存取時使用的名稱通常仍是原本的主機名稱。HTTPS 服務必須提供與該名稱相符的憑證，伺服器也可能依主機名稱選擇網站。不要因為 IP 位址能開啟某個頁面，就認定替它新增任意 Host 都能正常存取。位址可達、憑證相符、網站設定正確，是三個各自需要成立的條件。

Host 不適合長期固定指向使用動態位址的公用服務。服務更換入口後，舊對應可能仍將請求送往已失效的目標，造成「其他裝置正常，只有目前裝置失敗」的狀況。排查時檢查是否有遺留對應，暫時移除後重新建立連線再比較。若對應用於內部裝置，也要確認其位址是否因網路重新分配而改變。

分辨 DNS 快取與連線重用

修改對應後，舊的解析記錄或連線可能繼續影響觀察結果。先儲存檔案、確認選取的設定檔，再重新連線並發出新請求；必要時，透過 App 提供的入口清除相關快取。不要因為「頁面仍顯示舊內容」就直接認定 Host 沒有生效，頁面快取、伺服器快取與連線重用都可能保留舊結果。應優先依據新記錄中的目標位址判斷。

若記錄中看不到網域對應的位址，先在目前網路確認該名稱能否解析，再檢查是否拼寫錯誤、依賴內部解析，或使用 App 自己的解析機制。部分 App 的請求方式可能無法完整呈現一般網域資訊，不能因此推斷所有 DNS 都已繞過設定。將測試縮小到一個可重現的目標，比同時測試多個頁面更容易確認適用範圍。

逐項核對 General 參數

General 也可能包含與系統流量處理、例外範圍或位址家族相關的參數。不要把它們當成一組「最佳化開關」直接貼上。以現有檔案為基準，先查明欄位用途，再確認它與 Rule 的關係；若某個參數影響流量接管範圍，單純新增 Rule 未必能抵銷其效果。每次只修改一項，保留修改前的值與對應現象，確認後再處理下一項。

使用加密 DNS 等解析方式時，也要考慮解析請求本身如何抵達目標，以及是否形成連線依賴。若代理伺服器位址仍需解析，而解析器又只能透過這條代理連線，啟動時可能出現彼此等待。遇到這種情況，先還原已知可用的基本設定，再依序建立解析與連線；不要靠堆疊更多解析位址來掩蓋根本的依賴問題。

07 · URL Rewrite 的用途與限制

先釐清要改變的是存取路徑還是請求網址。將 example.com 交由 PROXY 處理屬於 Rule；將舊入口轉到另一個 URL，才可能需要 URL Rewrite。兩者不是可互相取代的設定區段，也不是將 URL Rewrite 放在 Rule 前面就能提高分流優先順序。它們處理不同問題，驗證時應分別觀察路由結果與網址變化。

從可控的 HTTP 入口開始

URL Rewrite 通常由比對運算式、目標網址與處理動作組成。以下使用 HTTP 重新導向至 HTTPS 的範例說明結構；測試前請確認你能管理對應目標，並以目前編輯器支援的動作與語法為準。運算式中的反斜線用來將句點視為一般字元，括號會擷取路徑部分，目標中的 $1 則引用第一個擷取群組。

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

這一行會從 URL 開頭比對 http://example.com/，將後續內容帶入目標網址，並以 302 表示暫時重新導向。它不會讓目標伺服器自動支援 HTTPS，也無法修復目標憑證。若目標網址本身無法存取，重新導向只會把請求帶往另一個失敗的地方。應先直接驗證目標 URL，再測試來源 URL 是否會轉向該目標。

正規表示式必須限制比對範圍

正規表示式中的句點預設可比對其他字元，省略跳脫可能擴大比對範圍；開頭錨點則能避免在任意位置誤比對。條件若只寫很短的關鍵字，通常難以界定允許處理哪些 URL。建議從完整協定、明確主機名稱與必要路徑開始，確認效果後再考慮擴大範圍；不要先寫寬泛條件，再逐一排除誤命中。

URL 可能帶有查詢參數、編碼字元與不同路徑形式。範例中的擷取群組會保留斜線後的內容，但不代表所有複雜網址都適合直接拼接。登入回呼、帶簽章的請求，或依賴參數順序的 API，改動任何部分都可能造成驗證失敗。遇到這類目標，請先確認協定約定，不要把能開啟一般網頁的運算式直接套用到驗證流程。

避免重新導向迴圈與請求語意改變

新增規則後，檢查目標網址是否會再次符合同一條規則，或被另一條規則改回原網址。若頁面反覆跳轉、網址不斷切換或請求數持續增加，應先停用新增規則並保留記錄。多個入口彼此雙向改寫，很容易形成迴圈；維護時請寫清楚來源條件、目標網址與預期終點，不要只看單行文字判斷是否正確。

重新導向也可能影響請求方法、本文或驗證標頭的處理方式，實際結果取決於動作及發出請求的 App。不要把瀏覽器中一次成功的 GET 測試，當成 API 的 POST 請求也會維持相同行為。對於表單提交、付款或身分驗證等請求，除非清楚了解服務協定，否則應保留原始請求，不要透過通用規則大量改寫。

HTTPS 可見性與憑證限制

一般加密連線不會將完整 URL 路徑直接提供給一般路由判斷。需要讀取 HTTPS 內容的功能涉及額外的解密與信任條件，不能因為設定了 URL Rewrite 就假設這些條件已經成立。本頁範例從未加密的 HTTP 入口開始，不需要為了驗證規則而新增受信任的憑證。若只需依網域分流，使用 Rule 即可。

不要把憑證信任步驟當成修復所有改寫問題的通用方法。先確認測試請求是否能被讀取、運算式是否符合、動作是否受支援，以及目標是否可達，再判斷此功能是否適合目前需求。不同 App 也可能主動驗證憑證或固定存取邏輯；若遇到失敗，應停止擴大改寫範圍，而非不斷降低驗證條件。

驗證完成後，保留數量最少但必要的規則，並記錄每條規則的用途與測試入口。網站本身可能已設定重新導向，重複新增本機改寫只會增加維護層次。若刪除規則後存取結果完全相同，請檢查是否由伺服器端或瀏覽器快取完成跳轉。確認功能由哪一端處理後再決定是否保留，可減少日後搬移設定時的隱性依賴。

08 · 設定驗證、On Demand 與維護流程

驗證前，先寫下一句可供測試的目標，例如「api.example.com 的新請求應命中 DOMAIN 並走 DIRECT」。接著記錄目前網路、Global Routing、選取的設定檔與伺服器，再進行一次存取。成功與否不應只看開關顏色，而要確認請求命中結果符合預期，且目標服務回傳合理結果。若路由判斷正確但伺服器連線失敗，處理方向與規則未命中不同。

依失敗階段排查，不要接連疊加修改

第一步檢查系統網路能否正常使用，第二步確認連線開關及 VPN 設定授權，第三步檢查伺服器，第四步查看規則。若曾拒絕新增 VPN 設定的授權，或相關設定已被刪除，請回到首次連線流程重新處理，不必先修改 Rule。系統提示的說明請參閱新增 VPN 設定與系統權限說明。

Connectivity Test 可協助觀察伺服器回應，但不能取代實際服務請求。測試失敗時，核對位址、連接埠、協定與目前網路；若測試有回應但網頁無法開啟，再檢查 DNS、TLS、規則與目標本身。不同測試方式驗證的層級可能不同，不宜將單次結果視為整條存取路徑的保證。可參閱連線逾時排查順序繼續檢查。

On Demand 負責觸發連線，不會改變規則語意

在 Settings 檢查 On Demand 的實際條件，分清「何時建立連線」與「連線後如何分流」。On Demand 會依設定條件觸發連線，無法修復錯誤密碼，也不會重新排列 Rule。排查規則時，可先手動連線建立穩定的測試基準；確認分流正常後，再啟用實際需要的按需條件，減少自動重新連線干擾測試結果。

手動中斷後若又自動連線，先檢查 On Demand 與系統觸發條件，不要立刻認為設定檔沒有儲存。若要觀察背景耗電，應在相近網路、相近使用時間與相同伺服器下比較；不能只憑一次電量變化判斷某個開關有問題。關於常駐連線與按需使用的取捨，請參閱On Demand 與背景耗電說明。

建立可復原的驗證記錄

每次修改都記錄四項內容：原始規則、修改後的規則、測試目標與實際命中結果。若結果不符預期，立即復原這次修改，再決定下一步。不要在失敗狀態下不斷新增例外，否則即使最後恢復連線，也很難判斷是哪一行生效。與其保留大量重疊條件，不如用少量能清楚說明用途的規則逐步滿足需求。

分享排查記錄時，請遮蔽訂閱連結、密碼、身分欄位、金鑰與不宜公開的內部位址。通常只需提供相關 Rule 片段、已處理的目標名稱、命中策略及錯誤階段，不必提供整份設定檔。本頁也不要求上傳檔案或提供完整訂閱；保留最低限度的必要資訊即可說明問題。分享截圖前，也請確認沒有暴露驗證資訊。

更新後例行檢查

App 透過 App Store 更新後，先確認目前選取的設定檔仍正確，再檢查依賴的幾條重要規則。訂閱更新後，確認伺服器選擇仍有效；遠端設定更新後，確認本機例外仍位於預期位置。更換裝置或重新安裝時，App 與設定檔須分別還原；購買記錄不代表所有自訂資料都會自動還原，詳細步驟請參閱已購買項目還原說明。

需要繼續查閱時，使用本頁目錄返回相關設定區段；若要從新增伺服器開始完整操作，請前往Shadowrocket 使用指南。購買、匯入失敗或系統權限等個別問題，可依類別查閱FAQ。維護目標是讓每條規則範圍明確、每次修改都能復原，且每項結論都對應可重現的新請求，而不是讓設定檔不斷變長。