Shadowrocket 完整使用手冊

先了解 Home 與設定之間的關係

首次開啟後，先分清三個項目：Home 中可選取的伺服器、Config 中使用的規則設定，以及建立系統連線的總開關。伺服器決定要求交由哪個遠端處理；規則設定決定各項要求採用何種策略；總開關則決定網路延伸功能是否正在執行。三者彼此相關，但不能互相取代。清單中有伺服器，不代表規則設定已經合適；有規則檔案，也不代表伺服器憑證正確；開啟開關後，仍須透過實際連線確認結果。

首次啟動時，App 可能會等到首次使用相關功能時才要求權限，不一定一次顯示所有提示。請先閱讀目前提示所說明的用途，再決定是否繼續。相機權限通常用於掃描 QR code；通知權限與 App 通知有關；系統 VPN 設定授權則用於建立連線。若只匯入文字連結，不必為了完成同一項工作而主動開啟相機權限。未使用的功能可等到真正需要時，再依系統流程授權。

了解系統 VPN 設定授權

首次嘗試建立連線時，系統通常會要求允許新增 VPN 設定，並可能要求驗證裝置身分。這是系統登錄網路延伸設定的步驟。請先確認要求來自目前操作的 Shadowrocket，再依系統提示處理。授權成功只代表系統允許該設定執行，不表示網路中的每個要求都一定會轉送，也不代表已連線的伺服器能存取所有目標；實際處理方式仍取決於 Global Routing、規則與遠端服務。

若先前取消了系統提示，確認伺服器資訊後可再次嘗試建立連線，並依實際出現的授權流程繼續。若始終無法建立設定，先檢查裝置是否受組織管理、是否有相關功能限制政策，以及是否有其他網路設定正在生效。受管理的裝置應遵循管理規範，不要把管理限制當成一般連線問題。請勿接連刪除多項系統設定來碰運氣；先記下現有設定所屬的 App 與用途，以免影響原有的工作網路。

分開判斷系統狀態與 App 狀態

系統顯示 VPN 狀態，代表相應的網路延伸功能處於連線狀態，但不能證明目標網頁已成功載入。反過來說，部分裝置的狀態列空間有限，沒有持續顯示某個標記，也不能單獨證明連線已中斷。請一併查看 App 中的開關狀態、目前選取的伺服器與實際存取結果。若從系統設定中斷連線後又自動連線，請檢查 On Demand 等觸發條件，不要因開關恢復就認定系統未接受操作。

變更伺服器、路由模式或規則設定後，現有連線可能仍沿用先前的路徑。首次驗證時，建議先停止目前的存取，再視需要重新建立連線，然後重新開啟目標頁面。不要在保留舊連線的情況下同時修改多項設定，再只憑頁面是否仍在播放來判斷新設定。若目標 App 需要登入，也要考慮 App 快取與工作階段恢復的影響；必要時先結束目標 App，再重新存取。

權限檢查回答的是「系統是否允許功能執行」；連線檢查則要確認「目前的伺服器、驗證參數、規則與目標服務是否正常」。請分別記錄這兩項檢查結果。

建立可復原的初次操作基準

匯入前，記下目前使用 Wi-Fi 還是行動網路，並確認一般網路本身可以正常使用。需要先通過網頁認證的 Wi-Fi，請先完成認證再測試連線。初次設定期間先不要啟用自動觸發規則，才能清楚掌握每次連線是由哪項手動操作啟動。如果裝置上還有其他會改變網路路徑的功能，也請記下其狀態，避免把多種機制同時生效的現象歸因於單一設定。

建議準備一份只供自己查閱的操作紀錄，記下目前使用的伺服器名稱、設定名稱、Global Routing 模式與本次修改內容，但不要記錄完整密碼或訂閱憑證。首次連線成功後，這份紀錄就是復原基準。若尚未匯入任何服務資訊，停留在本階段是正常情況；請接著閱讀下一章，新增自己已有的資訊。若想依較精簡的步驟操作，可返回入門指南；完成授權後，再回本頁查閱各項設定的適用範圍。

區分路由模式與規則策略

Global Routing 決定要求以何種方式處理。Config 依照目前設定中的規則比對；Proxy 讓用戶端處理範圍內的要求採用代理路徑；Direct 則採用直連路徑。它們是不同的運作模式，不是三台不同的伺服器。切換模式不會修正錯誤密碼，也不會延長現有服務的有效期限。特別是 Proxy，不應簡單理解為裝置上的所有通訊都一定會經過遠端；系統網路行為、處理範圍與協定能力仍各有不同限制。

