本文重點

Data 用來查看 Shadowrocket 記錄到的流量，不是行動網路帳單，也不能單憑數據證明某個網站採用了哪條策略。本文適合已有自己的服務商與訂閱、且已能連線的使用者，說明依伺服器與依 App 統計的差異，並提供「記錄基準值、送出請求、查看增量、核對規則」的排查步驟。不同 Apple 平台及介面提供的統計維度可能不同，請只根據目前頁面實際顯示的項目判斷。

1. 先區分累計流量、即時速率與計費流量

Shadowrocket 是在 App Store 發行的 Apple 平台付費用戶端，主要供 iPhone 和 iPad 使用。可在產品頁核對開發者 Shadow Launch Technology Limited 與 App ID 932747118；系統需求以 App Store 頁面標示為準。Data 中的數值是用戶端觀察到的結果，不能取代電信業者或你所使用服務的計費紀錄。

查看某一列時，先確認名稱、單位與統計範圍。上傳通常是裝置向外傳送的資料，下載通常是裝置接收的資料；兩者都以裝置的方向理解，而不是遠端伺服器的方向。以每秒為單位的數值代表速率，只有位元組單位的數值才是資料量。若介面未明確標示「本次連線」或時間範圍，請勿自行將累計數值解讀為當日流量。

8 bit
等於 1 B；小寫 b 與大寫 B 的意義不同
B/s
每秒位元組數，屬於速率，不是累計資料量
443
HTTPS 常用連接埠；僅憑連接埠無法證明流量經由 PROXY

連線閒置時，累計量仍可能增加。背景同步、通知、DNS 查詢、連線保活與重試都可能產生資料；但沒有請求明細時，不能只憑這些數字判斷是哪一項造成。反過來說，即使網頁已顯示，新增下載量很少也可能只是讀取了本機快取。

2. 依伺服器查看數據：觀察出站流量，不是手機總用量

依伺服器查看時，先確認它對應 Home 中目前使用的伺服器。名稱相同不代表連線參數也相同；重新命名、切換伺服器或更新現有訂閱後，比較紀錄時還要核對位址、連接埠與實際選擇結果。伺服器維度回答的是「用戶端將多少流量歸到這個出站」，而不是「手機上所有 App 總共用了多少流量」。

觀察項目可以得出的結論無法直接得出的結論
某伺服器的上傳增量在該統計範圍內，傳送至此出站的資料增加增加的資料全都來自前景 App
某伺服器的下載增量在該統計範圍內，經由此出站接收的資料增加增加量等於某個檔案標示的大小
舊伺服器仍有累計值頁面仍保留該項目的歷史統計目前的請求仍在使用舊伺服器
伺服器數據沒有變化觀察期間，該項目沒有可見增量請求一定走了 DIRECT，或連線一定失效

若請求走 DIRECT，就不需要經過代理伺服器轉送，因此不應把某個代理伺服器的數據當作直連流量總表。另一方面，介面上的總計可能與單一伺服器的統計範圍不同；只有確認時間範圍、篩選條件與重設基準一致後，才適合比較或加總。

3. 依 App 查看數據：先確認識別能力，再解讀流量

依 App 與依伺服器是兩種不同的統計方式：前者試圖回答「資料來自哪個來源」，後者回答「資料經由哪個出站」。同一個 App 可能同時存取多個網域，也可能部分請求直連、部分請求經由代理，因此 App 的累計量不一定等於某一個伺服器的累計量。

尤其在 iPhone 和 iPad 上，不應將隧道可見的網路流量等同於完整的處理程序身分資訊。若目前的 Data 介面沒有 App 清單，就不必尋找不存在的通用「依 App」開關；若有顯示 App 統計，也應以頁面實際識別的結果為準。對於無法識別或無法明確歸屬的紀錄，不要任意算到剛開啟的 App。

若要確認某個 App 是否使用行動網路，也應查看系統「設定 → 行動服務」中該 App 的統計，並核對系統統計週期。系統行動網路數據不包含相同範圍內的 Wi-Fi 用量；Data 則須依當時的連線狀態與頁面統計方式解讀，兩者不是同一份帳單。

4. 判斷 PROXY 或 DIRECT：先看路由模式，再核對命中結果

Data 顯示統計結果，Global Routing 則決定請求採用哪種路由方式。排查規則時，先前往 Home → Global Routing 確認目前模式，再到 Config 核對實際啟用的配置。Proxy 與 Direct 分別用於全域代理與全域直連；Config 會依配置中的規則分流。Scene 則須依所選場景的具體設定判斷，不能只憑名稱認定它等同於 Config。

產生請求 路由模式 比對規則 實際出站 統計歸集

