功能路徑與設定邏輯
本頁依實際操作順序說明 Global Routing、規則、Subscribe、On Demand、Data 與 Settings。每個項目分別回答「是什麼、在哪裡、如何設定、要注意什麼」，適合已完成 App Store 安裝並準備整理現有設定的使用者。
本頁所有匯入步驟皆以使用者已有自己的訂閱或伺服器資訊為前提。購買 Shadowrocket 取得的是客戶端使用權，客戶端一次買斷 ≠ 線路方案。應用程式取得方式、系統要求與相容裝置資訊均以 App Store 產品頁 標示為準。
01 / GLOBAL ROUTING
Global Routing 決定連線建立後，網路請求要依規則判斷、統一交給 Proxy，還是直接連線。它是整體處理模式，不等同於某一條規則，也不會取代伺服器選擇。日常使用前，應先確認目前選取的伺服器可用，再選擇符合目的的模式。
| 中文模式 | 介面用語 | 處理方式 | 適用情境 | 主要注意事項 |
|---|---|---|---|---|
| 設定 | Config |
依目前設定中的規則由上而下比對，再交由對應策略處理。 | 需要依網域、位址或地區分別使用 PROXY、DIRECT、REJECT 時。 | 結果取決於規則順序、規則內容、策略名稱，以及目前設定是否生效。 |
| 代理 | Proxy |
請求統一交由目前選取的 Proxy 處理，方便排除規則差異進行驗證。 | 暫時判斷問題是否來自規則，或短時間內要求統一處理請求時。 | 它會略過細部分流邏輯，不適合作為所有設定問題的最終處理方式。 |
| 直連 | Direct |
請求使用 Direct，不經過所選 Proxy。 | 確認本地網路是否正常，或暫時驗證連線差異時。 | Direct 正常而 Config 異常時，通常應繼續檢查規則、DNS 與伺服器狀態。 |
在 Home 中找到 Global Routing，可看到 Config、Proxy、Direct 三種模式。Config 是由規則驅動的方式；Proxy 是統一使用目前的 Proxy；Direct 則是直接連線。切換只會改變目前的處理模式，不會自動修改 Config 檔案，也不會替使用者選擇另一台伺服器。
如果目標是長期依規則使用，通常先在 Config 中確認設定，再回到 Home 選擇 Config。若某個網站在 Config 下異常，可以暫時切換至 Proxy 和 Direct 分別驗證。三種結果之間的差異，有助於判斷問題位於規則、伺服器或本地網路。
02 / RULES
規則分流的核心是「由上而下，第一條命中後即停止」。規則左側描述比對條件，末尾策略描述處理方式。具體規則通常位於目前 Config 的 Rule 區段，使用時應同時檢查關鍵字、比對值、策略名稱與排列位置。
DOMAIN 用於完整網域；DOMAIN-SUFFIX 用於某個網域後綴及其子網域；DOMAIN-KEYWORD 依網域中的關鍵字比對。IP-CIDR 與 IP-CIDR6 分別處理位址網段，GEOIP 依位址歸屬資訊判斷，USER-AGENT 則依據請求中的識別資訊比對。不同類型解決的問題不同，不宜只因名稱相近就互相替換。
網域規則通常應放在較寬泛的 GEOIP 或 FINAL 之前。精確條件應優先於寬泛條件，否則前面的寬鬆規則可能提前命中，讓後面的細部規則沒有執行機會。修改後要儲存，並確認目前啟用的正是剛才編輯的 Config。
PROXY、DIRECT、REJECT 是常見策略。PROXY 會將請求交給指定策略或目前的代理路徑，DIRECT 直接連線，REJECT 拒絕請求。若規則末尾引用的是自訂策略群組名稱，該名稱必須與設定中的定義一致；拼寫、大小寫或名稱不一致，都可能導致結果偏離預期。
FINAL 是兜底規則，應放在規則清單末尾，用來處理前面所有規則都未命中的請求。排查時先找出目標請求命中了哪一條規則，再確認該規則的策略，不要只查看 FINAL。新增規則後，應以少量明確網域進行驗證，避免一次修改過多而失去判斷依據。
03 / SUBSCRIBE
Subscribe 用於讀取使用者已有的訂閱資訊並更新伺服器清單；Add Server、Scan QR Code 與 Import from Cloud JSON 可依不同來源加入既有資訊。匯入只是將資料寫入客戶端，實際可用性仍取決於資訊本身、網路狀態與伺服器端設定。
從 Home 進入伺服器清單後，可使用 Add Server 手動輸入，也可依現有資料選擇 Subscribe、Scan QR Code 或 Import from Cloud JSON。手動新增時，協定類型、伺服器位址、連接埠、驗證欄位與額外參數都必須與原始資料一致。常見協定名稱包括 Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard 與 Hysteria2。
對於 Subscribe，先確認連結是否完整，再儲存並執行更新。更新完成後應查看清單是否出現預期變化，並選擇一項執行 Connectivity Test。測試結果只能作為目前時刻的連線參考，不能單獨代表持續使用體驗。
訂閱更新可能改變伺服器名稱、排序或現有項目。更新前可先記住目前選取的項目，更新後重新確認 Home 中的選擇。若清單沒有變化，依序檢查連結是否完整、目前網路是否能存取該位址、訂閱是否仍然有效，以及客戶端是否顯示明確錯誤。
同時存在多個來源時，建議使用容易辨認的群組與備註，避免重名項目造成誤選。刪除舊項目前，先確認它是否仍被策略群組或 Config 引用。伺服器資訊通常包含敏感欄位，展示 Diagnostics、螢幕截圖或設定片段前，應先移除位址、驗證內容與完整訂閱連結。
04 / ON DEMAND
On Demand 用於依據已設定的網路條件決定是否建立連線。它適合在明確知道觸發條件與例外條件時使用。啟用前應先完成一次手動連線測試，確認伺服器、Global Routing、規則與 DNS 在一般連線下都能正常運作。
在 Settings 中進入 On Demand，依照介面提供的網路條件新增規則。可用條件以目前應用程式介面顯示為準。先從單一且容易驗證的條件開始：儲存後切換一次對應網路，觀察系統連線狀態，再逐步增加其他條件。這樣能區分是觸發條件未命中，還是連線建立後發生網路問題。
On Demand 決定「何時嘗試連線」，Global Routing 決定「連線後如何處理請求」，兩者職責不同。修改 Global Routing 不會自動改變 On Demand 條件；反過來，On Demand 成功觸發也不能證明目前的規則、DNS 與伺服器一定可用。
05 / DATA
Data 用於查看 Shadowrocket 記錄的流量資訊，適合輔助判斷哪些連線產生資料、目前工作階段是否持續傳輸，以及不同統計週期之間的變化。它是客戶端側的觀察工具，不應直接視為服務帳單或電信業者計費依據。
從應用程式中的 Data 進入統計檢視後，先確認介面顯示的統計範圍與時間區間，再比較上傳與下載。若剛建立連線但資料始終沒有變化，可同時檢查目標應用程式是否產生請求、系統連線是否仍在，以及規則是否將請求交給預期策略。僅看到流量增加，也不能證明目標內容已完整載入。
排查某次異常時，應先記錄開始時間，再重現一次問題，然後對照 Data 與 Diagnostics。這比觀察累計數字更容易定位。若執行清除或重設，應先記錄需要保留的資訊；具體清除入口與統計口徑以目前介面文字為準。
06 / SETTINGS
Settings 集中放置 DNS、Test Method、Today Widget、iCloud 與 Diagnostics 等項目。這些設定會影響解析、測試、系統入口、同步與排查方式。調整前應記錄原本狀態，每次只修改一類設定，並在相同網路條件下重新測試。
是什麼：DNS 負責將網域轉換為網路位址。解析結果會影響後續網域規則、位址規則與連線目標，因此 DNS 異常常表現為網域無法開啟、部分請求逾時，或同一位址在不同網路下得到不同結果。
在哪裡與如何設定：從 Settings 進入 DNS 相關項目，同時檢查目前 Config 的 General 區段是否另有 DNS 設定。優先維持一套來源明確且能夠解釋的設定，不要同時疊加多組互相矛盾的解析安排。修改後應分別測試網域存取與直接位址連線。
注意事項：如果 Direct 可以存取而 Config 異常，或伺服器測試可連線但網域存取失敗，應重點檢查 DNS 與規則之間的關係。切換 Wi-Fi 與行動網路後結果不同時，也應記錄各自的解析表現再作判斷。
是什麼：Test Method 決定 Connectivity Test 使用哪種方式判斷連線狀態。測試值反映特定測試目標與方法下的回應，不等於應用程式載入、影片傳輸或長連線的完整體驗。
在哪裡與如何設定：在 Settings 中找到 Test Method，選擇介面目前提供的方法。比較多台伺服器時，應維持相同的 Test Method、相同網路與相近時間，避免將測試條件變化誤認為伺服器差異。
注意事項：一次逾時不宜直接下結論。可以重複測試，並結合實際存取、Data 與 Diagnostics 進行判斷。若所有伺服器同時異常，先檢查本地網路、DNS 與訂閱資訊，而不是逐一修改伺服器參數。
是什麼：Today Widget 是系統小工具相關入口，用於在系統允許的區域查看 Shadowrocket 提供的快捷資訊或操作。具體可用內容以系統與應用程式介面顯示為準。
在哪裡與如何設定：先在 Settings 檢查 Today Widget 相關選項，再到系統的小工具編輯區域加入 Shadowrocket。加入後確認小工具能讀取目前狀態，並測試點擊行為是否進入預期頁面。
注意事項：小工具顯示可能受到系統更新節奏影響，不應僅因短時間未更新就判斷連線失效。需要確認即時狀態時，應回到 Shadowrocket 的 Home、Data 或系統連線狀態查看。
是什麼：iCloud 相關功能用於在符合條件的 Apple 裝置之間儲存或同步應用程式資料。它適合用於遷移與復原，但同步結果仍取決於裝置登入狀態、iCloud 可用性，以及應用程式目前提供的同步範圍。
在哪裡與如何設定：在 Settings 檢查 iCloud 選項，並確認裝置使用預期的 Apple 帳號。啟用前先整理重複伺服器與舊設定；另一台裝置完成同步後，核對 Config、伺服器名稱與目前選擇，不要直接假定兩端完全一致。
注意事項：發生同步衝突時，先保留來源明確且時間較新的資料，再逐項核對。設定中可能包含伺服器位址與驗證欄位，應依敏感資料方式管理，不要將完整同步內容直接展示在公開頁面。
是什麼：Diagnostics 用於收集連線、解析與請求處理過程中的診斷資訊。它的作用是協助定位失敗發生在哪一層，而不是自動替使用者修復設定。
在哪裡與如何設定：從 Settings 進入 Diagnostics，在重現問題前記下時間、網路類型、Global Routing 模式與目前伺服器。接著只重現一次目標問題，再查看相鄰時段的錯誤、DNS 結果與規則處理資訊。
注意事項：分享診斷內容前，應移除完整訂閱位址、伺服器位址、驗證欄位、裝置識別資訊與與問題無關的存取記錄。診斷時盡量少作變更，修改一項後重新重現，才能建立設定與結果之間的對應關係。
07 / WORKFLOW
建議順序是：先確認本地網路，再檢查伺服器資訊，接著驗證 Global Routing，然後檢查規則與 DNS，最後啟用 On Demand、Today Widget 和 iCloud 等輔助功能。每完成一層都進行一次明確測試。
確認 Subscribe 連結或伺服器欄位完整，協定類型與原始資料一致。
選擇目標伺服器，使用統一的 Test Method 執行 Connectivity Test。
先使用 Config 測試，再透過 Proxy 與 Direct 區分規則和本地網路問題。
找出第一條命中的規則，確認策略、FINAL 位置與 DNS 設定來源。
手動連線穩定後再設定 On Demand，並從單一觸發條件開始驗證。
結合 Data 與 Diagnostics 記錄時間、網路、模式與實際結果。