本文適合已在 Shadowrocket（小火箭）匯入自己的訂閱，並想確認流量去向的使用者。先分辨伺服器彙整與 App 歸屬，再固定統計時段，最後交叉比對單次請求、規則命中紀錄與流量增量。Data 顯示的累計用量不是即時速度，也不能直接取代服務商帳單；App 歸屬資訊的可見範圍，則以實際介面與系統提供的資訊為準。
一、先確認 Data 的統計口徑
開啟 Data 後，別只看最大的數字。先確認目前項目代表伺服器、連線目標還是 App，數值是上傳、下載或合計，以及統計從何時開始。即使兩處都顯示 MB，只要彙整對象或起訖時間不同，數值就不一定能直接比較。實際分組、欄位與重設入口，請以應用程式介面為準。
上傳通常是裝置向外傳送的資料，下載則是裝置接收的資料。瀏覽網頁也會上傳請求、連線交涉與確認資訊，因此上傳量不為零，不代表正在主動傳送檔案。累計流量表示一段時間內傳輸了多少資料；速度則有時間單位，例如 KB/s。若把累計 20 MB 當成「目前速度 20 MB」，就會得出錯誤結論。
判斷本次操作產生的流量，應以結束值減去開始值，而非比較兩個累計總數。若中途重設統計、切換統計範圍或重新建立連線，應重新記錄基準值。應用程式內的計數、系統行動網路用量與服務商帳單各有統計範圍，不能只因數值不同就判定異常。
二、按伺服器看流量去向，按 App 看來源
按伺服器彙整，回答的是「資料經由哪個伺服器項目處理」。多個 App 同時使用同一伺服器時，流量會合併計算；同一個 App 存取不同目標，也可能因規則不同而使用不同出站。因此，伺服器流量增加，不能單獨證明某個 App 的所有請求都經過該伺服器。
按 App 檢視，則是試圖回答「流量由哪個 App 產生」。不過，App 身分不等同網域：同一個 App 可能連線至內容、圖片、登入與推播等不同網域；同一網域也可能由多個 App 存取。不能直接把某個目標網域的累計流量，當成某個 App 的完整用量。
尤其在 iPhone 與 iPad 上，VPN 隧道取得的封包資訊，不等於完整的系統程序資訊。若目前 Data 介面沒有 App 歸屬欄位，就不能根據伺服器名稱推算 App 用量排行；若介面顯示無法識別或未歸屬的紀錄，也應保留這項不確定性。若要確認行動網路中各 App 的用量，可前往系統 Settings → Cellular 查看，並確認系統統計週期；這些數據也不等於包含 Wi-Fi 的 App 總流量。
| 觀察對象 | 可以回答 | 無法單獨證明 |
|---|---|---|
| 伺服器項目 | 該項目在目前時段內的傳輸變化 | 某個 App 的所有請求都經由此伺服器 |
| App 歸屬資訊 | 可識別範圍內的流量來源 | 裝置上的所有 App 都已完整歸因 |
| 目標網域或 IP | 請求連線至何處 | 請求一定來自某個特定 App |
| 系統行動網路用量 | 系統統計週期內的行動數據用量 | 同一個 App 使用 Wi-Fi 時的用量 |
三、固定觀察時段，進行可重複的流量測試
測試前，先在 Home 確認已建立連線，再記錄 Global Routing 目前的選擇，以及 Config 中啟用的設定檔。本文假設你已備妥自己的伺服器與訂閱，無須為了查看統計而增加任何連線服務。測試期間不要更新訂閱或切換伺服器，以免同名項目變動影響前後比較。
- 減少干擾：暫停大型檔案傳輸、影片播放與雲端同步。關閉其他 App 的前景操作，但別假設這樣就能排除所有背景流量。
- 記錄起點：在 Data 記下目標伺服器的上傳、下載累計值與時間。保留既有紀錄即可，不必每次測試前都清除所有統計。
- 單獨觸發：只開啟一個 App，瀏覽一個已知頁面或執行一次明確操作。避免同時重新整理多個頁面，觀察約 60 秒。
- 記錄終點：返回 Data，讀取相同項目與相同口徑的累計值，分別計算上傳與下載的增量。
- 核對請求：在可用的連線紀錄中確認目標網域、命中的規則與出站資訊。若細節不足，就降低判斷的確定程度，不要把流量增量當成唯一證據。
- 再測一次：維持設定不變並重複測試。第二次可能命中快取，不必要求位元組數與第一次完全相同。
若要比較兩種設定，每次只變更一個變數。例如先維持伺服器不變，只將 Global Routing 從 Proxy 切換為 Config，再重新建立測試連線。若同時更換伺服器、DNS 與規則，即使數字有所變化，也無法判斷是由哪個因素造成。
四、交叉比對流量增量與規則命中
在 Home → Global Routing 中，Proxy、Direct、Config 與 Scene 代表不同的路由模式。Proxy 適合用來建立代理路徑的對照，Direct 可作為直接連線的對照；Config 則依據目前設定中的規則判斷流量去向。Scene 須依所選場景的具體設定判斷，不能直接視為固定代理或固定直連。
驗證規則分流時，先選用 Config，並在 Config 確認目前啟用的檔案。規則通常依序比對，較早命中的項目會影響結果；FINAL 是最後的兜底規則。只在編輯器中看到一條 DOMAIN-SUFFIX，不代表本次連線已命中該規則，也不代表它一定優先於其他符合條件的項目。
測試前記錄
- 連線入口
- Home
- 路由入口
- Home → Global Routing
- 路由模式
- Config
- 設定檔確認
- Config 中目前啟用的檔案
記下實際選擇，不要以記憶中的設定代替目前狀態。
範例規則說明
- DOMAIN-SUFFIX
- example.com,PROXY
- IP-CIDR
- 192.0.2.0/24,DIRECT,no-resolve
- FINAL
- DIRECT
- 比對順序
- 由上而下比對，命中後採用對應策略
範例使用保留網域與文件用位址範圍，僅用來說明語法，並非測試目標。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECT上例中，example.com 及其子網域會匹配 PROXY；文件用位址範圍會匹配 DIRECT，no-resolve 表示不因這條 IP 規則額外觸發網域解析；其他請求則最後套用 DIRECT。這只是規則片段，不能取代完整設定。實際使用時，應確認目前設定中可用的策略名稱與自己的需求相符。
判斷方式：每個請求都要有一組佐證
若預期目標應走 PROXY，應一併確認該請求命中的規則、實際出站，以及對應伺服器的流量增量。若只有累計數字增加，卻無法對應到特定請求，請先重做單一 App 測試，不要立即修改整份規則。
五、數字為何與預期不同
數據差異最常見的原因是統計範圍不同，而非規則失效。裝置端可能在某個處理層計數，服務商則在伺服器端依自己的口徑計費；傳輸封裝、連線交涉、重傳、上下行計費方式與時間範圍，都可能造成差異。HTTPS 常用 TCP 443，HTTP/3 常用 UDP 443，但連接埠相同不代表來源 App 相同，也不能證明所有請求都採用相同傳輸方式。
- 頁面快取：若頁面已從本機快取顯示，可能只有少量檢查更新的請求；畫面有所變化，不代表全部內容都重新下載。
- 背景活動：通知、同步與其他連線，可能使伺服器累計值在測試中的 App 閒置時繼續增加。
- 直連流量：使用 DIRECT 的請求不應預期會計入某個代理伺服器項目；是否會出現在其他彙總項目，請依目前介面的統計範圍判斷。
- 既有長連線沿用原路徑：切換規則後，已建立的連線可能繼續使用原有路徑。請結束測試操作並重新建立連線，再判斷新規則的結果。
- 計數與更新：顯示數值經過四捨五入、更新間隔、重設或統計時段變動，都會影響小流量比較。計算差值前，請先排除這些因素。
- 項目變動：更新自己的訂閱後，伺服器名稱、位址或分組可能改變。更新前後名稱相同的紀錄，不一定能直接串成同一條時間線。
On Demand 也會影響觀察時段。若測試期間自動中斷或重新連線，可前往 Settings → On Demand 核對觸發條件，並記錄實際連線狀態。它管理的是連線行為，不能據此判定某個請求命中了 PROXY 或 DIRECT；路由判斷仍須回到 Global Routing 與請求紀錄。
六、常見讀數問題與排查順序
明明開啟了 App，伺服器流量為什麼沒有增加？
先確認頁面是否來自快取，再到 Home 檢查連線狀態與 Global Routing。若目前選的是 Direct，或 Config 規則將目標送往 DIRECT，代理伺服器項目沒有增加可能是正常情況。請重新執行一次連網操作，並核對該請求的目標與出站。
App 都關了，Data 的數字還在增加，是規則出錯了嗎？
先停止其他傳輸，記錄連續兩個 60 秒時段的增量，再檢查是否有背景連線或仍在傳輸的長連線。僅憑前景沒有操作，無法判定流量異常；應先找出目標與連線，再決定是否調整規則。
按 App 統計的數字加總後，為什麼不等於伺服器總量？
先確認時間範圍、網路類型與上下行的統計口徑，再檢查 App 歸屬資訊是否完整、是否有未歸屬紀錄，以及是否包含 DIRECT 流量。若比較的是系統行動網路統計與 Data，不必要求兩者相等，更不能把差額全算在某個 App 上。
修改規則後，統計看起來還是走原本的伺服器？
先在 Config 確認啟用的是修改後的檔案，再到 Home → Global Routing 選擇 Config。結束舊連線後重試；若結果仍不符，請檢查前置規則與 FINAL。必要時重新連線，但應先保存測試基準值，避免混算重新連線前後的累計數字。
完整的排查紀錄應包括測試時間、網路類型、Global Routing 選擇、啟用的設定、目標請求與上下行增量。若要進一步排查，可參閱疑難排解手冊核對連線與規則，或在術語手冊確認策略關鍵字。Data 適合用來觀察趨勢與驗證假設；最終的分流判斷，應根據具體請求及其實際出站資訊。