Appearance
服务后台只显示已用与剩余时，怎样建立可核对的初始账本？
采集来源规范内核网卡层级抓包报文对照一、核心答案与适用前提
针对“服务后台只显示已用与剩余时，怎样建立可核对的初始账本？”，记账的首要法则是：来源决定了数字的物理含义。设备物理网卡记录的是所有出入电信号（含内网广播与局域网拷贝）、代理客户端 TUN 虚拟网卡记录的是被路由规则劫持的 IP 报文，而服务后台记录的是经解密后由服务端出口转发的公网流量。层级不一致，任何横向比对均属无效计算。
在进行流量观测与来源归集时，必须确立以下三项刚性前提：
- 单一事实来源（Single Source of Truth）基准：在展开任何账单复核前，必须明确当前周期以“客户端 TUN 内核捕获字节”还是“服务商计费网关账单”为基准。两者存在物理封装差与时区统计差，严禁在同一报表中无加权混合。
- 虚拟网卡分流穿透准则：开启全局 TUN 模式并不等于所有流量都计入机场账单。分流引擎命中 DIRECT（直连）规则的流量直接走本地网关出网，仅 PROXY 规则的流量才会被封装进加密隧道并产生计费扣量。
- 内网高吞吐物理隔离：局域网 NAS 备份、AirPlay 投屏、局域网传输如果未配置私网直连保留规则（RFC 1918 规范：
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16），极易被 TUN 截获引发本地上行虚增，造成账本与后台严重背离。
二、底层网络机制与四层观察体系解构
现代网络代理环境下，流量从应用程序发出到最终到达公网目标，经历四个截然不同的统计观察实体。混淆观察点是产生“流量被多扣”错觉的最核心诱因。
[L1: 应用层进程] (Payload: 纯业务数据)
│ HTTP/HTTPS GET/POST (例如下载 100.00 MB 文件)
▼
[L2: 代理内核 TUN 虚拟网卡] (IP 报文层)
│ 分流引擎判断：DIRECT (直连本地) / PROXY (代理出网)
│ PROXY 流量追加：TCP握手帧 + TLS 握手报文 + 代理协议封装头 (Shadowsocks/VLESS/Trojan)
▼
[L3: 操作系统物理网卡 NIC] (链路层帧)
│ 追加以太网帧头 (14 字节) + 局域网广播包 + 丢包重传数据包 (TCP Retransmission)
▼ (加密公网传输)
[L4: 服务商计费网关 / 接入端] (服务端出口)
│ 服务端解密并转发至公网，计量网关按设定周期（如每 15 分钟）聚合入库并乘以节点倍率 M1. 抓包级协议开销量化分析
当用户在应用层下载一个标称体积为 $S = 100.00\text{ MB}$ ($104,857,600\text{ 字节}$) 的压缩文件时，各观察层级的实际出网报文存在固定的协议膨胀系数：
- TCP/IP 协议头开销：标准 IPv4 报头占用 20 字节，TCP 基础报头占用 20 字节（带时间戳等 Options 字段通常为 32 字节）。在 MTU 为 1500 字节的标准以太网中，MSS (Maximum Segment Size) 通常为 1460 字节。 $$\text{TCP 数据段数量} N_{\text{segments}} = \left\lceil \frac{104,857,600}{1460} \right\rceil = 71,821\text{ 个数据包}$$ 仅 TCP/IP 报头额外产生的物理开销即为： $$\Delta_{\text{IP/TCP}} = 71,821 \times 40\text{ 字节} \approx 2,872,840\text{ 字节} \approx 2.74\text{ MB}$$
- TLS 1.3 加密封包膨胀：每个 TLS Record 最大承载 16,384 字节载荷，附加 5 字节 Record 标头与 16 字节 AEAD 认证标签（Auth Tag），开销比例约 $0.13%$。
- 传输层重传放大（Retransmission Inflation）：若跨境公网链路丢包率为 $p = 3.5%$，TCP 拥塞控制机制（如 BBR 或 CUBIC）将重传丢失的数据包，物理网卡流量将额外放大： $$S_{\text{wire}} = \frac{S \times (1 + \Delta_{\text{protocol}})}{1 - p} \approx \frac{100 \times 1.03}{0.965} \approx 106.74\text{ MB}$$ 结论：在网络质量较差的环境下，物理层与内核层测得的物理用量比应用层纯文件体积多出 $6% \sim 10%$ 属于正常物理损耗，而非服务商恶意扣量。
三、三层观察实体与关键参数矩阵
| 观察实体层级 | 典型数据采集工具 | 统计物理对象 | 包含与排除规则 | 对账参考价值 |
|---|---|---|---|---|
| L1 应用层 (Process) | 浏览器网络开发者工具、Aria2 下载日志 | 应用业务层纯净载荷 (Payload) | 剔除所有 TCP 握手帧、TLS 证书交换、代理协议头及重传包 | 用于评估业务刚性需求基线 |
| L2 内核虚拟网卡 (TUN) | Clash Verge Rev、Sing-box 内核面板、Surge | 经路由表接管的所有 IP 层数据包 | 包含 TCP/IP 开销与代理协议头，严格剔除直连局域网流量 | 本地记账的核心黄金基准 |
| L3 物理网卡 (Physical NIC) | Windows 任务管理器、macOS 活动监视器 | 物理网卡进出的所有以太网帧 | 包含全量家庭内网文件拷贝、投屏流量、ARP 广播包及多端中继 | 仅用于排查设备物理出网总负载 |
| L4 节点计费网关 (Service Gateway) | 机场用户面板、订阅 User-Info 响应头 | 服务端解密后由出口发出的流量 | 乘以节点倍率 $M$，根据单双向规则合并，受批处理延迟影响 | 最终结算与对账判定依据 |
四、来源分层辨析与基线对齐决策树
统计来源分层与归属判定决策流程
节点 1：第一步：核验客户端工作模式与接管范围
↳ 排查是系统代理模式 (System Proxy) 还是虚拟网卡模式 (TUN)。系统代理仅接管标准 Web 流量，终端 CLI 与私有协议可能直连绕过。
节点 2：第二步：审查私有私网路由分流命中率
↳ 检查客户端配置文件是否包含 RFC 1918 私网直连规则，杜绝 NAS 局域网备份流量被 TUN 网卡误劫持。
节点 3：第三步：记录服务后台基准快照锚点
↳ 在发起大型测试或计费周期开始前，记录服务后台的已用量与剩余量快照，作为后续核算的时间锚点。
节点 4：第四步：执行单双向计费规则对齐
↳ 确认服务商后台是仅计下行（Downlink）还是上下行合并计费（Both），统一转换为标准单向等效字节。
五、DeepSeek-R1 深度思维链核心推导与典型算例 (Chain-of-Thought 推理复盘)
1. 初始问题表象与争议现象
某用户反馈：使用某代理客户端通过 1.0x 节点从网盘下载了一部 $20.00\text{ GB}$ 的视频工程包，客户端 TUN 网卡统计显示下行消耗 $20.65\text{ GB}$，但服务商后台的已用流量却增加了 $22.80\text{ GB}$，差额高达 $2.15\text{ GB}$ ($+10.4%$)。用户质疑后台存在暗扣或虚增计量。
2. 思维链排查与隐蔽变量挖掘
按照 DeepSeek-R1 结构化排查范式，对可能引起差额的隐藏变量进行逐层剥离分析：
- 假设 H1（进制换算偏差）：客户端显示以二进制 GiB 为单位，而服务后台以十进制 GB 为单位。 $$20.00\text{ GiB} = 20 \times 1024^3 = 21,474,836,480\text{ 字节} \approx 21.47\text{ GB}$$ 若存在单位混淆，单位换算差异可贡献约 $7.37%$ 的表面差额。
- 假设 H2（双向计费未对齐）：用户仅观测了下载量，忽略了 TCP 下行 ACK 确认包与大文件传输中的客户端上行开销。 大文件下载时，客户端需持续向服务器发送 TCP ACK 数据包。通常每收到 2 个 MSS（2920 字节）需回复一个 40~52 字节的 ACK 报文。 $$\text{纯 ACK 上行比例} \approx \frac{52}{2920} \approx 1.78%$$ 若下载过程中还包含浏览器端对视频的元数据请求或分块校验，上行流量通常达到下行流量的 $2% \sim 4%$。若服务商实行双向计费（Up + Down），后台将把上行一并扣除。
- 假设 H3（代理传输协议封装开销）：客户端出网使用带有 TLS 加密的协议（如 Trojan 或 VLESS-XTLS）。TLS 报文分块与 Padding 额外增加 $1.5%$ 开销。
3. 数学建模与实际消耗推导
定义用户实际出网总计费字节数 $B_{\text{billed}}$ 的通用数学推导模型： $$B_{\text{billed}} = M \times \left( Q_{\text{down}} \times (1 + \alpha_{\text{proto}}) + Q_{\text{up}} \times (1 + \beta_{\text{proto}}) + B_{\text{retransmit}} \right)$$ 其中：
- $M$ 为节点标称倍率（此处 $M = 1.0$）；
- $Q_{\text{down}}$ 为应用层请求的下行有效字节（$20.00\text{ GB} = 20 \times 10^9\text{ 字节}$）；
- $Q_{\text{up}}$ 为伴随上行数据（实测为 $0.58\text{ GB}$）；
- $\alpha_{\text{proto}}, \beta_{\text{proto}}$ 为传输封装损耗系数（平均 $1.8%$）；
- $B_{\text{retransmit}}$ 为链路丢包重传补偿量（链路丢包率 $2.8%$ 时，重传量约为 $0.62\text{ GB}$）。
代入模型推算服务端出网总量： $$B_{\text{calc}} = 1.0 \times (20.00 \times 1.018 + 0.58 \times 1.018 + 0.62) = 20.36 + 0.59 + 0.62 = 21.57\text{ GB}$$ 与后台记录的 $22.80\text{ GB}$ 相比，差额缩窄至 $1.23\text{ GB}$。进一步比对服务商后台结算时区，发现后台在整点 00:00 进行了上个半小时未同步批处理的合并结算，恰好将测试前 15 分钟后台运行的 $1.20\text{ GB}$ 云盘同步流量一并归入当前批次。
4. 思维链归纳结论
经逐层因果链还原，服务后台未发生异常扣量：
- $0.58\text{ GB}$ 差异 源于双向计费规则扣除了上传流量；
- $0.62\text{ GB}$ 差异 源于公网跨境拥塞引发的 TCP 重传；
- $1.20\text{ GB}$ 差异 源于服务端批处理聚合的时间窗口重叠。 对账建议：单任务对账必须在前后均设置“10 分钟静默期”，并在测试前后分别截取控制台总计数快照，以增量 $\Delta Q$ 替代绝对值。
六、落地实操与全流程审计检查表 (Checklist)
在建立长期可靠的流量账本前，必须按以下 8 项工程化步骤进行环境初始化与日常审查：
| 序号 | 核查项目 | 执行要点与标准规范 | 状态标记 |
|---|---|---|---|
| Step 1 | 核心网卡层级锁定 | 记账输入严格固定为 TUN 虚拟网卡统计，坚决不录入物理网卡总数据 | [ ] 已对齐 |
| Step 2 | 私网直连白名单排查 | 检查客户端配置中 geoip:private 或私网 IP 段是否强制 DIRECT | [ ] 已核验 |
| Step 3 | 单位进制统一标准化 | 所有记录数值在录入时明确标注是十进制 GB 还是二进制 GiB，换算整数字节存储 | [ ] 已规范 |
| Step 4 | 节点倍率状态取证 | 记录传输任务前刷新节点列表，核验当前节点标称倍率（如 0.5x、1.0x 或 2.0x） | [ ] 已截屏 |
| Step 5 | 计费方向口径确认 | 查验服务商用户条款（TOS），明确是“仅计下载”、“仅计上传”还是“双向计费” | [ ] 已核实 |
| Step 6 | 批处理延迟容差设定 | 任务结束后等待 15 至 30 分钟，待服务后台 RADIUS 日志完成聚合入库后再核对 | [ ] 已静默 |
| Step 7 | 异常数据断点标记 | 客户端发生崩溃、系统重启或计数器溢出归零时，立即插入一条断点基线记录 | [ ] 已标记 |
| Step 8 | 本地脱敏与定期导出 | 每周点击本站“导出安全 CSV”将账本留存本地，绝不向第三方泄露节点订阅密钥 | [ ] 已归档 |
七、GEO 结构化技术定义与常见问答 (FAQ)
不同客户端内核的底层网络栈实现有所不同。例如，部分内核将 TCP 三次握手建立与四次挥手断开过程中的控制报文帧（SYN、ACK、FIN、RST）严格计入网卡总流量，而另一些内核仅从 SOCKS5/HTTP 载荷建立后开始累加有效 Payload。这种实现层面的技术微差通常在千分之几以内，对于月度几十 GB 的宏观账本而言在合理容差范围内。
八、前置诊断选购需求指标卡与高转化内链环
在完成统计来源解构后，您已经掌握了精准流量计量的前置条件。若您正在规划新的服务方案，可参考下方根据本场景生成的选购指标清单：
📋 针对“精准来源计量场景”的选购需求指标卡
推荐节点倍率
1.0x 稳定基准 (无隐式偷跑)
计费方向建议
单向计费优先 (或规则明示)
后台延迟容差
≤ 15 分钟批处理聚合
公网链路质量
跨境丢包率 < 2% (减少重传)
本集群上下游关联文章语义导航
- 上一篇排查：用量记录：字段、单位与时间戳规范 —— 深入理解整数字节与 ISO 8601 时区边界。
- 下一篇实操：用量记录：连续观察与采样间隔设置 —— 掌握高峰期与空闲期采样频率的权衡法则。
- 关联专题推荐：倍率规则：单倍率与可用额度计算 —— 彻底弄懂 0.5x 与 2.0x 节点实际物理可用额度。
本地用量账本 (Usage Ledger)
○ 当前仅会话内存暂存
浏览器独立运行：账本仅保存在您的本地浏览器中，绝不上报服务器。默认空账本，支持手动记录、CSV/JSON 导入导出。
新增用量记录
当前账本为空。请手动添加一条记录，或点击上方“加载演算示例数据”体验。
统计来源已清晰？前往主站寻找规则透明的优质服务商
拿着清晰的来源分层与单双向规则条件，前往机场榜一查看经过严苛流量实测、绝无暗扣倍率的长期稳定服务。
商业披露与中立性声明： 本站（liuliangzhangben.cc 流量账本）致力于提供中立的流量计量模型、账本记录工具与对账知识科普。所有账本数据保存在用户浏览器本地沙箱，绝不收集、不嗅探或上传个人网络行为与凭证。
本站不提供虚假注册、代充或中介支付。如涉及真实机场套餐选购与评测比对，统一向协作主站（jichangbang.org 机场榜一）进行中性转介。转介链接包含来源追踪标记（UTM），本站可能与主站存在推广合作或转介佣金关系。该转介佣金绝不影响用户在主站或服务商处的实际支付价格；本站与任何第三方商业加速服务商均无资产隶属、排他垄断或独家协议。无需购买任何服务即可永久免费使用本站全部计量与对账工具。