Data 是观察流量的入口，不是服务商账单，也不能单独证明某条规则命中。本文面向已有自己的服务商与订阅、已经完成连接的用户，说明服务器归属、应用归属、上传下载和累计读数的区别，再用固定测试动作与连接记录交叉核对分流结果。判断时看测试前后的增量，不只看总量。
一、Data 记录的是流量，不是购买额度
Shadowrocket（小火箭）的 Data 用于查看应用记录到的网络活动。先在 Home 确认连接状态，再打开 Data 查看统计。统计只反映相应记录范围内的活动；连接关闭期间、未进入隧道的流量，以及系统采用其他路径处理的活动，不能据此认定已经计入。
上传表示设备向外发送的数据，下载表示设备接收的数据。浏览网页也会产生上传：请求、请求头和交互数据都需要发送。上传有读数并不等于正在上传文件；下载有读数也不等于网页主体已经完整显示。
这条流程用于理解观察顺序，不是应用内部实现示意。规则决定连接走哪里，统计反映连接收发了多少。连接失败前也可能交换少量数据，因此“数字增加”只能证明有活动，不能直接证明访问成功。
二、按服务器与按应用：两种归属不能重复相加
按服务器查看时，重点是某个服务器条目承担了多少传输。按应用查看时，重点是流量归属于哪个来源。两种视图是在不同维度整理网络活动，不是两份互不相干的流量。不能把服务器合计与应用合计相加，作为设备总用量。
| 观察维度 | 适合回答的问题 | 不能单独推断的内容 |
|---|---|---|
| 按服务器 | 测试期间哪个服务器条目的收发读数增加？ | 不能仅凭总量确认具体域名命中了哪条规则。 |
| 按应用 | 哪些已识别的来源产生了较多流量？ | 不能认定该应用的所有连接都采用相同出站。 |
| 上传与下载 | 本次操作主要产生发送还是接收数据？ | 不能直接等同文件大小或服务商扣除额度。 |
| 累计读数 | 当前统计范围内积累了多少活动？ | 不能把历史流量全部归因于刚刚修改的配置。 |
应用归属应以当前 Data 实际提供的分组和识别结果为准。Apple 平台的网络隧道不保证每条连接都能获得明确的应用名称；未识别的来源、系统进程或合并记录，不宜强行归给某个应用。若当前页面没有相应分组，不要把域名列表当作应用列表使用。
一个应用可能同时请求登录接口、图片域名与内容分发域名。这些连接可能命中不同规则。因此，“该应用下载了很多数据”与“该应用全部经过某个服务器”不是同一结论。要核实分流，需要进一步查看目标地址和实际出站记录。
判断：用服务器增量定位出站，用连接记录确认目标
先找测试期间增长的服务器条目，再核对同一时间段的目标域名、匹配规则与实际策略。只有时间、目标和出站能对应起来，才把这次增长归因于正在测试的请求。
三、先核对 Global Routing，再讨论规则是否生效
在 Home → Global Routing 查看当前姿态。Proxy、Direct、Config、Scene 的选择影响流量如何路由。测试配置文件内的规则时，应确认使用 Config，并在 Config 中确认当前选中的配置文件；仅编辑文件但没有选用它，统计不会自动反映那份文件的意图。
- Proxy：以代理姿态处理流量。不能用此时的服务器增长证明配置文件里的某条分流规则已经命中。
- Direct：以直连姿态处理流量。代理服务器读数没有增加，不一定是连接开关或统计功能异常。
- Config：依据当前配置进行分流。检查规则顺序、策略名称和兜底规则，才能解释出站结果。
- Scene：依据场景设置决定路由行为。测试前要确认实际生效的场景，不能只看首页选中的服务器名称。
以下配置卡仅解释核对项目，不要求直接替换现有配置。example.com 与 192.0.2.0/24 用于语法说明，不提供可用服务。PROXY 的最终出站还要结合当前服务器或策略组选择确认。
规则匹配核对
- DOMAIN-SUFFIX
DOMAIN-SUFFIX,example.com,PROXY- IP-CIDR
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve- GEOIP
GEOIP,CN,DIRECT- FINAL
FINAL,PROXY
规则按顺序匹配；FINAL 是兜底。no-resolve 表示不为该条 IP 规则主动进行域名解析。
测试环境核对
- Home → Global Routing
- 测试配置规则时确认 Config。
- Config
- 核对当前选用的配置文件及规则内容。
- Settings → On Demand
- 检查自动连接条件是否影响测试期间的连接状态。
- Home
- 核对当前服务器及相关策略组的实际选择。
一次只改变一个条件，避免把路由切换、服务器切换和自动连接混在同一轮测试里。
四、用一次短测试核对流量增量
有效的比较需要相同统计范围。先记下当前数值，再执行单一动作，最后计算差值。无需为了每次测试都清空历史记录；若使用当前界面提供的重置操作，应先保存需要的读数，并记录重置时间。不要默认切换服务器或断开重连一定会清除累计值。
- 记录基线：在 Data 记下目标服务器的上传、下载数值，并记下记录时间。核对 Home 的连接状态与 Global Routing。
- 减少干扰：暂停正在进行的大文件传输、视频播放和同步任务。保留必要的系统活动，不把后台噪声误认为完全消失。
- 执行单一操作：打开一个自己有权访问、可以重复测试的页面，等待加载结束。记录实际访问的域名与开始、结束时间。
- 读取差值：返回 Data，用结束读数减去基线读数。两个数必须来自同一条目、同一方向、同一单位。
- 交叉核对：在可用的连接详情或日志中查找对应时间段，查看目标、规则及策略。若记录不足，保持条件不变再测一次。
下面是计算方法示例，不是产品实测结果。假设某服务器的下载读数从 120 MB 增至 126 MB，上传从 8.0 MB 增至 8.2 MB，那么显示值对应的增量分别是 6 MB 和 0.2 MB。它们是该时间段的统计增量，不应直接写成“这个网页恰好有 6 MB”。
下载增量 = 126 MB - 120 MB = 6 MB
上传增量 = 8.2 MB - 8.0 MB = 0.2 MB
比较前提 = 同一条目 + 同一统计范围 + 同一单位显示值经过舍入时，小请求可能暂时看不出变化。网页缓存也会减少重新传输的数据量。若第二次加载明显更快且读数增长很小，先检查是否使用了缓存，不要立即判定规则失效。页面跳转、图片和后台请求也可能访问其他域名，必须按实际连接核对。
五、常见读数异常：先检查记录范围
网页能打开，为什么服务器流量没增加？
先检查 Home → Global Routing 是否为 Direct，或 Config 中是否命中了 DIRECT。再确认页面不是从缓存加载，并查看是否实际使用了另一个服务器或策略组成员。使用一次新的、可重复的网络请求核对，而不是只刷新已有页面。
什么都没操作，下载读数为什么还在涨？
系统同步、消息接收、后台刷新和未结束的媒体连接都可能持续收发。先停止明确可识别的传输，再按固定时间窗口观察增量；同时查看该时间段的连接记录。不要仅根据累计数字判断是哪一个应用在传输。
按应用与按服务器的合计为什么对不上？
核对两边的统计范围、重置时间、单位和分组条件。应用归属可能不完整，直连也不等于某个代理服务器的流量。只比较能够对应的同一时间段；范围不同的累计值不适合直接作差。
订阅更新后，同名服务器的读数还能接着比较吗？
先核对 Home 中该条目的实际服务器地址、端口和协议。同名条目可能对应不同配置，更新也可能改变统计归属。记录新基线后再测试，不要把更新前后的同名显示自动视为同一出站。
另一个常见情况是连接开关被自动条件影响。进入 Settings → On Demand 检查当前配置的连接条件，记录测试期间是否切换 Wi-Fi 或蜂窝网络。On Demand 控制连接触发，不负责给每个应用分配统计标签；排查时应把“是否建立隧道”与“流量归属谁”分开。
六、判断规则分流生效的最小证据
Data 适合快速发现“哪一项在增长”，连接记录适合解释“为什么走这里”。两者配合时，先固定目标与路由条件，再核对实际出站。不要只凭某个服务器排在统计列表第一位，就认定所有请求都经由它。
- 目标一致：记录的是实际请求域名或 IP，不只是网页标题。跳转后的地址和资源域名需要分别检查。
- 条件一致：Home → Global Routing、Config 文件、服务器或策略组选择，在同一轮测试期间保持不变。
- 证据一致：连接记录中的规则与策略符合预期，Data 中相应条目的增量也能对应到测试时间。
- 结果可重复：排除明显后台传输和缓存影响后，重复测试仍得到相同出站判断。
操作结论：先查命中，再解释用量
出站不符合预期时，先核对 Global Routing 与规则顺序；出站正确但用量不同，再检查统计范围、缓存和计数口径。不要为解释一个累计读数，同时改动 DNS、协议和多条规则。
如需进一步排查连接失败，可参阅疑难解答；需要整理配置文件和诊断思路，可参阅疑难手册。这些检查应基于自己已有的配置与服务，不以流量总量代替连通性判断。