Data 適合用來觀察流量變化，不宜單獨據此判定某條規則是否命中，或核對線路帳單。本文適用於已完成連線設定的 iPhone、iPad 使用者：先分辨上傳、下載與分類方式，再以相同時間區間的增量進行測試，並搭配 Global Routing、Config 和連線紀錄判斷流量去向。
一、先分清累計流量與即時速度
查看 Shadowrocket（小火箭）的 Data 數據時，別忘了留意單位。上傳是裝置向外傳送的資料，下載則是裝置接收的資料；瀏覽網頁也會產生上傳流量，因為瀏覽器需要傳送請求、連線協商資訊等。下載量較大不代表上傳量應為零；上傳量增加也不等於裝置正在上傳檔案。
表示容量的 KB、MB、GB，與帶有時間分母的 KB/s、MB/s 是不同概念。前者表示一段期間內累計的資料量，後者表示傳輸速率。累計值很大，只能代表先前傳輸量較多，不能證明目前速度很快；頁面停止載入後，累計值也不會因速度下降而自動減少。
上述 60 秒是測試方法，並非 Data 的固定更新週期。統計資料是否保留、何時更新，以及哪些分類會顯示，請以裝置目前頁面為準。開始比較前，先記下時間、單位與分類，避免拿昨天的累計值和今天一次網頁請求的數據相比。
二、依伺服器與依 App 分類：兩種維度不可直接相加
依伺服器查看時，重點是觀察期間內某個伺服器項目的上傳與下載是否增加。這能回答「這個與出站相關的統計是否有變化」，而不是「哪個前景 App 獨占了所有流量」。多個 App 可能共用同一伺服器；策略切換也可能讓同一個 App 的不同連線使用不同出站。
依 App 分類時，重點是頁面能辨識並歸入相應項目的流量。Apple 平台的來源辨識有其限制，不能將這個檢視畫面視為系統中所有 App 的完整稽核結果。系統服務、背景工作或無法明確歸屬的連線，可能不會以預期的 App 名稱顯示；實際分類比根據名稱猜測更可靠。
| 觀察維度 | 適合判斷 | 不能單憑此項推論 |
|---|---|---|
| 依伺服器 | 本輪哪些伺服器項目的流量增加 | 所有流量增量都來自某個前景 App |
| 依 App | 可辨識的來源項目是否有新增傳輸 | 該 App 的所有請求都命中同一條規則 |
| 上傳與下載 | 傳送與接收的流量各增加多少 | 與服務商計費流量逐位元組完全一致 |
判讀方式：分別比較增量，不要將兩種分類的數值相加
先在同一分類中比較測試前後的讀數，再到另一個分類確認變化方向。伺服器與 App 是觀察流量的不同維度，把兩個檢視畫面的數值相加可能會重複計算，無法得出更準確的總量。
三、統計方式與歸零：先保留紀錄，再建立基準值
Data、系統網路用量與服務商帳單，可能在統計起訖時間、涵蓋範圍、協定封裝及單位換算方面有所不同。即使觀察的是同一次下載，也不應要求三處數字完全相同。尤其不要直接把用戶端顯示的下載量當成訂閱剩餘額度；額度與計費週期應以服務商提供的資訊為準。
歸零是為了縮短觀察區間，並非修復連線的必要步驟。中斷後重新連線、退出 App 或更新訂閱，都不能作為「統計一定會歸零」的依據。如果目前的 Data 頁面提供歸零操作，執行前先確認影響的是單一項目還是整個統計範圍，並保留需要的紀錄；不要只憑圖示位置猜測操作範圍。
- 先記錄：保存目前的伺服器名稱、上傳與下載讀數、記錄時間，以及本輪使用的 Global Routing 模式。
- 再選定基準值：若要保留歷史紀錄，不必歸零，直接將目前數值作為起始值；若要建立全新的觀察區間，再使用頁面實際提供的歸零控制項。
- 確認結果：歸零後重新查看目標分類。若有背景連線，讀數可能很快再次增加，不必要求它長時間維持在零。
- 維持相同條件：下一輪使用相同網路、相同測試資源與相同時間。從 Wi-Fi 切換到行動網路後，請重新記錄一輪。
四、確認規則分流：先檢查 Global Routing
Data 顯示流量變化，規則則決定請求如何選擇路徑，兩者無法互相取代。在 Home 查看 Global Routing：只有使用 Config 時，才應依目前設定中的規則檢查比對結果；使用 Proxy 或 Direct 時，不要仍以 Config 中的某條網域規則解釋現象。若使用 Scene，請先確認目前的場景及其生效設定，再進行測試。
以下為規則語法示意，並非可整段覆蓋目前設定的方案。範例中的 PROXY 必須對應目前設定中實際可用的策略。example.com 僅供說明，不能用來驗證你實際使用情境的分流結果。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX：依網域後綴比對；同一個頁面的圖片、影片和 API 可能來自其他網域。IP-CIDR：依目標 IP 網段比對；範例中的no-resolve表示不為這條 IP 規則主動進行網域解析。GEOIP：依據 IP 的地理位置歸屬比對，不能根據網站顯示的語言推斷是否命中。FINAL：作為前面規則都未命中時的備用規則；也要檢查它之前是否已有其他規則先行命中。
在 Config 確認目前使用的設定與規則順序後，再發起新的連線。修改規則前已建立的長連線，可能仍沿用原有出站，因此只重新整理 Data 不保證請求會重新比對。請停止原本的測試工作，再次發出請求，並在可用的連線紀錄中確認目標網域或 IP、命中的規則與出站策略。
五、進行一次 60 秒對照測試：以增量縮小範圍
測試前先暫停其他高流量工作，選擇一項你有權存取且可重複請求的資源。保持 Home 中的連線與伺服器選擇不變，記錄 Data 起始值，再持續觀察 60 秒。不要同時更新訂閱、更換協定或修改規則，否則即使數字有變化，也難以判斷是哪個因素造成。
| 範例讀數 | 測試前 | 測試後 | 本輪增量 |
|---|---|---|---|
| 伺服器下載 | 120 MB | 132 MB | 12 MB |
| 伺服器上傳 | 8 MB | 9 MB | 1 MB |
表格中的數字僅供示範計算，並非實測效能。下載增量 12 MB 除以 60 秒，得到此區間平均約 0.2 MB/s；這包含等待時間，不等於下載過程中的峰值速度。若頁面顯示的數值經過四捨五入，差值也只是近似值，不適合據此比較極小的請求。
下一步：交叉比對統計變化與實際連線
目標伺服器的數值增加且測試資源成功載入，只能支持「本輪該伺服器有傳輸」這個判斷。若要確認指定網域是否正確分流，還要檢查該請求命中的規則與出站策略；若數字沒有變化，先排除快取與舊連線，再考慮規則或設定問題。
若要比較 Direct 與代理路徑，請分成不同輪次測試，每輪重新建立基準值，且每次只改變一個條件。使用命中瀏覽器快取的頁面進行對照，可能幾乎不會產生新的下載；可選用能確認重新發出請求的自有測試資源，但不要為了測試而消耗大量方案流量。
六、常見讀數問題與檢查順序
沒有開啟網頁，為什麼 Data 數值還在增加？
先暫停同步、媒體播放等已知工作，再觀察一段固定時間。背景請求、連線保活及系統服務都可能產生流量；若在 Settings → On Demand 設定了按需連線，也應確認目前是否因相應條件而觸發連線。不能只憑少量增長就判定有異常傳輸。
網頁可以開啟，但所選伺服器的數值沒變，是分流失敗嗎？
先在 Home 確認 Global Routing 與伺服器選擇，再到 Config 檢查目前生效的設定。資源可能來自快取、透過 Direct 存取，或使用其他策略選取的伺服器。重新發出請求並檢查連線紀錄，比反覆切換開關更有助於判斷。
在依 App 分類的清單中找不到正在使用的 App，該怎麼辦？
不要因為清單中沒有 App 名稱，就認定它沒有連上網路。先查看相同時間區間的整體變化與伺服器增量，再根據該請求的目標與時間確認連線。對於無法準確歸類的項目，應保留不確定性，不要勉強將所有未辨識流量歸到某個 App。
更新訂閱後流量讀數不同，需要重新歸零嗎？
先檢查伺服器項目、策略引用與目前選擇是否有變動。更新訂閱和統計歸零是不同操作；保留舊紀錄後重新設定起始值，就能繼續測試。若項目已替換，不要只因顯示名稱相同，就把前後數值視為同一筆連續紀錄。
排查結束後，請還原原本需要的路由設定，並保留「時間、網路、設定、伺服器、起始與結束值、目標請求」六項紀錄。Data 用來發現變化，連線紀錄用來確認流量去向，服務商資訊則用於核對額度；釐清三者用途，比反覆歸零更容易重現問題。更多基本操作請參閱Global Routing 使用說明；網域解析問題可接著查看DNS 排查。