Data 是查看流量的入口，不是服務商帳單，也無法單憑統計確認某條規則是否命中。本文適合已有服務商與訂閱、且已完成連線的使用者，說明伺服器歸屬、App 歸屬、上傳下載及累計讀數的差異，再透過固定測試步驟與連線記錄交叉確認分流結果。判斷時應比較測試前後的增量，而非只看總量。
一、Data 記錄的是流量，不是購買額度
Shadowrocket（小火箭）的 Data 可查看 App 記錄到的網路活動。先在 Home 確認連線狀態，再開啟 Data 查看統計。統計只反映相應記錄範圍內的活動；連線關閉期間、未進入隧道的流量，以及由系統透過其他路徑處理的活動，都不能據此認定已計入。
上傳是裝置向外傳送的資料，下載則是裝置接收的資料。瀏覽網頁也會產生上傳流量，因為請求、標頭和互動資料都需要傳送。上傳讀數增加不代表正在上傳檔案；下載讀數增加也不代表網頁內容已完整顯示。
這個流程是為了說明觀察順序，並非 App 內部實作示意。規則決定連線的路由，統計則反映連線收發的資料量。即使連線失敗，過程中也可能交換少量資料，因此「數字增加」只能證明有活動，不能直接證明連線成功。
二、依伺服器與依 App 統計：兩種歸屬不可重複相加
查看伺服器統計時，重點是某個伺服器項目承載了多少傳輸量；查看 App 統計時，重點則是流量歸屬於哪個來源。這兩種檢視是以不同維度整理網路活動，並非兩份互不相關的流量。不可將伺服器總量與 App 總量相加，當作裝置的總用量。
| 觀察維度 | 適合回答的問題 | 無法單獨推斷的內容 |
|---|---|---|
| 依伺服器 | 測試期間，哪個伺服器項目的收發讀數增加？ | 不能只憑總量確認特定網域命中了哪條規則。 |
| 依 App | 哪些已識別的來源產生較多流量？ | 不能據此認定該 App 的所有連線都使用相同的出站路由。 |
| 上傳與下載 | 這次操作主要產生傳送還是接收資料？ | 不能直接等同於檔案大小或服務商扣除的額度。 |
| 累計讀數 | 目前統計範圍內累積了多少活動？ | 不能將所有歷史流量都歸因於剛修改的設定。 |
App 歸屬應以目前 Data 實際提供的分組與識別結果為準。Apple 平台的網路隧道不保證每條連線都能取得明確的 App 名稱；未識別來源、系統程序或合併記錄，不宜勉強歸類至特定 App。若目前頁面沒有相應分組，請勿將網域清單當作 App 清單。
同一個 App 可能同時連線至登入介面、圖片網域和內容傳遞網域，這些連線可能符合不同規則。因此，「這個 App 下載了很多資料」不等於「這個 App 的所有流量都經過某台伺服器」。若要確認分流，還需查看目標位址和實際出站記錄。
判斷方式：用伺服器增量找出站，再用連線記錄確認目標
先找出測試期間讀數增加的伺服器項目，再核對同一時段的目標網域、匹配規則與實際策略。只有時間、目標和出站方式都能互相對應，才能將這次增量歸因於正在測試的請求。
三、先確認 Global Routing，再判斷規則是否生效
在 Home → Global Routing 查看目前模式。Proxy、Direct、Config、Scene 的選擇會影響流量路由方式。測試設定檔中的規則時，應確認目前使用 Config，並在 Config 中確認已選取正確的設定檔；只編輯檔案卻未選用，統計不會自動反映該檔案的設定意圖。
- Proxy：以代理模式處理流量。此時伺服器讀數增加，不能證明設定檔中的某條分流規則已命中。
- Direct：以直連模式處理流量。代理伺服器讀數沒有增加，不一定表示連線開關或統計功能異常。
- Config：依據目前設定進行分流。須檢查規則順序、策略名稱與最終規則，才能解讀出站結果。
- Scene：依據場景設定決定路由方式。測試前應確認實際生效的場景，不能只看首頁選取的伺服器名稱。
以下設定卡僅供核對項目，不必直接取代現有設定。example.com 與 192.0.2.0/24 僅用於語法說明，不提供可用服務。PROXY 的最終出站方式仍須配合目前選取的伺服器或策略組確認。
規則匹配核對
- DOMAIN-SUFFIX
DOMAIN-SUFFIX,example.com,PROXY- IP-CIDR
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve- GEOIP
GEOIP,CN,DIRECT- FINAL
FINAL,PROXY
規則依序匹配；FINAL 是最終備援規則。no-resolve 表示不會為該 IP 規則主動解析網域。
測試環境核對
- Home → Global Routing
- 測試設定檔規則時，確認目前使用 Config。
- Config
- 確認目前選用的設定檔及規則內容。
- Settings → On Demand
- 檢查自動連線條件是否影響測試期間的連線狀態。
- Home
- 確認目前選取的伺服器及相關策略組。
每次只變更一個條件，避免在同一輪測試中混合路由切換、伺服器切換與自動連線。
四、透過短時間測試核對流量增量
有效比較必須使用相同的統計範圍。先記下目前數值，再執行單一操作，最後計算差值。無須每次測試都清除歷史記錄；若使用目前介面提供的重設功能，請先保存需要的讀數並記下重設時間。不要假設切換伺服器或中斷後重新連線一定會清除累計值。
- 記錄基準值：在 Data 記下目標伺服器的上傳與下載數值，以及記錄時間。確認 Home 的連線狀態與 Global Routing。
- 減少干擾：暫停進行中的大型檔案傳輸、影片播放及同步工作。保留必要的系統活動，不要把背景流量誤認為完全消失。
- 執行單一操作：開啟一個自己有權存取且可重複測試的頁面，等待載入完成。記錄實際存取的網域，以及開始和結束時間。
- 讀取差值：返回 Data，以結束讀數減去基準值。兩個數值必須來自同一項目、同一方向及同一單位。
- 交叉確認：在可用的連線詳細資料或記錄中，查找對應時段並查看目標、規則及策略。若記錄不足，維持條件不變再測一次。
以下為計算方式範例，並非產品實測結果。假設某伺服器的下載讀數從 120 MB 增至 126 MB，上傳讀數從 8.0 MB 增至 8.2 MB，則顯示值的增量分別為 6 MB 和 0.2 MB。這些是該時段的統計增量，不應直接解讀為「這個網頁剛好有 6 MB」。
下載增量 = 126 MB - 120 MB = 6 MB
上傳增量 = 8.2 MB - 8.0 MB = 0.2 MB
比較條件 = 同一項目 + 同一統計範圍 + 同一單位顯示值經過四捨五入時，小型請求的變化可能暫時看不出來。網頁快取也會減少重新傳輸的資料量。若第二次載入明顯較快且讀數只略有增加，請先檢查是否使用快取，不要立刻判定規則失效。頁面跳轉、圖片和背景請求也可能連至其他網域，必須依實際連線核對。
五、常見讀數異常：先檢查記錄範圍
網頁可以開啟，為什麼伺服器流量沒有增加？
先檢查 Home → Global Routing 是否設為 Direct，或 Config 中是否匹配到 DIRECT。接著確認頁面不是從快取載入，並查看實際使用的是否為其他伺服器或策略組成員。請使用新的、可重複的網路請求確認，不要只重新整理已開啟的頁面。
沒有操作，下載讀數為什麼還在增加？
系統同步、接收訊息、背景重新整理及尚未結束的媒體連線，都可能持續收發資料。先停止明確可辨識的傳輸，再以固定時間區間觀察增量，同時查看該時段的連線記錄。不要只憑累計數字判斷是哪個 App 正在傳輸。
依 App 與依伺服器的總量為什麼對不上？
確認兩邊的統計範圍、重設時間、單位和分組條件。App 歸屬可能不完整，直連流量也不屬於特定代理伺服器。只比較能對應的同一時段；範圍不同的累計值不適合直接相減。
訂閱更新後，同名伺服器的讀數還能接續比較嗎？
先在 Home 確認該項目的實際伺服器位址、連接埠和協定。同名項目可能對應不同設定，更新也可能改變統計歸屬。記錄新的基準值後再測試，不要直接把更新前後顯示名稱相同的項目視為同一個出站。
另一種常見情況是自動條件影響了連線開關。前往 Settings → On Demand，檢查目前設定的連線條件，並記錄測試期間是否切換 Wi-Fi 或行動網路。On Demand 控制連線觸發條件，不會為每個 App 指派統計標籤；排查時應分開確認「是否建立隧道」和「流量歸屬於誰」。
六、確認規則分流生效所需的最低證據
Data 適合快速找出「哪個項目正在增加」，連線記錄則適合說明「流量為何經過這裡」。兩者搭配使用時，先固定目標與路由條件，再核對實際出站方式。不要只因某台伺服器排在統計清單第一位，就認定所有請求都經過它。
- 目標一致：記錄實際請求的網域或 IP，而不只是網頁標題。跳轉後的位址與資源網域也須分別檢查。
- 條件一致：在同一輪測試期間，固定 Home → Global Routing、Config 檔案，以及伺服器或策略組的選擇。
- 證據一致：連線記錄中的規則與策略符合預期，Data 中相應項目的增量也能對應測試時段。
- 結果可重現：排除明顯的背景傳輸與快取影響後，重複測試仍得到相同的出站判斷。
操作結論：先確認規則命中，再解讀用量
出站方式不符合預期時，先檢查 Global Routing 與規則順序；出站正確但用量不同時，再檢查統計範圍、快取和計算方式。不要為了解釋單一累計讀數，同時修改 DNS、協定和多條規則。
若要進一步排查連線失敗，請參閱疑難排解；若需整理設定檔與診斷思路，請參閱疑難手冊。排查時應以自己的既有設定與服務為基礎，不要以流量總量取代連線狀態判斷。