Shadowrocket 設定與功能說明
先確認何時建立連線，再決定請求採用哪種策略。依序檢查 Global Routing、Config、On Demand 與 Data，將模式選擇、規則判斷和結果驗證分開處理。
操作以 iPhone 和 iPad 為主。介面入口可能隨應用程式更新而調整，實際名稱請以目前 App 內顯示為準；系統需求以 App Store 頁面標示為準。首次連線步驟請參閱入門指南。
Global Routing：Config、Proxy 與 Direct
Global Routing（全域路由）決定整體請求的處理方式，不是伺服器協定選擇器，也不等同於連線總開關。
在 Home（首頁）找到 Global Routing，進入後選擇 Config（設定檔）、Proxy（代理）或 Direct（直連）。選擇前先確認 Home 中的伺服器，以及 Config 中已啟用的設定檔。變更模式後，適合用來驗證的是新發出的請求；已建立的連線可能仍沿用原本路徑，不能只重新整理一次頁面就判斷設定是否生效。
| 介面模式 | 處理方式 | 適用情境 | 注意事項 |
|---|---|---|---|
| Config（設定檔） | 依據目前設定檔中的規則決定請求策略。 | 日常依網域、位址等條件分流。 | 務必確認目前啟用的 Config 與編輯的是同一份設定檔。 |
| Proxy（代理） | 以代理方式處理整體路由。 | 暫時檢查所選伺服器的實際連線能力。 | 不是逐一重新選擇所有規則中的 PROXY 項目。 |
| Direct（直連） | 採用直接連線方式。 | 暫時檢查目前網路本身的連線情況。 | 不等同於關閉系統連線設定或停用 On Demand。 |
日常使用先選 Config
若要讓不同請求採用不同策略，請選擇 Config，再檢查規則順序。此時，即使 Home 中選取了某台伺服器，也不代表每個請求都會經過該伺服器：符合 DIRECT 的請求會直接連線，符合 REJECT 的請求會遭拒，符合 PROXY 的請求才會依相應代理策略處理。若規則引用指定的策略群組，也要檢查該群組目前的選擇。
用 Proxy 與 Direct 縮小問題範圍
若在 Config 模式下只有某個目標異常，可暫時改用 Proxy 或 Direct 對照同一目標，判斷問題是否與規則路徑有關。每次只變更一種模式，記錄結果後再切回原設定。這種對照只能協助定位問題，不能單獨證明 DNS、伺服器或目標服務一定正常。模式名稱代表整體路由選項，仍應配合連線記錄核對個別請求。
規則分流：比對條件與執行策略
規則左側描述比對條件，末尾指定處理策略。規則類型與策略是兩回事，不能把 PROXY 當成網域比對方式。
在 Config（設定檔）中選取目前使用的檔案，檢查其中的 Rule（規則）區段。規則通常由上而下比對，第一個符合的項目會決定請求去向。設定時先寫範圍較小的例外，再寫涵蓋範圍較大的通用項目，最後將 FINAL 設為前面條件皆未符合時的最終策略。編輯並儲存後，也要確認該檔案已啟用。
| 關鍵字 | 比對對象或意義 | 檢查重點 |
|---|---|---|
DOMAIN | 完整網域名稱。 | 只填網域，不包含路徑。 |
DOMAIN-SUFFIX | 指定網域及其子網域。 | 涵蓋範圍大於單一完整網域。 |
DOMAIN-KEYWORD | 網域中包含的關鍵字。 | 過短的關鍵字容易擴大比對範圍。 |
IP-CIDR / IP-CIDR6 | IPv4 / IPv6 位址範圍。 | 位址範圍與遮罩必須符合相應格式。 |
GEOIP | IP 地理位置分類。 | 分類結果不等於目標實際營運所在地。 |
USER-AGENT | 可辨識的 User-Agent 資訊。 | 受請求資訊可見度影響，不宜作為唯一判斷依據。 |
FINAL | 前面的規則皆未符合時採用的最終策略。 | 放在規則末尾，避免提前攔截後續規則。 |
PROXY / DIRECT / REJECT | 代理處理／直接連線／拒絕請求。 | 這些屬於策略，不是比對條件。 |
用最精簡的規則片段理解順序
[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT此範例僅用於說明語法。造訪 account.example.com 時，會先符合第一條規則並採用 DIRECT；其他屬於 example.com 的網域則由第二條規則比對；其餘請求會套用 FINAL。若將第二條移到第一條之前，原本針對特定網域的例外就會被先符合的後綴規則蓋過。此範例並非適用於所有網路的完整設定。
若分流結果不符預期，先確認 Global Routing 是否設為 Config，再檢查符合的規則及其策略。尚未確認比對結果前，不要同時調整 DNS、伺服器和規則順序。更完整的設定檔結構、位址範圍寫法與優先順序說明，請參閱設定欄位參考。
訂閱與伺服器管理
Subscribe 用來管理一組可更新的伺服器資訊；手動新增伺服器則是逐項儲存連線參數。兩者都無法取代分流規則設定。
Subscribe：匯入現有訂閱
在 Home 開啟 Add Server（新增伺服器），選擇 Subscribe（訂閱）類型，並在對應欄位填入向服務提供者取得的現有訂閱網址。儲存後執行更新，確認伺服器項目已出現，再選擇要使用的項目。訂閱網址可能包含存取憑證，請視為敏感資訊妥善保存，不要在公開截圖或求助內容中貼出完整網址。
訂閱更新成功只代表內容已取得並處理，不表示其中每台伺服器都能使用。更新後請確認所選項目是否仍存在、名稱是否變更，以及連線參數是否符合原本用途。訂閱管理的項目可能在下次更新時重新建立，不宜只靠臨時手動修改來長期保存參數；有需要時請先保留自己的設定記錄。
Add Server：逐項填寫伺服器資訊
手動新增時，請先在 Add Server 中選擇正確的協定類型，再填寫位址、連接埠和驗證資訊。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 等協定所需欄位各不相同，不能把一種協定的參數直接填入另一種表單。若涉及 TLS、傳輸方式或公鑰等項目，請依據現有伺服器資料逐項核對，不要只憑伺服器名稱推測。
儲存前可在備註欄標示用途，但備註本身不會改變請求路徑。儲存後先選取該伺服器，再執行 Connectivity Test（連線測試）並實際驗證連線。若清單中有多筆相似記錄，請核對位址和協定，不要只看名稱，以免選錯已失效的項目。
Connectivity Test 與 Test Method 的適用範圍
Connectivity Test 用於觀察特定測試條件下的結果。測試方式會受到 Test Method 等設定影響，測試數值不等於所有目標的連線耗時，也不代表實際傳輸速率。若測試成功但無法連線，請繼續檢查規則、DNS、驗證資訊與目標本身；若測試失敗，也要先確認測試目標和方法是否適用於目前網路。
On Demand：依網路條件建立連線
On Demand（按需連線）管理連線何時觸發；Global Routing 與 Config 則管理連線建立後如何處理請求。
在 Settings（設定）中找到 On Demand，先閱讀目前列出的觸發條件與例外，再依使用情境啟用或調整。可設定的網路條件請以 App 內實際選項為準。首次設定時先用簡單條件驗證，再逐項加入網路例外；如此一來，若連線行為不如預期，便能找出是哪項條件造成影響。
例如，若要在某些網路環境下自動建立連線，請先確認一般手動連線運作正常，再啟用相應的按需條件。接著切換至符合條件的網路，並查看系統連線狀態與 App 內狀態。不要將 On Demand 當成修復伺服器無法使用的方法：它無法補正錯誤的密碼、憑證或規則。
若手動中斷連線後又自動建立，請先查看 On Demand 是否仍啟用，以及目前網路是否符合觸發條件。需要暫停自動連線時，應先調整按需設定，再檢查連線開關。只將 Global Routing 改為 Direct，並不代表自動連線條件已停用。
Data：流量統計與讀數核對
Data（流量統計）用來查看客戶端記錄的傳輸量，不是服務提供者的帳單，也不能單憑這項數據判斷規則是否正確。
進入 Data，先確認目前顯示的統計分類、累計範圍，以及上傳和下載方向，再觀察相應伺服器的變化。若目前介面提供依 App 分類的選項，可切換分類查看；App 識別與分類會受系統和請求資訊影響，未分類的部分不一定代表連線異常。比較兩次操作時，應維持相同分類和觀察區間。
若要測試某個目標是否產生流量，可先記下初始讀數，再進行一次明確操作，等介面更新後比較增量。背景同步、媒體預載及其他 App 活動也會產生傳輸量，不能把全部增量都算在剛開啟的頁面上。需要重設統計資料時，先記下需要保留的讀數，再使用 App 提供的重設入口，並確認提示所涵蓋的範圍。
客戶端與服務提供者的讀數可能因統計起訖時間、連線額外開銷、計量單位和計費方式不同而不一致。重設客戶端統計不會替服務提供者重設用量；服務提供者開始新的計費週期，也不一定會清除 Data。判斷剩餘用量請以自己的服務提供者記錄為準；排查傳輸行為則應搭配客戶端連線記錄。詳細讀數說明請參閱Data 流量統計筆記。
Settings：常用項目與修改範圍
Settings 並非所有設定的唯一來源。DNS 等項目也可能受目前 Config 影響，修改前請先確認實際生效的設定。
DNS：一併檢查解析與連線路徑
DNS（網域名稱解析）負責將網域名稱轉換為連線所需的位址。請在 Settings 的相關項目及目前 Config 中核對 DNS 設定，先確認設定檔是否指定了解析項目，再決定要修改哪一處。不要只因某個網域無法開啟就連續更換多個解析位址；應先確認伺服器連線，再檢查解析是否成功、結果是否符合預期。
設定解析服務時，請使用已確認可連線且符合需求的設定，並保留原值。解析請求的路徑與最終連線策略並非同一回事；網域能成功解析，也不代表目標連線一定成功。變更後請用新的請求驗證，必要時重新建立連線，以免快取和既有連線影響觀察結果。參數的詳細意義請參閱設定欄位。
Test Method：統一測試條件
Test Method（測試方式）用來選擇伺服器測試的方法，請在 Settings 中進入相應項目，依目前介面提供的選項設定。比較多台伺服器時，應使用相同方法和測試目標；變更測試方法後，舊結果就不適合直接比較。測試結果反映特定條件下的表現，不應以單一數值概括連線品質。
若測試結果與實際連線情況不一致，請記錄測試方法、測試目標和目前的 Global Routing，再進行一次實際請求驗證。不要為了得到較低的測試數值而反覆變更條件，以免失去排查依據。測試只是診斷的一環，驗證資訊、規則和 DNS 仍須分別核對。
Today Widget：快速操作入口
Today Widget（今日檢視小工具）可提供快速操作或狀態檢視。在 Settings 中確認相關選項，再透過系統提供的編輯入口加入可用的小工具；實際顯示方式與可用性請以目前系統和 App 內說明為準。加入後先確認它對應目前使用的設定或伺服器，不要只憑小工具的顯示就認定目標已連線。
透過小工具觸發連線後，若狀態沒有即時更新，請返回 App 檢查實際狀態。On Demand 仍可能依條件重新建立連線，因此小工具上的單次中斷操作不一定等於永久停用自動連線。判斷網路行為仍應以 App 狀態和實際請求驗證為準。
iCloud：同步與獨立備份
iCloud 同步可在符合帳號和系統條件時同步 App 支援的資料。在 Settings 查看 iCloud 相關開關及 App 內說明，並在系統設定中確認 iCloud 可正常使用。啟用前先整理目前設定；啟用後在另一台裝置檢查實際同步的內容。不要假設所有伺服器、訂閱、規則和本機統計都會以相同方式同步。
同步不等於保留歷史版本。刪除或誤改的內容也可能同步到其他裝置，重要的 Config 應另外匯出並妥善保存。若設定中包含訂閱網址或驗證資訊，備份檔也需要妥善保護。更換裝置時，請先確認 App 取得、同步和設定還原都已完成，再建立連線，以免未檢查內容便覆寫原有設定。
Diagnostics：一次只驗證一項假設
Diagnostics（診斷）用來蒐集或檢視連線問題的相關資訊。在 Settings 中進入相應入口，使用目前可用的工具檢查網路、解析或連線情況。先寫清楚重現條件，例如「同一台伺服器、Config 模式、無法連線至某個網域」，再執行相關測試；若一次更換伺服器、DNS 和規則，測試結果就失去比較基準。
需要保存診斷結果時，只保留與問題相關的片段，並檢查內容是否包含訂閱憑證、驗證資訊、瀏覽記錄或個人位址。向他人描述問題時，可用網域和欄位名稱說明現象，不應公開完整的敏感資訊。診斷結束後，將臨時調整恢復原狀，再次確認日常連線。
修改後的檢查順序
依固定順序重新檢查，比同時切換多個選項更容易找出原因。先確認基本連線可用，再核對規則與自動連線行為。
- 確認輸入資料。確認現有訂閱是否更新成功，或手動新增的伺服器協定、位址、連接埠與驗證欄位是否一致。不要以備註名稱取代參數檢查。
- 確認模式與檔案。在 Home 查看 Global Routing，並在 Config 確認已啟用的檔案。修改某份設定檔，不代表它已成為目前生效的檔案。
- 發出新的測試請求。使用 Connectivity Test 輔助觀察，再驗證實際目標。記錄測試方式與結果，避免既有連線干擾判斷。
- 核對符合的策略。檢查請求對應的規則與最終策略，區分 DIRECT、PROXY 與 REJECT。若只有一個網域異常，優先檢查精確規則和解析結果。
- 最後檢查自動連線與統計項目。基本連線正常後，再確認 On Demand 的觸發條件、Data 的統計範圍，以及 iCloud 的同步結果。
需要復原時，請將本次變更還原為原值，不要重新匯入多份來源不明的設定。保留一份已驗證可用的 Config 和簡短的修改記錄，有助減少重複排查。若要了解介面入口、首次授權或購買項目的復原方式，可繼續閱讀以下官方手冊章節。