規則中的 PROXY、DIRECT 與 REJECT 是策略關鍵字，不能與 Global Routing 介面上的文字混為一談。規則中的 PROXY 也必須搭配目前的選取項目及設定中的策略定義來理解。若設定使用自訂策略群組，規則末尾可能會引用群組名稱，而非固定寫成 PROXY。初次了解設定時，請先確認現有設定的引用關係，不要只更改規則末尾的文字，就以為策略調整已完成。

由上往下比對，FINAL 放在末尾

在 Config 模式下，規則會由上往下依序檢查，命中後採用相應策略。越具體的例外規則通常越應放在相關的廣泛規則之前；否則前面的規則一旦命中，後面的例外就不會執行。FINAL 用來處理前面都未命中的要求，應放在末尾。排查規則順序時，請從規則頂端開始檢查，不要只搜尋新加入的那一行，因為真正生效的可能是位置更前面的其他規則。

以下是 .conf 中的規則片段範例，只用來說明結構與比對順序，並非完整設定，也不保證適用於所有網路。example.com 是教學用網域；使用前請依自己的目標與現有策略定義調整。編輯前請先備份原設定，並確認目前選取的是修改後的設定檔。

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

DOMAIN 用於比對完整網域名稱；DOMAIN-SUFFIX 用於比對指定網域及其子網域；DOMAIN-KEYWORD 會比對網域中的關鍵字，涵蓋範圍可能比預期廣。IP-CIDR 與 IP-CIDR6 用於比對 IP 網段；GEOIP 則依 IP 位址所屬地區的資料庫進行判斷。網域要求與實際連線位址之間還有解析步驟，因此網域規則和位址規則命中時所依據的資訊並不相同，不能只憑最後顯示的某個位址反推整個比對過程。

用單一目標驗證修改，不要一次更動整份設定

修改規則前，先確認預期結果：哪個目標應採用什麼策略，以及原本為何不符合需求。新增一條針對該目標的規則後，重新送出要求，並查看連線記錄中的策略結果。若行為沒有改變，先確認設定是否已儲存並套用、是否有更前面的規則命中，以及舊連線是否仍在使用。不要一次修改 DNS、伺服器與大量規則；否則即使恢復正常，也很難知道是哪項修改發揮作用。

將目標設為 DIRECT，不代表一定可以存取；仍須依賴本機網路的解析與連線能力。設為 PROXY，也不代表遠端一定能連上該目標。REJECT 會主動拒絕要求，可能影響頁面資源、登入流程或 App 通知；使用前請先確認目標用途。規則應以明確需求為基礎，不要用項目數量衡量品質。更詳細的順序範例請參閱自訂規則優先順序與 FINAL 說明。

建議依序操作：先保留已驗證的伺服器，再用 Proxy 檢查代理路徑，最後回到 Config 確認規則分流。暫時切換模式完成比對後，請恢復原本的日常設定。

若 Proxy 可以存取，但 Config 失敗，請優先檢查規則、策略引用及設定相關的 DNS 行為；若兩種模式都失敗，則應回頭檢查伺服器驗證、傳輸設定與網路連線能力。這種分組判斷比反覆切換模式更有效。請記下最後使用的設定名稱與 Global Routing 模式，才能讓下一章的連線驗證有可重複的前提。

本機統計不等於服務端剩餘額度

Data 用來查看用戶端可觀察範圍內的流量與相關記錄，具體項目以目前 App 顯示為準。請先確認統計資料代表目前連線、某段時間或累計數據，再判讀數值變化。用戶端記錄的流量不應直接等同服務端扣除的額度：兩端的時間區間、計算單位、協定額外負載或計費方式可能不同。若要確認現有服務的剩餘額度，請查看自己的服務帳戶資訊，不要用用戶端累計數字自行推算。

請以裝置的角度理解上傳與下載方向。網頁要求、傳送檔案與雲端同步都可能產生上傳流量；接收網頁內容、影片與檔案則會產生下載流量。即使沒有主動開啟網頁，背景同步與 App 通知仍可能使用網路。因此，看到少量流量持續變動，不足以單獨判斷是否異常；請搭配目前的前景工作、背景活動與記錄範圍一起分析，尤其不要在未確認單位前，把傳輸速率和累計流量混為一談。