以下是用來說明規則順序的最小範例，並非完整配置。example.com 是示範網域，不能用來取代你實際需要核對的目標；PROXY 也必須有現成且可用的代理出站，才能完成轉送。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT

解讀規則範例

DOMAIN-SUFFIX
example.com,PROXY：比對此網域及其子網域。
IP-CIDR
192.168.0.0/16,DIRECT,no-resolve：比對相應的位址範圍，不會為此規則主動解析網域。
FINAL
DIRECT：前面的規則都未命中時，使用直連。

規則由上而下比對；此範例僅供說明，修改前請先保留原配置。

確認執行條件

Home → Global Routing
使用 Config 測試規則，並確認是否切換過 Scene。
Config
確認選取的檔案確實包含測試規則。
Settings → On Demand
檢查自動連線條件是否會影響測試期間的隧道狀態。

On Demand 負責依條件連線，不能用來證明網站採用 PROXY 或 DIRECT。

更可靠的依據是目標請求對應的規則與實際出站紀錄。若目前介面提供連線或請求明細，請依網域、目標位址與時間找到同一次請求，再核對命中的規則及策略。伺服器計數增加只能作為輔助驗證，因為同一時間可能還有其他請求使用該伺服器。

5. 以前後差值進行一次可重現的流量測試

不必先清除所有歷史統計。保留歷史數值並記錄測試前後的讀數，可以避免誤刪參考資料，也不必依賴介面是否提供重設按鈕。以下流程只使用你已有且有權存取的目標，不需要更換或新增服務。

  1. 固定測試環境：選定 Wi-Fi 或行動網路，測試期間不要切換網路；暫停進行中的大型檔案傳輸，並記下 Home 目前的伺服器與 Global Routing 模式。
  2. 記錄基準值：進入 Data，記下目標伺服器的上傳、下載數值與單位；若有依 App 統計，也一併記錄對應 App。等待約 30 秒，觀察閒置時數值是否仍明顯增加。
  3. 只執行一項操作：開啟一個目標網頁，或讀取自己已有的測試檔案。不要同時執行多項測試；記下開始與結束時間，並留意重新導向後的網域。
  4. 查看增量：等待頁面統計更新，再以結束數值減去開始數值。若顯示精度較低，小型請求可能暫時看不出變化，請勿立刻判定為零流量。
  5. 交叉核對：綜合目標請求命中的規則、實際出站與計數增量進行判斷。若要更改配置，一次只修改一項條件後重做測試，結束後還原原設定。

6. 常見數據疑問與處理方式

網頁能開啟，但伺服器流量沒有增加，是不是沒走代理？

先排除頁面快取，再核對 Home → Global Routing 與 Config 中啟用的規則。若實際命中 DIRECT，代理伺服器沒有相應增量是正常情況；若命中 PROXY，請檢查是否看錯伺服器項目、數據是否尚未更新，以及請求是否確實重新送出。

為什麼 Data 的數據比下載檔案大小多？

先暫停其他傳輸，再以前後差值重新測試。檔案標示的大小只代表檔案內容；統計數據可能同時包含其他請求、標頭、連線維護或重試。實際計入哪些項目應以頁面的統計方式為準，不能用固定比例反推檔案大小。

切換伺服器後，舊伺服器仍有數值，需要刪除嗎？

先區分累計值與新增值。記下舊項目的數值，等待一段時間並送出一次明確請求，再觀察數值是否變化。只要舊數值沒有新增，通常只是歷史參考；不要只為了讓頁面「歸零」就刪除現有伺服器或配置。

系統行動網路統計與 Data 差很多，哪個才是方案用量？

電信方案用量應以電信業者的計費紀錄為準。先在系統「設定 → 行動服務」核對統計週期，再排除 Wi-Fi 用量、重設時間不同與背景資料。Data 適合用來排查用戶端可見的流量分布，不會顯示方案剩餘額度。

依 App 統計清單找不到目標 App，可以直接按網域把流量算給它嗎？

不能直接這樣歸屬。多個 App 可能共用網域，網頁也可能載入第三方資源。請先針對單一 App，在短時間內重複測試；若介面仍無法確認來源，就應保留「無法明確歸屬」的結論，而不是把伺服器增量全算到該 App。

7. 保存排查紀錄時，保留統計方式並隱藏敏感資訊

可供複核的紀錄應包含測試時間、網路類型、Global Routing 模式、啟用的 Config、目標網域，以及同一項目測試前後的差值。若要向自己的服務商說明問題，再補上錯誤現象與實際命中的策略。只有累計總數而沒有時間範圍，通常無法定位單次請求。

結論應寫成「在這次測試期間，該請求命中某條規則，且對應出站出現增量」，而不是「Data 有數值，所以所有流量都走了代理」。分開記錄規則與統計的依據，才能區分路由錯誤、快取影響、背景用量與統計方式差異。