Data 用于观察 Shadowrocket 处理的流量，不等同于设备蜂窝用量或服务商账单。本文适合已经从你的服务商处获取订阅与节点、需要核对用量的用户：先分清累计流量与实时速率，再按服务器和应用归因查看，最后用同一时间窗口的增量判断差异。
先分清 Data 读数、实时速率与套餐用量
Shadowrocket（小火箭）的本地统计、系统网络统计与服务商后台分别观察不同位置。Data 中的读数应结合当前统计分类和记录范围理解，不能直接当成整台 iPhone 或 iPad 的总用量，也不能据此推算套餐必然扣除了多少。页面上的单位、分类标题和记录起点，比单个数字更重要。
上传通常指设备向外发送的数据，下载通常指设备接收的数据。例如播放视频以下载为主，但仍会产生请求、确认和其他上行通信。若看到带有 /s 的单位，那是速率；没有时间分母的字节数才是累计数据量。某一瞬间的速度高，不代表整个统计周期都保持同样速度。
例如，理论上 8 Mbps 对应 1 MB/s，换算时尚未扣除协议开销。MB 与 MiB 也不是同一个单位：1 MB 是 1,000,000 字节，1 MiB 是 1,048,576 字节。比较两个页面前，应先确认其单位定义；只看到缩写相近，不能认定它们采用相同换算方式。
按服务器查看：确认流量实际经过哪个出站
按服务器查看，关注的是代理出站的使用情况：哪个服务器条目承接了请求，流量集中在哪个条目，切换之后新请求是否转移。这里的服务器条目与服务商套餐不是一一对应关系。同一套餐可以包含多个服务器，多个设备也可能使用同一套餐；本机某一条目的累计值因此不能代表整个账户的用量。
- 先在 Home 确认当前选择的服务器，并记录名称。若有多个同名条目，还要核对地址和端口，避免把不同条目混为一项。
- 检查 Global Routing。使用 Config 时，请求按配置规则决定去向；使用 Proxy 与 Direct 时，普通请求的出站选择不同，不能直接横向比较。
- 进入 Data，查看页面提供的服务器统计，记录相关条目的上传、下载及记录范围。具体分类入口以当前页面显示为准。
- 完成一项短时操作后，再读取同一条目的数字。以增量确认它是否承接了这项操作，不要只看历史累计值的大小。
切换服务器不会让所有既有连接立即变成新连接。视频流、长连接或后台传输可能继续使用原连接，直至断开或重建。因此，切换后旧条目仍有少量增长，并不能单独证明选择没有生效。用于对照时，应结束测试任务，重新发起请求，再观察新一轮增量。
判断方法：先比同一条目的增量
需要判断当前服务器是否被使用时，固定 Global Routing 和测试任务，分别记录操作前后读数；不要拿一个条目的长期累计值与另一个条目的短期读数比较。
按应用查看：用于归因，不等于系统完整清单
按应用视角回答的是“这些被观察到的连接可以归到哪个来源”，而不是“设备上每个应用消耗了多少运营商流量”。Apple 平台对应用身份识别存在权限和系统能力边界。Data 若提供应用分类，应以实际可见的分类与归因结果为准；没有列出某个应用，不能推断它没有联网，也不应要求每条连接都能准确对应到应用名称。
一个前台操作可能触发多个服务请求，后台同步也可能与它同时发生。反过来，多个应用可能访问同一个域名或共用系统服务。仅凭域名、服务器地址或连接时间，通常不足以唯一确定发起应用。查看应用维度时，应把它当作排查线索，再通过单项操作验证。
服务器视角记录单
- 入口
- Home 确认选择，Data 查看统计
- 对象
- 具体服务器条目与代理出站
- 前置条件
- 记录 Global Routing 当前姿态
- 比较方法
- 相同条目、相同时间段的增量
适合检查出站使用情况，不用于代替账户账单。
应用视角记录单
- 入口
- Data 中实际提供的应用分类
- 对象
- 能够被观察和归因的连接
- 前置条件
- 确认分类存在及其显示范围
- 比较方法
- 暂停其他任务，单独操作目标应用
适合寻找流量来源，不能替代系统蜂窝用量统计。
如果目的是排查蜂窝套餐消耗，应同时到系统 Settings 的 Cellular 或 Mobile Data 页面查看对应应用用量，入口名称随系统语言和地区变化。系统蜂窝统计与 Shadowrocket 本地统计的周期需要分别核对；Wi-Fi 下产生的数据也不能拿来解释蜂窝账单。
按步骤做一次可复核的流量对照
一次有效对照不需要清空所有历史记录。保留原始读数，通过前后相减就能计算增量，也能避免丢失后续排查需要的信息。下面是一组演算示例，不是实测结果或产品性能承诺。
- 固定环境：选择一种网络，保持同一个服务器与 Global Routing 姿态，暂停云端同步、应用更新和其他设备上的同账户传输。
- 记录起点：写下时间、Data 中的上传与下载读数，以及服务商后台显示的用量和刷新时间。订阅信息中的剩余用量也可能是上次刷新时的数据。
- 执行单项任务：只打开一个目标应用，进行一次能够明确开始和结束的操作。网页缓存和视频预加载都会改变实际传输量，不把页面标称文件大小当作网络读数。
- 记录终点：任务结束后等待连接趋于空闲，再读同一组字段。服务商后台若延迟汇总，等它刷新后再记录，不反复执行任务补数。
- 计算差值：分别计算上传增量与下载增量，保存测试时段，再依据服务商公开的计量规则比较。
| 记录项目 | 操作前 | 操作后 | 本次增量 |
|---|---|---|---|
| 上传累计 | 20 MB | 22 MB | 2 MB |
| 下载累计 | 100 MB | 150 MB | 50 MB |
| 上传与下载合计 | 120 MB | 172 MB | 52 MB |
这组示例只能说明本地所选统计范围增加了 52 MB。它不能自动证明服务商也应扣除 52 MB，更不能证明目标应用的有效内容恰好为 50 MB。是否同时计算上下行、是否有倍率、是否还有其他设备使用，都需要独立核实。
读数不同的原理：观察位置与分流结果不同
这条流程说明统计为什么不能简单对齐：应用产生内容请求，Shadowrocket 处理进入其接管范围的连接，规则决定出站方式，服务商在自己的网络边界统计。流程中的每个观察点都可能采用不同的字节范围和汇总周期。Direct 流量不会因为经过本地处理就自动成为代理服务器的套餐消耗。
在 Global Routing 使用 Config 时，Config 中的规则自上而下匹配，首条命中决定策略。以下只是规则语法示例，不是要求替换现有配置；实际策略名称应以你的配置为准。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY示例中，匹配 example.com 及其子域名的请求采用 DIRECT；随后由 GEOIP,CN,DIRECT 处理匹配的 IP；尚未命中的请求交给末尾 FINAL,PROXY。因此，同一次浏览操作可能产生不同去向的连接。只看本地合计，而忽略具体策略，是对账时常见的误差来源。
- 协议封装：TLS、代理协议头和连接维护会产生额外数据；应用内容大小、隧道传输字节与服务器网卡字节不是同一概念。
- 重传与重连：网络不稳定会带来额外传输，但不同统计位置对重传的覆盖范围不同，不能用固定百分比统一修正。
- 账户聚合：后台可能汇总同一账户的多个服务器、多个设备以及上传和下载，而本地只显示当前设备的一部分记录。
- 计量规则：计费倍率、结算周期、时区和后台刷新间隔均可能造成差异，应从你的服务商处获取具体说明。
- 自动连接：Settings → On Demand 中的条件可能让隧道自动建立，后台同步也会随之产生传输；熄屏不等于所有网络活动停止。
对账前先统一四个条件
把设备范围、起止时间、上下行范围和单位统一后再比较。仍有持续差异时，保留同一测试窗口的两端记录，再向你的服务商核对计量规则。
常见问题：归零、后台增长与上传异常
Data 数字变小或归零，是套餐恢复了吗？
不能这样判断。先检查所选服务器、分类和记录范围是否改变，再核对是否执行过重置、重新安装或恢复相关操作。本地记录变化不等于服务商账单变化；套餐剩余量应在对应账户后台确认。
没有打开网页，为什么流量还在增加？
先暂停照片同步、文件传输和媒体播放，再查看增量是否明显下降。随后检查 Settings → On Demand 的自动连接条件。后台通知、同步与既有连接都可能继续产生数据，不能仅凭前台没有操作就认定统计异常。
上传比预期多，应该检查什么？
先记录五分钟内的上传增量，检查是否有云端备份、视频通话或文件上传；若 Data 提供应用归因，再针对相应条目逐项暂停验证。不要仅凭累计上传大于下载，就把原因归结为服务器故障。
重置 Data 能让服务商用量重新计算吗？
本地统计重置只影响本地记录，不改变服务商计量。若当前界面提供重置功能，先保存记录并阅读确认提示；为了做一次对照，优先用前后差值，不必重置。不要预设重连、更新订阅或更换服务器会清除账户用量。
处理流量问题时，先留存数据，再改变设置。向服务商提供起止时间、单位、服务器条目和上下行增量通常已经足够；分享记录前，应遮盖订阅地址中的凭据、账户标识和访问记录中的私人信息。后续需要检查分流或首次连接步骤，可继续阅读本站使用说明。