Shadowrocket 完整使用手冊

02 / FIRST LAUNCH

首次啟動：了解 VPN 設定與連線權限

先熟悉介面，再處理系統授權

請先備妥有效的伺服器資訊，再於發起連線時處理系統授權。Home 用於查看伺服器與連線入口，Config 管理規則設定，Data 用於查看流量資訊，Settings 集中常用設定。不同裝置的版面可能略有差異，請依項目名稱尋找，不必對照固定按鈕位置操作。首次開啟時清單為空，只代表尚未新增可用的連線資料。

首次啟用連線時，系統可能會要求允許新增 VPN 設定，並要求輸入裝置密碼或使用裝置提供的驗證方式確認。這是系統允許 App 建立網路延伸功能的授權步驟，不是訂閱登入頁面，也不是輸入服務商密碼的欄位。請確認提示是由目前操作觸發，且 App 名稱正確，再決定是否允許；若取消，可以先返回 App 檢查伺服器資訊。

允許新增 VPN 設定只會授予裝置端的連線權限，不會驗證遠端伺服器是否可用。即使授權成功，位址、連接埠、驗證資訊或網路條件不符，仍可能導致連線失敗。不要把完成系統授權當成連線已成功；後續還要分別驗證伺服器連線、網域解析與目標存取，三者不能互相取代。

權限不足時的排查方式

如果先前拒絕授權，下次連線時請先觀察系統是否再次顯示提示。若沒有提示且連線立即失敗，可以到系統設定中尋找 VPN 設定，確認是否有 Shadowrocket 對應項目，以及裝置是否受到組織管理限制。系統設定項目的名稱會隨系統介面而異，請以裝置實際顯示為準；不要為了尋找固定路徑而反覆變更無關權限。

裝置已有其他 VPN 設定時，請先確認目前實際連線的是哪一項。測試 Shadowrocket 前，應先結束其他正在使用的 VPN 連線，避免把系統的連線切換誤判為伺服器故障。保留設定不等於維持連線，通常不必為了測試而刪除所有設定；先中斷連線、重新確認，再明確嘗試連線一次，才能判斷是哪個步驟失敗。

相機權限僅用於掃描操作。若要使用 Scan QR Code 匯入已有的伺服器資訊，請依系統提示允許存取相機；若不使用掃描，也可以採用 App 提供的其他匯入方式。拒絕相機權限不等於拒絕 VPN 權限，也不代表伺服器無法連線。每種權限都應先確認目前功能是否需要，再決定是否授予。

首次連線前保留可復原狀態

正式設定前，先確認裝置原本能正常存取要測試的一般網頁。記下目前使用 Wi-Fi 或行動網路，以及是否連上需要網頁認證的網路。若需要網頁認證，請先完成認證再連線 Shadowrocket；否則即使 App 已取得權限，也可能因基礎網路尚未允許存取而失敗。反覆修改協定參數只會掩蓋真正原因。

初次使用建議先手動連線，暫時不要啟用複雜的 On Demand 條件。先完成「選擇伺服器、選擇路由模式、開啟連線、存取目標、關閉連線」的完整流程，確認各階段的狀況。自動連線以基礎設定正確為前提，太早啟用容易在手動關閉後再次連線，讓人難以判斷是權限問題、條件觸發，還是伺服器連線不穩。

需要截圖記錄設定或故障時，請先遮蔽密碼、訂閱連結、驗證識別資訊，以及可還原敏感資訊的 QR Code。系統提示與 App 設定可用於記錄操作階段，但分享前仍須逐項檢查內容。排查權限只需確認是否出現授權提示、是否允許，以及在哪個步驟失敗，不必公開服務憑證。完成準備後，再進入伺服器匯入章節。

04 / GLOBAL ROUTING

分流：釐清 Config、Proxy、Direct 的用途

先用三種模式決定要求的處理方向

日常規則分流請使用 Config；排查所選伺服器時使用 Proxy；與本機直接連線比較時使用 Direct。Global Routing 是 App 內的整體路由選擇，不是服務商的協定類型，也不是系統授權開關。請先確認目前選取的模式，再判斷要求為何經由伺服器或直接連線；只檢查伺服器名稱，無法判斷實際採用的路徑。

在 Config 中，規則通常依序檢查，由第一條符合的規則決定相應的處理策略。更具體的例外規則應放在可能涵蓋它的寬泛規則之前；若前面的規則都未符合，則以 FINAL 作為最後處理。以下片段用於說明比對關係，並非可直接取代所有現有設定的完整設定檔；修改前請先複製目前有效的檔案，保留原有伺服器與策略定義。

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

分別理解規則類型、策略與順序

DOMAIN 比對完整網域，DOMAIN-SUFFIX 依網域後綴比對，DOMAIN-KEYWORD 則依網域中的關鍵字比對。後綴規則適用於同一網域及其子網域採用相同策略；關鍵字規則涵蓋範圍較廣，容易連帶比對到名稱中含有相同字元的其他網域。新增規則前，請先明確界定要涵蓋的目標範圍，不要用過於寬泛的規則取代目標網域清單。