先分清傳輸速率、累計流量與時間範圍

傳輸速率表示單位時間內的資料變化量；累計流量則表示某個統計區間內的總量。短時間內的峰值無法證明長時間的傳輸能力，累計量增加也不代表目前仍在持續傳輸。查看時，先確認單位，以及是否混淆了位元組與位元，再進行比較。不同介面可能以不同方式顯示單位；回報問題時，最好完整記下畫面上的單位，而不是只提供沒有上下文的數字。

重新連線、清除記錄或重設統計，都可能改變可查看的範圍；操作前請先閱讀目前選項的用途。不要為了讓數字歸零而刪除伺服器或訂閱，兩者是不同的管理項目。若要比較兩次存取的流量，請選擇相同目標與相近的操作，記錄開始與結束時的統計差值，並留意瀏覽器快取是否已命中。第二次開啟頁面時流量較少，可能是因為快取，並不代表網路路徑有所改變。

透過連線記錄確認規則是否如預期生效

若 App 提供相關連線記錄，可搭配目標網域或位址、命中規則、採用的策略與處理結果，判斷要求的路徑。先確認自己剛剛送出了哪項要求，再尋找相應記錄；清單也可能同時包含背景工作與其他 App 的通訊。網域與位址不一定一一對應，有些連線直接使用位址，有些要求則依賴先前快取的解析結果。若未看到預期的網域，不要立即認定目標完全沒有送出網路要求。

記錄中的策略資訊尤其適合用來驗證 Config。先確認命中的是特定網域規則、位址規則還是 FINAL，再查看所引用的策略是否符合預期。若記錄顯示 DIRECT，不要只修改伺服器，因為該要求可能根本沒有使用伺服器；若顯示 REJECT，請先確認是否遭到主動拒絕。若記錄與預期不符，請回到第四章依序檢查規則，並確認目前選取的設定與正在編輯的檔案相同。

流量數字回答「觀察到多少」，連線記錄則協助判斷「這次要求如何處理」。兩者可搭配使用，但都不能取代實際確認目標服務是否傳回內容。

流量異常時先比對變化

發現流量明顯增加時，先停止大型工作，例如播放影片、系統更新或雲端同步，再觀察流量是否減少。接著逐一恢復工作，找出與流量增加相關的活動。不要只憑伺服器名稱判斷流量來源，也不要直接將統計增加解讀為憑證外洩。若停止前景工作後流量仍持續增加，請搭配背景 App 活動與可用記錄進一步縮小範圍，並確認統計時間範圍是否仍包含先前的資料。

若服務端額度減少，但本機 Data 變化不大，請考慮是否有自己的其他裝置正在使用同一項服務、兩端的統計週期是否一致，以及服務端是否採用不同的計算方式。先確認這些資訊，再透過現有服務的支援管道詢問計量規則。用戶端通常無法說明服務端的所有扣量細節，因此不建議反覆重設本機統計來處理帳戶額度問題；重設只會改變本機顯示，不會更改服務端紀錄。

分享診斷資訊前，先刪減不必要內容

連線記錄可能包含存取網域、路徑、裝置網路資訊與個人識別資料。對外說明問題前，請先篩選與本次狀況有關的內容，並遮蔽完整訂閱網址、密碼及可識別個人的參數。截圖也要檢查背景是否顯示敏感項目。處理完後，依 App 目前提供的功能管理不再需要的記錄；保留時間以自己的排錯需求為準，不必長期累積所有歷史資料。日常維護只需保留可重現的條件、關鍵錯誤與有效的處理結果。

本階段的目標不是一直盯著數字，而是掌握判斷方法：了解統計涵蓋的範圍、找到一次失敗要求，並分辨本機觀察結果與服務端帳戶資訊。掌握這些資訊後，再調整 Settings 中與實際問題相關的選項，就能減少沒有依據的嘗試。

分開管理 App 更新與訂閱更新

App 更新透過 App Store 完成，主要變更用戶端本身；訂閱更新則會重新取得使用者現有服務的伺服器清單，兩者並非相同操作。訂閱更新成功不代表 App 已更新；App 更新也不保證服務資訊仍然有效。日常請分別留意商店中的 App 狀態與自己的訂閱狀態，不必追逐未經確認的版本資訊。若更新前正在排查問題，請先記下可重現的條件，避免更新後失去比較依據。

