本文面向已经在 Shadowrocket（小火箭）中导入自己订阅、需要核对流量去向的用户。先区分服务器归集与应用归因，再固定统计窗口，最后用单次请求、规则命中记录和流量增量交叉验证。Data 中的累计量不是实时速度，也不能直接替代服务商账单；应用归属的可见范围以实际界面和系统提供的信息为准。
一、Data 读数先看统计口径
打开 Data 后，不要只看最大的数字。先确认当前条目代表服务器、连接目标还是应用，数值是上传、下载还是合计，统计范围又从什么时候开始。即使两个位置都显示 MB，只要归集对象或起止时间不同，数值就没有直接相等的前提。具体分组、字段和重置入口以实际应用界面为准。
上传通常指设备向外发送的数据，下载通常指设备接收的数据。浏览网页也会上传请求、连接协商和确认信息，因此上传不为零并不表示正在主动发送文件。累计流量表示一段时间内传输了多少数据；速度带有时间分母，例如 KB/s。将累计 20 MB 理解成“当前速度 20 MB”会得出错误结论。
判断本次操作产生的流量，应取结束值减去开始值，而不是比较两个累计总数。若中途重置统计、切换统计范围或重新建立连接，应重新记录基线。应用内计数、系统蜂窝用量与服务商账单各有统计边界，不能仅凭数值不一致判定异常。
二、按服务器看出站，按应用看来源
按服务器归集回答的是“数据经由哪个服务器条目处理”。多个应用同时使用同一个服务器时，读数会汇总到一起；一个应用访问多个目标，也可能因规则不同而使用不同出站。因此服务器流量增加不能独立证明某个应用的全部请求都经过该服务器。
按应用观察则试图回答“流量由哪个应用产生”。但应用身份不等于域名：同一应用可能连接内容、图片、登录和推送等不同域名，同一个域名也可能被多个应用访问。不能把某个目标域名的累计流量直接命名为某个应用的完整用量。
尤其在 iPhone 与 iPad 上，VPN 隧道获得的数据包信息不等于完整的系统进程信息。若当前 Data 界面没有应用归属字段，不能凭服务器名称推算出按应用排行；若界面存在无法识别或未归属的记录，应保留这种不确定性。需要核对蜂窝网络中各应用用量时，可到系统 Settings → Cellular 查看，并核对系统统计周期；该数据也不等于包含 Wi-Fi 的应用总流量。
| 观察对象 | 可以回答 | 不能单独证明 |
|---|---|---|
| 服务器条目 | 该条目在当前窗口内的传输变化 | 某应用的全部请求均走此服务器 |
| 应用归属信息 | 可识别范围内的流量来源 | 设备上所有应用都被完整归因 |
| 目标域名或 IP | 请求连接到哪里 | 请求一定来自某个特定应用 |
| 系统蜂窝用量 | 系统统计周期内的蜂窝数据使用 | 同一应用在 Wi-Fi 下的用量 |
三、固定窗口，做一次可重复的流量实验
测试以前，先在 Home 确认连接已建立，再记录 Global Routing 当前选择与 Config 中启用的配置文件。本文以用户已有服务器和订阅为前提，不需要为查看统计增加任何连接服务。测试期间不要更新订阅或切换服务器，以免同名条目变化影响前后对照。
- 减少干扰：暂停大文件传输、视频播放与云端同步。关闭其他应用的前台操作，但不要假定这样就能消除全部后台流量。
- 记录起点：在 Data 抄下目标服务器的上传、下载累计值与时间。保留旧记录即可，不必为了每次测试清空所有统计。
- 单独触发：只打开一个应用，访问一个已知页面或执行一次明确操作。避免同时刷新多个页面，观察约 60 秒。
- 记录终点：回到 Data，读取同一条目与同一口径的累计值，分别计算上传和下载增量。
- 核对请求：在可用的连接记录中核对目标域名、命中规则与出站信息。若没有足够细节，降低结论强度，不把增量当作唯一证据。
- 重复一次：保持设置不变再测试。第二次可能命中缓存，不能要求它与第一次字节数完全一致。
如果要比较两种设置，每次只修改一个变量。例如先保持服务器不变，只将 Global Routing 从 Proxy 切到 Config，再重新建立测试连接。把服务器、DNS 和规则同时更换，即使数字发生变化，也无法确定是哪一项导致。
四、把统计增量与规则命中对起来
在 Home → Global Routing 中，Proxy、Direct、Config 与 Scene 是不同的路由姿态。Proxy 适合建立代理路径的对照，Direct 用于直接连接对照；Config 才按当前配置中的规则判断去向。Scene 需要结合所选场景的具体设置判断，不能把它直接理解成固定代理或固定直连。
验证规则分流时，先使用 Config，并在 Config 中确认当前启用的文件。规则通常按顺序匹配，较早命中的条目会影响结果；FINAL 是兜底。仅在编辑器里看到一条 DOMAIN-SUFFIX，不代表本次连接已经命中它，也不代表它一定早于其他匹配项。
测试前记录
- 连接入口
- Home
- 路由入口
- Home → Global Routing
- 规则姿态
- Config
- 配置核对
- Config 中当前启用的文件
记录实际选择，不用记忆中的设置代替当前状态。
示例规则含义
- DOMAIN-SUFFIX
- example.com,PROXY
- IP-CIDR
- 192.0.2.0/24,DIRECT,no-resolve
- FINAL
- DIRECT
- 匹配顺序
- 自上而下，命中后采用对应策略
示例使用保留域名与文档地址段，仅解释语法，不作为测试目标。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECT上例中，example.com 及其子域名匹配 PROXY；文档地址段匹配 DIRECT，no-resolve 表示不为该 IP 规则额外触发域名解析；其他请求最终落到 DIRECT。这只是规则片段，不能替代完整配置。实际使用时，应核对当前配置可用的策略名称与自己的目标。
判断动作：一条请求配一组证据
若目标预期走 PROXY，应同时核对该请求命中的规则、实际出站和对应服务器的流量增量。只有累计数字增长而没有请求对应关系时，先重复单应用测试，不要立即修改整份规则。
五、为什么数字会偏离预期
最常见的差异来自统计边界，而不是规则失效。设备端可能在某个处理层计数，服务商则在服务器侧按自身口径计费；传输封装、连接协商、重传、上下行计费方式与时间窗口都可能造成差异。HTTPS 常见端口为 TCP 443，HTTP/3 常见使用 UDP 443，但端口相同并不意味着应用来源相同，也不能说明所有请求采用同一种传输。
- 页面缓存：页面已经从本地缓存显示时，可能只有少量检查更新的请求；画面变化不等于重新下载全部内容。
- 后台活动：通知、同步和其他连接可能让服务器累计值在测试应用闲置时继续增长。
- 直连流量：走 DIRECT 的请求不应期待归入某个代理服务器条目；是否在其他汇总处显示，应看当前界面的统计范围。
- 长连接沿用旧路径：切换规则后，已经建立的连接可能继续使用原路径。应结束测试操作并重新建立连接，再判断新规则。
- 计数与刷新：显示取整、刷新间隔、重置或统计窗口变化都会干扰小流量对照，先排除这些因素再计算差值。
- 条目变化：更新自己的订阅后，服务器名称、地址或分组可能变化。更新前后的同名记录不一定可以直接拼成一条时间线。
On Demand 也会影响观察窗口。若测试中途自动断开或重新连接，可到 Settings → On Demand 核对触发条件，并记录实际连接状态。它管理的是连接行为，不能据此断言某个请求命中了 PROXY 或 DIRECT；路由判断仍需回到 Global Routing 和请求记录。
六、常见读数问题与处理顺序
应用明明打开了，服务器流量怎么没增加？
先确认页面是否来自缓存，再到 Home 检查连接状态与 Global Routing。若当前是 Direct，或 Config 规则将该目标送往 DIRECT，代理服务器条目不增长可以是正常结果。重新触发一次联网操作，并核对该请求的目标与出站。
应用都关了，Data 的数字还在涨，是规则错了吗？
先停止其他传输，记录连续两个 60 秒窗口的增量，再查看是否存在后台连接或仍在传输的长连接。只凭前台没有操作不能判断流量异常；应先定位目标与连接，再决定是否调整规则。
按应用的数字加起来，为什么不等于服务器合计？
先核对时间窗口、网络类型和上下行口径，再确认应用归属是否完整、是否有未归属记录，以及是否包含 DIRECT 流量。若比较的是系统蜂窝统计与 Data，不能要求两者相等，更不能把差额全部归给某个应用。
改完规则，统计看起来还是走原来的服务器？
先在 Config 确认启用的是修改后的文件，再在 Home → Global Routing 选择 Config。结束旧连接后重试；若仍不符，核对前置规则和 FINAL。必要时重新连接，但应先保存测试基线，避免把重新连接前后的累计值混算。
完整的排查记录应包含测试时间、网络类型、Global Routing 选择、启用配置、目标请求与上下行增量。需要进一步处理时，可按排查手册核对连接与规则，或在术语手册确认策略关键字。Data 适合发现趋势和验证假设；最终的分流结论应建立在具体请求及其实际出站之上。