IP-CIDR 與 IP-CIDR6 分別用於對應的位址範圍，GEOIP 則依位址資料庫中的歸屬結果判斷。網域要求可能涉及解析，IP 規則也可能受到解析行為影響；範例中的 no-resolve 用於限制該規則觸發額外解析，並非通用的連線加速開關。是否符合規則取決於實際要求資訊，不能只憑網頁顯示名稱推斷。

PROXY、DIRECT、REJECT 代表不同的處理策略，不要與 Global Routing 中的介面模式混為一談。Config 中某條規則符合並採用 DIRECT，不代表整個 App 切換為 Direct；若採用 PROXY，還要檢查目前設定中的策略引用與伺服器選取。若檔案使用自訂策略組名稱，規則結尾必須引用實際存在且拼字一致的名稱。

以最小幅度修改確認規則是否生效

編輯設定時，先確認修改的是目前選取的檔案，而非同名副本。儲存後依 App 提示重新連線或重新載入設定，再發出新的測試要求。既有長連線、網頁快取與 App 快取可能仍維持原本行為，因此不要只查看已開啟的頁面；請發出一次明確的新要求，並搭配要求紀錄確認符合的策略。

目標在 Proxy 下可用、在 Config 下無法使用時，優先比較規則比對、策略組引用與 DNS 結果，不要立刻重建伺服器。若 Direct 下正常、Proxy 下異常，請回頭檢查伺服器與協定。三種模式是協助縮小範圍的比對工具，不是可以互相取代的修復按鈕；測試完成後，請切回原本需要的模式，避免臨時測試狀態變成長期設定。

規則檔也可能包含 DNS、策略組或遠端規則引用，不能只看一行 FINAL 就判斷整體行為。先用少量明確的規則建立可驗證的基準，再逐步加入例外。每次新增規則後，記錄目標、預期策略與實際比對結果，並保留可說明的變更；需要繼續排查時，帶著這三項資訊查看疑難解答，比只描述「分流不正確」更容易找出問題。

06 / DATA

Data：區分流量統計、要求紀錄與服務用量

先確認數字的統計範圍，再看大小

Data 中的流量資訊用於觀察客戶端的處理狀況，不等於既有服務的最終計費用量。查看數字前，先確認項目名稱、統計週期與目前連線狀態，弄清楚它代表上傳、下載、目前連線還是累計紀錄。不同範圍的數字不能直接相減比較，更不能只因兩處數字不一致，就判定客戶端或服務端的統計有誤。

上傳與下載是以目前裝置的角度描述資料傳輸方向。開啟頁面也可能產生上傳要求，下載內容時同樣會有協定交握，因此不能把上傳完全理解為主動傳送檔案。流量數字表示資料傳輸量，不代表每段內容都已成功顯示；連線重試、背景重新整理與失敗的要求也可能產生流量，應搭配實際存取行為判讀。

本機統計與服務端紀錄可能不同，原因包括統計時間範圍、協定額外負荷、重試處理與服務端本身的計算方式。有些要求也可能依規則直接連線，因此使用者在服務端看到的可能只有經過伺服器的部分。若要核對用量，請先統一觀察時間與連線範圍，再查閱已有服務的說明；不要把 Data 當成帳單結算依據。

透過要求資訊找出規則與解析問題

查看要求紀錄時，優先找到剛才主動發起的操作，核對時間、目標與策略。裝置在背景也會產生其他連線，清單最上方的項目不一定就是正在排查的網頁。可以先停止無關操作，再進行一次明確的測試，以縮小紀錄範圍。需要重複驗證時，請維持目標不變，避免把不同要求的結果誤認為同一個要求反覆變化。

如果紀錄包含規則符合資訊，請同時查看規則類型與最終策略。符合某條網域規則，只代表比對過程到達該規則；還要確認規則所引用的策略是否符合預期。DIRECT 紀錄不代表伺服器失效，REJECT 紀錄也不一定是連線錯誤；它們可能正是設定要求的處理方式。先比較預期，再判斷是否異常。

網域與位址紀錄也需要分開理解。同一個網頁可能存取多個網域，同一個網域也可能解析到不同位址，切換網路後結果還可能改變。只查看某個位址的歸屬，不能判定整個網頁應採用什麼規則。排查 DNS 時，應一併查看解析結果、符合的策略與目標存取情況，避免只憑單一位址就大幅修改 GEOIP 或 IP-CIDR 規則。

流量異常增加、清理與隱私界線

裝置沒有主動操作但流量仍增加時，先檢查背景同步、媒體播放、系統更新及其他正在執行的網路工作，再判斷是否與目前測試有關。可以在一段明確的短時間觀察中減少背景活動，比較開啟連線前後及不同路由模式下的結果。不要因看到流量增加就認定訂閱異常，客戶端處理的背景要求本來也會反映在統計中。

