如果你已經連上自己的伺服器,卻在 Data 頁看到依伺服器與依 App 兩組數字對不上,或者發現它與 iOS 設定裡的用量統計差了一截,這篇說明依「入口 → 單位 → 兩組基準 → 差異原因 → 排查順序」的順序講清每一處讀數的含義,並提供一套可重現的定位流程。適合已經完成訂閱匯入、想用讀數判斷流量去向的讀者。全文以你已有自己的服務商與訂閱為前提,文中的伺服器名稱與數字僅作排布示範。
Data 頁在哪裡,兩組讀數分別統計什麼
打開 Shadowrocket,底部標籤列的 Data 就是流量統計頁。頁面頂端是這段時間的總量,上行與下行分開顯示;下方依分組列出明細,在頁面頂端切換分組,即可在「依伺服器」與「依 App」兩種視角之間切換。連線開關關閉時流量不經過隧道,頁面上的數字不會成長,所以看到讀數靜止,先回 Home 確認頂端的連線開關狀態。
兩組讀數的統計對象並不相同。「依伺服器」統計的是歸屬到某個伺服器項目的連線位元組數,只有真正經由該伺服器轉送的連線才會出現在這一列;「依 App」統計的是發起連線的 App,只要連線經過了隧道,無論最終走代理還是直連,都會記到對應項目名下。因此同一段時間裡,兩組讀數的合計通常不相等,差額來自命中 DIRECT 的連線、DNS 查詢以及被 REJECT 的連線。
先看哪一組,取決於你要回答的問題:想知道流量落到哪台伺服器,看依伺服器;想知道流量由誰發起,看依 App。兩組搭配使用,才能把「某個 App」與「某台伺服器」對應起來。
單位與讀法:上行、下行、總量怎麼對
每筆讀數都分上行與下行。上行是裝置送出的位元組,下行是裝置接收的位元組,兩者不會合併成一個數字,因為它們的排查意義不同:下行異常通常說明有內容在下載或同步,上行異常則更可能與上傳、備份、心跳請求有關。
單位依 1024 進位逐級換算,依次是 B、KB、MB、GB,顯示時自動選擇合適的一級,所以同一行在不同時間可能以 MB 或 GB 出現。讀數的基準是隧道內的位元組數,包含加密與封裝帶來的額外開銷,通常略大於實際內容大小;一個 1 MB 的檔案下載完成,讀數顯示 1.0x MB 屬於正常。
總覽 ↑ 15.6 MB ↓ 412.3 MB
依伺服器 Server A ↑ 12.4 MB ↓ 386.2 MB
依伺服器 Server B ↑ 1.8 MB ↓ 24.9 MB
依 App Safari ↑ 3.1 MB ↓ 208.7 MB上面的排布只是示範,數字不是實測值。實際列表中每一行還會顯示佔總量比例,方便快速判斷哪一項最大;比例與絕對值一起看,比只看總量更容易發現異常。
依伺服器讀數:流量落在哪台伺服器上
「依伺服器」列表裡的每一行對應 Home 頁伺服器列表中的一個項目,名稱與 Home 裡顯示的一致。切換伺服器後,新流量記到新項目上,舊項目的歷史讀數不會自動歸零,除非在 Data 頁手動把讀數歸零,或刪除對應項目。
這一組讀數能直接回答兩個問題:目前流量是否落在你預期的伺服器上;某台伺服器是否在你沒有操作的情況下持續產生流量。前者用來核對 Global Routing 與 Config 規則是否按預期運作,後者用來發現設定裡被遺忘的項目。
| 讀數分組 | 統計對象 | 包含 | 不包含 |
|---|---|---|---|
| 依伺服器 | 歸屬到某個伺服器項目的連線 | 經該伺服器轉送的上行與下行位元組 | 命中 DIRECT 的連線、DNS 查詢、被 REJECT 的連線 |
| 依 App | 發起連線的 App | 該 App 經隧道處理的全部連線,含命中 DIRECT 的部分 | 連線開關關閉期間產生的流量 |
如果列表裡出現了你不認識的項目,先回 Home 核對伺服器列表。項目名稱與 Home 一致,通常來自你自己匯入的設定或手動新增的伺服器,不會憑空多出項目。
依 App 讀數:流量從哪個 App 出去
「依 App」列表把流量歸到發起連線的行程上。同一個網域的請求由不同 App 發出時會分別記帳,所以它能回答「是誰在跑流量」,這一點系統層級統計做不到:系統的用量統計只依網路介面彙總,無法把位元組歸到具體 App。
Global Routing 的姿態會直接改變兩組讀數的分布。Config 姿態下,命中規則的連線計入對應伺服器,命中 DIRECT 的只出現在依 App 列表;Proxy 姿態下,全部連線集中到目前選取的伺服器,依伺服器列表幾乎只剩一行在成長;Direct 姿態下,依伺服器讀數基本停止成長,依 App 讀數仍在累計。
設定(Config)
推薦依規則分流:命中規則的連線走對應伺服器並計入該伺服器,命中 DIRECT 的連線只出現在依 App 列表。
適合:日常主力,需要看清哪類流量走了代理
代理(Proxy)
全部連線交給目前選取的伺服器,依伺服器列表會集中到一行,便於核對總量與隧道開銷。
適合:臨時全域,核對讀數總量
直連(Direct)
全部連線直連,依伺服器讀數不再成長,依 App 讀數繼續累計,兩組數字的差值變得最直觀。
適合:驗證規則是否誤命中、臨時對照
排查規則是否誤命中時,Direct 姿態是一個乾淨的對照組:切到 Direct 後再做一次同樣的操作,如果依 App 讀數的增量與之前一致,說明這段流量本來就在直連,與規則無關。
為什麼和 iOS 系統統計對不上
iOS 的「設定 → 行動網路」裡能看到本計費週期的行動數據用量,它統計的是行動網路介面上的全部位元組,包含所有 App 的連線,不管是否經過隧道;Shadowrocket 的 Data 頁統計的是經過隧道的位元組,Wi-Fi 與行動網路都算在內。兩者取樣位置與涵蓋範圍都不同,數字不同是必然的。
常見的差異來源有這幾類:
- 統計範圍:系統用量涵蓋介面上的全部網路活動,Data 頁只涵蓋經過隧道的部分;連線開關關閉期間的流量完全不計入 Data 頁。
- 介面範圍:行動數據用量只統計行動網路介面,而 Data 頁把 Wi-Fi 與行動網路一併計入,在 Wi-Fi 環境下兩邊的差距最明顯。
- 歸零時間:系統用量依計費週期或手動重置歸零,Data 頁有自己的歸零操作,兩者不會同時歸零。
- 協定開銷:隧道內的位元組包含加密與封裝標頭,同一段內容在 Data 頁的讀數通常略大於原始內容。
- 歸屬方式:系統依 App 彙總介面用量,Data 頁依伺服器與依 App 兩個維度分組,分組維度不同,無法逐行對齊。
結論:只用 Data 頁做相對比較
Data 頁的絕對值不必與系統統計對齊,它的價值在於同一段時間內的相對分布。判斷異常時,看的是某一行的增量是否與你的操作對得上,而不是總數是否等於系統裡的那個數字。
用 Data 頁定位異常流量的順序
下面這套順序用於回答「某個 App 是不是在偷偷跑流量」。它依賴兩個前提:先建立乾淨的基準,再只做一次操作,避免多個變數混在一起。
確認連線已開啟
在 Home 頂端確認連線開關處於開啟狀態。關閉狀態下流量不經過隧道,Data 頁不會產生新讀數,後續步驟都會失去意義。
歸零基準
在 Data 頁把兩組讀數歸零,並記下歸零的時刻,方便與系統用量對照。
只做一個操作
回到要觀察的 App,做一次明確的操作,例如打開一個頁面並等它載入完成,其餘 App 保持不動。
先看依 App
切到依 App 分組,看哪一行的增量最大;這一行就是本次操作的發起者。
再看依伺服器
切到依伺服器分組,確認增量落在你預期的伺服器上;若完全沒有增量,說明這次連線命中了 DIRECT。
對照路由姿態
如果增量出現在預期之外的伺服器上,回 Home 檢查 Global Routing 姿態與 Config 規則,確認是否有規則被提前命中。
把第 3 到第 5 步重複兩三次。如果每次的增量都落在同一行,基本可以確認流量來源;如果增量忽大忽小,可能是 App 的背景重新整理或推播在同時發起連線,這時把 App 切到背景再觀察一輪。
結論:先依量級分類,再決定查什麼
兩組讀數對不上時,先看差額的量級:差額只有幾 MB,通常來自 DNS 查詢與被 REJECT 的連線;差額達到幾百 MB,更可能是某個 App 的流量命中了 DIRECT。先分類再動手,順序顛倒會把正常現象當成故障。
常見疑問
依伺服器加起來比總量少一截,是掉資料了嗎?
不是。總量統計隧道內的全部位元組,依伺服器只統計歸屬到具體伺服器的部分;命中 DIRECT 的連線、DNS 查詢與被 REJECT 的連線都只出現在依 App 一側。把依 App 的合計與總量對照,通常更接近。
Data 頁數字一直是 0,怎麼讓它動起來?
先回 Home 確認連線開關已開啟,再確認 Global Routing 沒有停在 Direct;兩者都正常,就打開任意網頁觸發一次連線,讀數隨後就會出現。
換了伺服器以後,舊伺服器的讀數會自動歸零嗎?
不會。讀數依伺服器項目分別累計,換伺服器只是把新流量記到新項目上;要歸零需在 Data 頁手動重置,或刪除對應項目。
為什麼依 App 列表裡有我不認識的項目?
部分連線由系統服務或背景行程發起,沒有可歸屬的前景 App,會顯示為系統或未知項目。這類項目通常量很小;若某一項持續成長,再回 Home 核對伺服器列表與 Config 規則。