Shadowrocket 流量統計怎麼看？Data 頁面的伺服器與 App 用量說明

一、先了解 Data 的兩種統計維度

Shadowrocket（小火箭）的 Data 可查看流量統計。依伺服器查看，能了解「流量經過哪個代理伺服器」；依 App 查看，則能了解「哪些 App 產生了可歸屬的流量」。兩者是觀察同一批網路活動的不同角度，不能直接相加，以免重複計算。

進入 Data 後，先確認目前顯示的是伺服器維度還是 App 維度，再查看列表中的累計數值。不要直接把列表第一項當成目前連線的伺服器，也不要因某個 App 沒有獨立列出，就認定它沒有連網。系統能否提供 App 歸屬資訊，以及連線是否落在目前統計範圍內，都會影響顯示結果。

依伺服器統計時，同一個 App 可能先後使用不同伺服器；依 App 統計時，同一個 App 也可能同時建立直連與代理連線。因此，「某個 App 用了多少流量」和「某台伺服器用了多少流量」本來就不必一一對應。核對時請固定相同的時間範圍，不要拿不同時間讀取的總量比較。

二、如何判讀上傳、下載、累計用量與速率

以本機為觀察起點，上傳是向外傳送的資料，下載則是本機接收的資料。瀏覽網頁通常以下載為主，但傳送搜尋字詞、請求標頭及確認訊息也會產生上傳流量。上傳照片通常以上傳為主，但仍會收到伺服器確認與頁面回應，因此另一個方向的流量不一定是零。

檔案大小與統計增量不完全相同是正常情況。請求、加密封裝、建立連線及重傳都可能增加資料量；快取、壓縮與分段請求也會改變本次實際傳輸量。不同計數位置可能涵蓋不同層次的額外流量，不能只憑一個數字推斷所有流量都採用相同的統計方式。

請留意大寫 B 與小寫 b：B 代表位元組，b 代表位元，1 B 等於 8 b。若將 1 MB/s 換算為頻寬，大約是 8 Mbps，但也要留意 MB 與 MiB 的單位差異及通訊協定額外流量。Data 的累計位元組數本身不是測速結果。

三、依伺服器統計：用前後差值確認實際出站

依伺服器查看數值，最適合用來確認「這次請求是否使用預期的伺服器」。在 Home 選取伺服器，只代表選定代理出站對象；請求是否真的經由該伺服器處理，仍會受到 Global Routing 和規則影響。若 Global Routing 設為 Direct，請求會直接連線，不應只因已選取伺服器，就預期其代理流量持續增加。

1. 在 Home 確認連線狀態、目前伺服器與 Global Routing。若要檢查規則分流，請使用 Config 模式，並前往 Config 確認目前啟用的設定檔。
2. 進入 Data，記下目標伺服器目前的上傳量、下載量及記錄時間。暫停其他下載、雲端同步與串流播放，減少背景流量干擾。
3. 只執行一項可重現的操作，例如從有權限存取的網頁下載一個已知大小的檔案。不要同時切換伺服器或修改規則。
4. 操作完成後回到 Data，等數值更新，再記下新數值，以「操作後數值減操作前數值」計算增量。
5. 接著檢查對應連線的目標、命中規則與實際策略。伺服器增量可作為旁證，單筆連線記錄則能確認特定請求。

例如，以下僅為計算示例，並非實測結果：某伺服器的下載量從 120 MB 增至 132 MB，上傳量從 8 MB 增至 8.4 MB，則本次觀察期間的增量分別為 12 MB 與 0.4 MB。這表示該伺服器在觀察期間有流量，但不能據此認定這 12 MB 全都來自剛才開啟的網頁。

四、依 App 統計：分清 App 歸屬與連線策略

依 App 查看流量，適合找出背景下載、自動播放或同步工作造成的流量。先找到目標 App，再觀察同一段時間內的上下載變化。App 有流量不代表所有請求都經過代理：同一個頁面可能同時向主站、圖片網域、影片網域及統計介面發出請求，各自可能命中不同規則。

App 名稱如何顯示，取決於系統提供的資訊。遇到無法個別歸屬的項目，請保留這項限制，不要根據目標網域猜測 App 身分。瀏覽器中多個分頁的流量通常也無法只靠 App 總量區分；若要定位特定頁面，請縮短測試時間，並查看對應的目標連線。

• App 未在前景操作，但數值持續增加：檢查背景同步、預先載入、自動更新，以及仍在播放的媒體；先暫停相關工作，再重新記錄流量增量。
• 開啟頁面，但數值幾乎沒變：頁面可能是從快取讀取，或相關流量不在目前可歸屬的範圍內。請改用一次明確需要連網的新請求進行確認。
• App 總量與伺服器總量不同：先統一統計時間範圍，再確認是否包含直連請求、其他伺服器或無法歸屬的流量，不要勉強逐項配對。

如果裝置沒有顯示預期的 App 統計項目，不代表安裝異常。請先查看目前平台實際提供的統計項目；若 App 維度資訊不足，仍可透過伺服器增量與連線記錄驗證分流。

五、使用 Data 確認 Config 規則分流

Data 能呈現傳輸結果的變化，但不會說明每條規則為何命中。檢查規則時，請先確認 Home → Global Routing 設為 Config，再前往 Config 核對目前設定。Proxy、Direct 和 Scene 是不同的路由模式，不能把其他模式下的結果直接當成目前規則檔的驗證結論。

完整規則列由規則類型、比對值與策略組成；FINAL 則直接指定預設策略。以下僅為語法示意，並非適用於所有網路環境的分流方案；IP-CIDR 使用文件保留的位址範圍，避免指向真實服務。

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

規則會由上而下比對，符合後即停止。DOMAIN-SUFFIX 用於比對網域後綴，IP-CIDR 用於比對位址範圍；IP-CIDR 中的 no-resolve 表示不為這條 IP 規則主動觸發網域解析，並不代表整個 App 停止 DNS 查詢。FINAL 用來處理未符合前面規則的請求，必須放在需要優先判斷的規則之後。

1. 使用自己有權存取的實際目標，並將網域規則放在可能先行命中的廣泛規則之前。
2. 儲存後確認正在使用修改過的 Config。關閉舊頁面或結束舊連線，再發出新請求，避免舊連線影響判斷。
3. 在連線記錄中確認目標與命中策略，再對照 Data 的伺服器流量增量。若預期結果為 DIRECT，不能只因頁面能開啟，就判定代理已生效。
4. 測試完成後還原原本的設定。如果原先使用 Scene，請記下其選擇條件，以免切回後誤將路由變化當成統計故障。

六、流量不符、斷線後數值增加等常見問題

排查時不必同時修改通訊協定、DNS、規則與伺服器。每輪只調整一項，並記錄測試時間、網路類型、路由模式、前後數值與連線結果。如此才能分開判斷「背景流量」、「規則選擇」與「統計範圍」三種問題，也方便之後在相同條件下重現測試。