訂閱更新頻率請依現有服務的說明與實際需求，不要因為一次要求較慢就連續重新整理。更新後，先確認目前選取的項目是否仍存在、名稱是否變更，以及規則中的策略引用是否受到影響。若清單更新失敗但原項目仍可用，請優先保留目前可用狀態，再排查取得問題。將正常使用與維護操作分開處理，可避免需要連線時，因一次清理操作而失去所有可用資訊。

備份不只要保留 App，也要涵蓋相關資訊

App 購買紀錄、伺服器資料、訂閱連結與規則設定應分別確認。能從 App Store 重新取得 App，不代表所有本機內容都能自動還原；裝置備份能還原多少，也應以實際復原結果確認。換機前先查看 App 提供的匯出或備份功能，並確認匯出範圍是否包含需要的設定。對手動輸入的項目而言，保留原始資料尤其重要；只留下顯示名稱，不足以重新建立連線。

備份可能包含密碼、訂閱憑證或其他存取參數，請儲存在自己能控管且受保護的位置。不要把完整設定放在公開筆記、公開資料夾或問題討論中。建議在備份中註明用途與設定名稱，並保留一份已驗證可用的版本；大幅調整規則前，請先匯出原有內容。備份是否有效，最終取決於能否讀取並還原必要資訊，而不只是檔案存在，因此請在適當時機確認備份涵蓋的內容。

換機後依相依順序復原

先在新裝置的 App Store 確認原購買紀錄與產品身分，再依商店條件取得 App；系統需求、通用購買與「家人共享」的適用性，均以 App Store 頁面標示為準。接著還原自己的伺服器或訂閱資訊，再還原規則設定，最後重新確認系統 VPN 設定授權。新裝置仍可能需要個別完成權限提示，不要因為舊裝置已授權就略過這個步驟。購買還原的詳細檢查方式請參閱已購項目還原說明。

還原後不要立即啟用所有自動觸發與進階選項。先手動選取一個已知項目，驗證連線與常用目標；確認 Config 下的分流正常後，再還原 On Demand。裝置名稱、Wi-Fi 環境、系統設定與 App 權限都可能和舊裝置不同，因此相同設定不一定會產生完全相同的觸發結果。若換機過程中遇到問題，請回到最近一個已驗證的階段，不要直接重做整個流程。

建立固定的故障復原順序

日常遇到異常時，可依四個步驟處理：確認基本網路、確認目前選取項目、檢查近期變更、還原已知基準。第一步排除 Wi-Fi 認證問題與網路無法使用的狀況；第二步確認伺服器、設定與 Global Routing；第三步查看近期是否更新訂閱、修改規則或啟用自動觸發；第四步只復原相關變更。這樣既能保留判斷依據，也能減少不必要的操作。只有在明確知道某項內容已損壞，且手邊有復原資料時，才考慮刪除並重建。

若問題只出現在某個網路，請保持設定不變，改用自己的另一個可用網路進行比較；若只有一台伺服器異常，請保留其他項目並確認該項目的參數；若只有一個目標無法存取，請檢查連線記錄與相關規則。遇到服務資格或額度問題，請透過現有服務的支援管道處理；遇到購買紀錄問題，請從 App Store 帳號紀錄查詢。依問題所在環節處理，避免用 App 設定解決帳戶端的問題。

復原基準至少應包含：可用伺服器的來源、設定名稱、Global Routing 模式、必要設定，以及最近一次有效驗證的操作。請另外妥善保管憑證，不要寫進公開的排錯紀錄。

用簡短紀錄取代反覆嘗試

每次維護只需記下幾項結果：修改內容、修改原因、採用的比對方式、是否有效，以及如何復原。不要把未經驗證的猜測記成固定規則，也不要因為短暫成功就刪除原有備份。定期清理重複項目與無用記錄時，先確認相依關係，尤其要分辨訂閱產生的項目與手動新增的項目。清理是為了減少混淆，不是讓清單越短越好。

至此，完整使用流程應已清楚：透過 App Store 確認產品與購買，系統授權允許建立連線，現有資訊提供伺服器，Global Routing 決定處理方式，實際存取驗證結果，Data 與記錄提供判斷依據，Settings 用於解決具體需求，維護流程則確保能夠復原。若要重新按照精簡步驟操作，請參閱入門指南；若要確認特定原理，可從本頁目錄前往相關章節，不必重新建立已正常運作的設定。