如果 App 提供清除統計或清理紀錄的操作，執行前請先保存排錯所需的範圍說明與關鍵狀況。清除本機顯示通常不等於清除服務端用量，也不會改變伺服器連線狀態。不要把清除數字當成恢復服務額度的方法。重設後以相同條件進行短時間測試，更適合觀察變化；但請記下新的觀察起點，不能再與舊的累計值直接比較。

要求紀錄可能包含存取網域、伺服器位址、時間與其他敏感欄位，匯出或截圖前請逐項檢查。分享故障資訊時，可以保留規則類型、策略名稱與錯誤階段，並隱藏個人憑證及與故障無關的存取內容。即使訂閱連結只顯示一部分，也可能包含驗證資訊；不要以為裁掉開頭就安全，分享前必須檢查完整的可見範圍。

Data 適合用來提供證據，而不是單獨下結論。將單次存取對應的網路環境、路由模式、符合的策略與結果一起記錄，通常比累積大量截圖更有效。如果紀錄與觀察不一致，先確認是否取得同一次要求，再檢查快取與長連線。整理好證據後，再到 Settings 調整相關項目，避免只憑統計變化就大幅修改設定。

08 / MAINTENANCE

維護：保留有效設定，分別管理更新與復原

App、訂閱與規則分開維護

請分開處理 App Store App 更新、Subscribe 清單更新與 Config 規則維護。App 更新會變更客戶端本身，訂閱更新會變更伺服器資料，規則更新則會變更要求的分流依據。三者可能在不同時間發生；遇到變化時，應先確認最近變更的是哪一層。不要因為訂閱更新成功就認定 App 已更新，也不要用 App 更新取代對失效資料的核對。

透過 App Store 更新前，先保存目前有效的設定，並確認已有訂閱資料可以找回。更新後，使用原本的伺服器、路由模式與測試目標重新確認；不要立刻同時匯入新規則。如果結果有變化，先記錄具體功能與失敗階段，再判斷是否與設定相容性、網路環境或伺服器狀態有關。App 更新紀錄可在商店查看，不必自行維護版本清單。

更新訂閱時，請留意項目的新增、刪除、名稱變化，以及目前選取的項目是否仍有效。更新完成後，至少驗證一部正在使用的伺服器，不要只看「成功」提示。若清單突然變空，先保留現有資料並核對連結狀態，避免反覆刪除重建。既有服務的使用期限與權限由使用者自己的服務安排決定，更新客戶端無法延長或變更。

備份不只是儲存一個檔案

備份時應區分規則檔、手動設定的伺服器參數與訂閱連結。一個 Config 檔未必包含所有伺服器資訊，一張清單截圖也無法復原驗證欄位。使用 App 提供的匯出或備份方式前，先確認實際包含哪些內容，再將必要資料保存在自己能掌控的位置。備份檔可能包含憑證，不宜放在公開連結、共用目錄或未經檢查的聊天紀錄中。

備份是否有效，要看能否復原，而不只是檔案是否存在。可以在不破壞目前有效設定的前提下，檢查匯出內容與復原入口，確認檔案可讀取、規則區段完整，且策略引用仍有對應項目。驗證備份不必先清空所有設定；先保留原設定，再用副本檢查，避免一次維護演變成重新排查所有連線問題。

換機後先從 App Store 重新取得 Shadowrocket，再處理伺服器資料與 Config。購買資格復原與本機資料復原應分別確認；使用同一個帳號取得 App，不代表每項設定都會自動出現。家庭共享、跨裝置使用與相容性條件，請以 App Store 頁面標示為準。復原後先手動連線，確認有效後再重新啟用 On Demand 等自動功能。

清理失效項目並建立可重複使用的紀錄

整理伺服器清單時，先區分暫時測試失敗與已確認不再使用的項目。網路短暫不穩造成的一次逾時，不足以判定應刪除該項目；請先更新訂閱、確認參數，再以相同條件重新測試。手動新增的項目應保留來源說明，訂閱產生的項目則要留意下次更新可能會重建。依來源整理，比只憑名稱或單次測試結果批次清理更可靠。

設定檔也應保留一份明確有效的基準。準備修改時，先複製副本並寫明修改目的，例如新增一個網域例外或調整最終策略；確認結果後，再決定是否取代原檔。不要讓多個同名副本同時被當成「目前使用的設定」，否則下次連線時容易選錯。範例中的保留位址與網域僅用於說明，不能作為實際伺服器連線資料。

故障紀錄可以簡短，但應包含網路類型、所選伺服器所屬資料、Global Routing、問題發生時間範圍、錯誤階段與最近一次變更。紀錄中不需要完整密碼或訂閱憑證。再次遇到類似問題時，先對照上次有效狀態並檢查最近變更，再依序核對權限、伺服器、解析、規則與目標存取，避免每次都從頭重設。

長期使用時，請依序檢查：基礎網路正常、資料仍有效、設定選取正確、路由符合預期、實際目標可正常存取。先確保這條流程清楚，再增加自動連線與複雜規則。需要重新依最短流程操作時，請閱讀快速上手；需要核對購買與復原方式時，請閱讀下載指南；遇到具體症狀時，請前往疑難解答依問題查閱。