Data 适合观察流量增量与归属，不宜直接当作服务商账单或规则命中日志。本文以用户已有自己的服务商与订阅为前提，说明服务器与应用两种视角的区别、速率和累计量的换算、清零前的记录方法，以及用一次受控访问核对分流的步骤。不同平台展示的明细可能不同，操作时以当前 Data 实际提供的项目为准。
Data 统计范围：先区分流量归属与规则证据
Shadowrocket（小火箭）的 Data 页用于查看客户端记录到的流量。它不是整台设备所有网络活动的完整账本：未进入客户端处理路径的连接，不能据此判断用量；应用名称能否识别、能展示到什么粒度，也取决于平台和当前实现。看不到某个应用名称，不等于这个应用没有联网。
按服务器查看，主要回答“流量由哪个服务器承载”；按应用查看，主要回答“流量归属于哪个可识别的应用”。两者是观察同一批网络活动的不同分组方式，不是两份应当相加的消费记录。也不要把应用列表中的每一行都理解成经过代理：是否代理仍要结合实际路由与连接记录判断。
这条流程用于理解排查顺序，不表示界面中的每一种计数器都在同一个位置计数。统计可以提示“测试期间某个服务器有新增流量”，但不能单独证明“刚才访问的某个域名命中了指定规则”。后一个问题需要对照同一时段的请求或连接记录，查看目标、策略与实际出站。
上传、下载与累计量：先读单位，再比较增量
上传是从设备向外发送的数据，下载是设备接收的数据。打开网页时，上传请求与下载响应通常会同时出现；播放内容时也可能有确认包、进度上报等上传活动。因此，“只在看内容，上传却不为零”本身不是故障证据。速率描述某个采样时刻附近的快慢，累计量描述一个统计区间内已经传输了多少。
例如，假设同一统计项测试前显示下载 120 MB，测试后显示 138 MB，那么这个窗口的显示增量为 18 MB。这只是计算示例，不是实测结果，也不是网页文件大小的保证值。界面若使用四舍五入后的单位，短时间的小流量可能暂时看不出变化；应等待刷新，或延长观察窗口，而不是立即断定连接没有经过该路径。
| 看到的读数 | 可以回答 | 不能直接推出 |
|---|---|---|
| 当前速率，单位如 KB/s | 采样窗口内传输是否活跃 | 整个会话已经消耗多少流量 |
| 累计上传或下载，单位如 MB | 同一统计范围内的累计量 | 当前连接的实时速度 |
| 某服务器的累计增量 | 该统计项在窗口内新增的流量 | 全部流量都来自正在前台使用的应用 |
| 某应用的累计增量 | 可归属到该应用的流量变化 | 每个请求都命中了同一条规则 |
按服务器与按应用：固定对象后再核对读数
按服务器排查时，先记下 Home 当前选用的服务器，同时检查 Config 中正在使用的配置及策略是否会选择其他服务器。切换 Home 的选择，不应被理解为所有既有连接会立即迁移；策略选择和连接复用都可能影响实际出站。服务器重命名、订阅更新或条目替换后，也不要仅凭相似名称就把新旧累计值拼成一条连续记录。
按应用排查时，尽量只让一个目标应用进行一次新的网络访问。浏览器多个标签页、后台同步和应用内预加载都会增加干扰。若当前平台的 Data 不能提供所需的应用归属，就改用时间窗口和目标域名的连接记录交叉验证，不要把无法识别的条目强行归给某个应用。
服务器视角记录项
- 入口
- Data 中的服务器统计视图
- 测试对象
- Home 选择与策略实际使用的服务器
- 比较方法
- 同一条目测试后的累计量减测试前累计量
- 辅助证据
- 同一时段连接记录中的实际出站
固定服务器、配置和网络条件，再比较一次测试的增量。
应用视角记录项
- 入口
- Data 中可用的应用统计视图
- 测试对象
- 一个可识别的前台应用
- 干扰来源
- 后台同步、缓存、预加载与其他标签页
- 辅助证据
- 测试时间、访问目标及匹配策略
应用归属与代理出站是不同问题，不能用其中一个代替另一个。
统计清零时机：以明确重置或基线记录为边界
不要默认 Data 在每天零点、每次重连或每次重启应用后自动清零，也不要假设它与服务商的计费周期一致。不同统计项的保留范围可能不同；界面没有明确标注时，应把“上次何时重置”视为未知，而不是把当前累计量称作“今天用量”。
- 先保留基线。记录时间、平台、当前配置、服务器名称和准备观察的累计读数。需要保留历史时，保存文字记录即可，不必为了测试删除历史。
- 确认重置范围。如果当前 Data 提供清零或重置操作，先阅读操作说明或确认提示，分清它影响当前条目还是全部统计；按钮名称以当前界面为准。
- 需要清零时再执行。在一次受控测试开始前执行，并等待界面刷新，确认目标读数确实变化。不要在测试中途清零，否则前后差值失去共同基线。
- 没有明确入口就用差值。不必通过删除服务器、删除配置或重新安装来获得零起点；用结束值减开始值，通常更适合排查。
核对分流：用 Config 和连接记录验证一次访问
核对规则时，先确认 Home → Global Routing 处于 Config。Proxy、Direct 与 Config 的路由意图不同，不能把前两者下的测试当作自定义规则生效的证据；使用 Scene 时，还应确认当前场景实际采用的配置与策略。接着到 Config 确认正在使用的配置，而不只是确认某份文件已经导入。
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY以上仅用于说明顺序：规则从上到下匹配，命中后执行策略，FINAL 负责兜底；其中 PROXY 应对应配置中有效的代理策略。example.com 是示例域名，不是测试线路。IP-CIDR 与 GEOIP 依据 IP 条件匹配，不能把它们直接当成域名分类；具体结果还应结合目标解析和连接记录检查。
- 停止正在进行的大文件传输与媒体播放，记录 Data 中相关统计项的起始值。暂停其他操作即可，不要假设后台流量已经完全消失。
- 在目标应用中发起一个新的请求，记下访问时间与完整目标域名。尽量选择自己可以确认会联网的操作，避免只打开已经缓存的页面。
- 等待请求结束并返回 Data，记录同一统计项的结束值。若使用固定窗口，可统一观察 60 秒，避免一次观察几秒、另一次观察数分钟。
- 查看同一时段的请求或连接记录，核对目标域名、匹配策略和实际出站。规则应走
DIRECT时，代理服务器累计量不必随该请求增加。 - 如需对照测试，每次只改变一项设置，并重新发起连接；必要时先结束旧连接，避免复用连接干扰判断。
结论：以连接记录定归属，以 Data 看增量
如果服务器累计量增加，却找不到目标请求使用该出站的记录，先排除后台活动；如果记录已显示目标走 DIRECT，就不要仅因代理计数没有增加而修改规则。
常见读数问题：账单差异、零增量与断开后变化
为什么 Data 和服务商面板的用量对不上？
先对齐统计起止时间，再确认服务商面板是否包含其他设备、上传计费或流量倍率。客户端与服务商可能处于不同计数位置，协议封装和重传的处理也可能不同。保留同一时间窗口的两端读数，按已有服务商的计费说明核对，不要直接用两边累计总量相减。
页面能打开，服务器流量为什么没有增加？
先检查是否读取缓存，再检查 Home → Global Routing 与 Config 中的有效规则。目标可能走 DIRECT，也可能由其他策略选择了另一服务器。重新发起一次可确认联网的请求，结合连接记录判断；小流量还需要考虑显示精度和刷新间隔。
切到另一个应用后，原应用的流量还在增加怎么办？
先停止该应用内的下载、播放或同步任务，再观察一个固定窗口。切到后台不等于所有连接结束，部分读数也可能稍后才刷新。若当前平台不能可靠显示应用归属，改用目标域名和请求时间核对，不要单靠应用行名称判断后台行为。
断开以后又出现流量，是统计错误吗？
先回到 Home 查看连接状态，再检查 Settings → On Demand 是否启用了会触发重新连接的条件。若连接确实保持断开，比较的是累计值还是速率，并等待刷新。仍有疑问时记录断开时间与新增连接时间，按时间顺序排查，避免仅凭一次数字变化下结论。
最后，Data 只能说明已记录的传输活动，不能单独解释网页为什么慢。服务器连通性、DNS、目标响应时间与网络质量应分别检查。出现连接故障时，可继续查看故障排查；每次只调整一个设置，再用相同测试窗口复核，才能让前后读数具有可比性。