使用
流量统计
总流量、月流量、今日流量分别怎么算，重置日怎么设。
面板上有三个流量数字，算法不一样：
| 数字 | 从哪来 | 什么时候归零 |
|---|---|---|
| 总流量 | hub 侧累加 | 永不归零，也永不回退 |
| 本月流量 | 同上，另存一份 | 跨过这个节点的重置日 |
| 今日流量 | 同上 | 跨过 hub 本地时区的零点 |
为什么要 hub 来累加
网卡的流量数来自内核计数器，而这个计数器每次开机从 0 开始。照原样显示， VPS 一重启面板上的总流量就归零。
所以 agent 只上报两样东西：内核计数器的当前读数（原样，不加工），
和一个每次开机都会变的 boot_id。累加由 hub 做，agent 保持无状态。
只计入 hub 亲眼看着涨过去的那部分
读不出计数器 → 整行不动，不计流量也不改基线
boot_id 和上次一样 → delta = max(当前读数 - 上次读数, 0)
其余情况 → delta = 0，只重新对基线「其余情况」有三种：节点第一次上报、同一个 boot 下读数变小（某个网卡消失了）、boot_id 变了。
三种都选「重新对基线」，因为赌错的代价差几个数量级——
- 猜错方向计进去：一次虚增一整个 lifetime 计数器（几百 GB），而总流量单调递增，只能手工改回来
- 重新对基线：只丢掉「开机到首次上报」之间的量，通常几十秒、几百 KB
boot_id 变了也不计流量，还有第二个理由：同一条安装命令粘到了第二台机器上，
两个 agent 互相踢下线再重连，hub 每秒看到两个 boot_id 来回切换。实测每来回一轮涨 180 GB。
agent 掉线期间的流量会被补上
这是特性不是 bug。读的是内核 lifetime 计数器，agent 挂着的时候内核照样在计数， 重连后的第一次 delta 把这一段全包进去。流量确实跑了，商家确实会算。
前提是机器没重启。 掉线期间重启过的话 boot_id 变了，那一段没有基线可减。
月度周期按商家的重置日算
每个节点有自己的每月重置日（1–31），在节点编辑里设。
- 今天 ≥ 本月的重置日 → 周期从本月的重置日开始
- 否则 → 从上月的重置日开始
- 重置日超过当月天数就落到当月最后一天（设 31 号，2 月落到 28 或 29 号）
没有定时任务做重置，是节点下一次上报时惰性触发的。所以一个离线很久的节点重新上线时 会正确地开始一个新周期，而不是在离线期间被误重置。
读取的时候也会再判一次周期：在边界之前就掉线的节点，磁盘上留着的是上一个周期的数字， 读出来会答 0 而不是把上个月的用量当成这个月的。
月配额怎么算
每月流量额度（GB） 留空或填 0 表示不限，进度条留空，页脚写「不限」。
流量计算方式决定拿哪个数去对配额：
| 方式 | 计算 | 什么时候用 |
|---|---|---|
sum | 上行 + 下行 | 大部分商家 |
max | max(上行, 下行) | 按较大方向计费 |
up | 只算上行 | 只限上行 |
down | 只算下行 | 只限下行 |
今日流量按本地时区
日边界和月边界都走 hub 所在机器的本地时区，不是 UTC——重置日和「今天」都是人说的日期。
Docker 部署必须设 TZ。不设按 UTC 算，日流量和账单周期到点不归零，而且没有任何报错。
手工校正
节点 → 流量校正，用于换机器、迁移或者修正一次误算。
只提交你改了的字段；没填的保留数据库当前的读数，不会把打开表单那一刻的快照写回去。
改月度值时 hub 会顺手把周期戳成当前周期——不然刚填进去的数会被读成 0， 等节点重新上线又会被重置掉。
清理历史不影响累计
设置 → 历史数据保留天数只删每分钟一行的历史明细和探测记录，永远不碰累计流量。
因为累计值不是从明细算出来的，它是一个独立的、每次上报都更新的状态。 所以保留天数可以放心调小，图表变短，流量数字毫发无损。