Shadowrocket（小火箭）的 Data 頁面用來查看用戶端記錄的流量，並非服務商的資費帳單。已設定伺服器的使用者，可先分辨上行、下行與累計值，再分別查看伺服器歸屬和 App 活動，最後透過一次受控連線前後的差值檢查分流狀況。本文也會說明統計起點，以及背景流量與讀數不一致時的排查順序。
一、先分清流量與連線速度
Data 的流量讀數表示已傳輸的資料量。上行是裝置傳送出去的資料，下行是裝置從外部接收的資料。開啟網頁時，傳送請求會產生上行流量，接收文字、圖片和影片則會產生下行流量；上傳照片時，上行通常較明顯。即使主要是在下載，上行也不一定是零，因為建立連線、傳送請求和確認資訊等過程仍會產生上行流量。
先確認數值旁的單位，再看數值大小。KB、MB、GB 表示資料量；帶有「每秒」概念的單位才表示速率。累計下行量較大，只代表觀察期間接收的資料較多，不能據此判斷目前速度，也不能取代 Connectivity Test 的連線檢查結果。
流量統計也不等於連線成功。請求即使失敗，也可能已傳送資料，之後才因解析、交握或遠端回應問題而中止；反之，從本機快取載入的頁面可能正常顯示，卻只產生少量新流量。判斷時應一併參考 Data 讀數和實際連線結果。
二、依伺服器或 App 檢視，各自能回答什麼問題
依伺服器檢視，著重於統計期間內某個伺服器項目承載了多少流量；依 App 檢視，則著重於哪些 App 活動產生了可歸屬的流量。這是觀察同一類網路活動的不同角度，並非兩份可直接相加的資費用量。
| 檢視角度 | 可以判斷 | 無法單獨證明 |
|---|---|---|
| 依伺服器 | 某個伺服器項目的累計流量或本次觀察期間的增量 | 所有 App 都使用了該伺服器 |
| 依 App | 可辨識 App 的流量分布與增長情況 | 該 App 的每個請求都使用相同策略 |
| 上行與下行 | 傳送與接收的資料量差異 | 即時頻寬、延遲或剩餘資費額度 |
App 流量歸屬也受系統提供的資訊與目前統計能力限制。若出現無法明確歸屬的記錄，請勿直接判定為未知 App 或異常程式。單一 App 可能連線至多個網域，也可能同時有直連與代理請求，因此「App 有流量」與「某個伺服器有流量」並非一一對應。
結論：使用相同時間範圍比對兩種檢視角度
先記下伺服器與目標 App 的目前讀數，再只操作一個 App。比對相同時段的流量增量，不要拿伺服器的歷史累計值與 App 剛產生的少量活動比較。
三、統計從何時開始？為何不能當作資費帳單
相關流量必須經過 Shadowrocket 處理並記錄，才會納入統計。安裝 App、購買或匯入訂閱的時間，都不能直接視為 Data 目前數值的起點。也不要把所有欄位一概解讀為「從這次開啟頁面起算」：目前連線資料與保留的累計記錄應分開看待。
判斷統計起點時，優先查看目前頁面是否明確標示時間範圍、連線時間或重設狀態。若沒有明確的時間標示，就不要把數值稱為「今日用量」或「本月用量」。連線中斷後是否保留某項讀數，應以該欄位的實際變化為準；不要假設每次重新連線都會清除所有歷史資料。
- 需要測試一段連線：連線前記下數值與時間，連線後再記錄一次，以差值建立自己的觀察區間。
- 曾切換伺服器：分別保存切換前後的記錄，不要把舊伺服器的累計值當成目前伺服器本次的流量。
- 曾清除或重設資料：將操作時間記為新的比較起點，不要再直接與重設前的累計值相減。
- 需要查詢剩餘額度：前往服務商提供的用量頁面確認；計費週期與流量計算方式請以服務商說明為準。
用戶端與服務商可能在不同環節計算流量。協定封裝、統計更新間隔、流量倍率及計費週期都可能影響最終顯示，因此兩邊的數值不一定完全一致。裝置的行動網路數據統計則是另一種計算方式，可能包含 Shadowrocket 未處理的系統活動。未確認統計範圍前，不應直接以這三處的數字互相替代。
四、透過五個步驟進行可重複檢查的流量觀察
以下操作不需要修改伺服器參數，也不需要重新匯入訂閱。請先使用現有設定；若尚未取得訂閱，請向服務商索取。測試時只執行一個明確的連線動作，例如在 Safari 開啟未載入快取的頁面，避免同時播放影片、更新 App 或同步大量照片。
-
確認連線
前往 Home，在 SERVER 清單確認目前選取的伺服器，開啟頂端的連線開關，再執行 Connectivity Test。測試結果只能作為連線狀況的參考，還需要實際開啟目標頁面確認。
-
確認路由模式
前往 Home → Global Routing，記下目前模式是 Config、Proxy、Direct 還是 Scene。若使用 Config，再到 Config 確認目前啟用的設定，測試期間不要切換。
-
記錄基準值
開啟 Data，分別記下目標伺服器與目標 App 目前的上行、下行數值及時間。暫停其他前景下載，並留意背景同步可能仍在進行。
-
執行連線
返回 Safari 完成一次頁面連線，記錄開始與結束時間。不要同時切換 Wi-Fi、行動網路或伺服器，否則流量歸屬的變化會難以判讀。
-
比較增量
返回 Data，等待讀數更新後記錄相同欄位。以後一次的數值減去前一次的數值，並一併參考連線是否成功、目前路由模式與請求記錄。
以下僅為差值計算範例，並非實測結果或效能承諾。請使用相同單位；若介面顯示的數值經過四捨五入，少量流量可能不會呈現明顯變化。可延長觀察時間，不要立刻判定記錄失效。
| 欄位 | 連線前 | 連線後 | 本次增量 |
|---|---|---|---|
| 伺服器下行 | 100 MB | 120 MB | 20 MB |
| 伺服器上行 | 10 MB | 11 MB | 1 MB |
五、搭配 Global Routing 判斷分流是否符合預期
Data 提供結果線索，Global Routing 與目前設定則決定流量如何處理。發現伺服器讀數增加前，應先確認目前的路由模式。尤其不要在 Proxy 模式下觀察到流量，就據此認定 Config 中某條規則已命中。
Config
建議依目前設定中的規則選擇策略。檢查分流時，應同時核對目標請求、命中的規則與最終策略，不要預設未命中的請求一定會直連。
適用情況：確認現有設定是否依預期分流
Proxy
讓納入處理範圍的流量經由代理路徑，適合作為連線狀況的對照。這無法證明 Config 中的特定 DOMAIN-SUFFIX 或 IP-CIDR 規則有效。
適用情況：暫時區分伺服器問題與規則問題
Direct
使用直連路徑。伺服器代理流量沒有增加，可能符合目前模式；不能只因伺服器讀數為零就判定連線故障。
適用情況：比對目標透過直連路徑的連線狀況
若使用 Scene，請先確認目前場景對應的設定及生效條件；不要將 Scene 視為必然等同於 Proxy 或 Direct 的第四種路徑。測試前後應維持相同場景，差值才有比較意義。
在 Config 中，規則順序同樣重要。DOMAIN-SUFFIX 依網域後綴比對，GEOIP 依 IP 地理資料庫比對，IP-CIDR 依 IP 網段比對，FINAL 則處理前面未命中的請求。流量的最終去向取決於命中規則指定的策略，而非 App 名稱。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY以下僅用於說明規則語法：example.com 及其子網域符合 DIRECT，其餘請求則由 FINAL 指向 PROXY。測試前請確認設定支援所引用的策略；不要為了觀察流量而直接覆寫現有設定。完整網頁也可能載入其他網域的資源，因此即使主網域採直連，仍可能看到部分代理流量。
結論：流量增加只能證明有資料經過
若要確認目標是否符合預期規則，應在同一次連線中比對請求記錄中的目標、命中規則與最終策略，再以 Data 增量輔助驗證，不要用整個頁面的總流量取代逐項請求的判斷。
六、讀數異常時，依現象逐項排查
先記錄現象，再調整設定。記下觀察時間、網路類型、Global Routing 模式與連線目標，通常比反覆重新連線更有助於找出原因。每次只變更一個條件，完成一次連線後重新記錄 Data，避免混淆多項變更造成的結果。
網頁可以開啟，伺服器流量為何沒有增加？
先查看 Home → Global Routing 是否為 Direct，再檢查 Config 中的目標是否符合 DIRECT。接著使用未載入快取的內容重試，並等待 Data 更新。命中快取、單位進位或查看了錯誤的伺服器項目，都可能讓流量增量不明顯。
沒有操作，流量為什麼還在增加？
先暫停雲端同步、媒體播放與 App 更新，再觀察 App 檢視角度的增量。接著確認 Settings → On Demand 是否已啟用及其條件，檢查是否有自動觸發連線的情況；返回 Home 核對實際連線狀態，不要只憑先前關閉過開關就判斷。
某個 App 的數值與伺服器數值對不上？
重新統一觀察的起訖時間，並停止其他 App 活動。該 App 可能同時產生直連與代理請求，伺服器也可能承載其他 App 的流量；App 識別範圍與顯示時的數值進位也會影響比對，不必要求兩個累計值完全相同。
服務商顯示的用量比 Data 多，該怎麼辦？
先確認資費計算週期一致，再核對服務商說明的流量倍率、更新延遲，以及同一帳戶其他裝置的使用情況。Data 用於用戶端流量觀察，剩餘額度應以服務商帳單為準；提交排查資料時，請勿附上訂閱連結或認證資訊。
最後，將一次完整檢查整理為四項記錄：目前連線狀態、目前路由模式、連線前後的流量差值，以及目標請求的最終策略。若 Connectivity Test 與實際連線都失敗，應優先處理網路或伺服器連線問題；若連線正常但路徑不符預期，再回到 Config 檢查規則順序。Data 只是驗證流程的一環，不能單獨作為故障結論。