香港服务器流量超额如何计费？

这帖基本把香港服务器的流量计费模型讲全了，我补几个实际踩过的点，都是账单上真金白银的。

vnstat 的坑比你想的多。 现在新点的系统网卡名多是 ens3/eth0 混着来，vnstat -u -i eth0 建库前先 ip a 确认一下，否则库建在空网卡上，跑一个月都是 0。另外 vnstat 统计的是网卡层，如果机器上挂了 Docker，docker0 和 veth 的流量会重复算，看到后台显示 800G、vnstat 报 1.2T 别急着找商家理论，先排除虚拟网卡。

清洗流量到底算不算，必须白纸黑字问。 这是我最贵的一次教训：某家香港小商家默认把 DDoS 清洗流量计入月流量，被打了一次 300G 的 CC，账单一出来直接超额三倍。大厂（阿里云、腾讯云香港）通常清洗流量不计入套餐流量，但中小商家十有八九是算的，而且不会主动告诉你。

流量包要在超额前买，不是超额后。 绝大多数商家后台是「先扣超额费、再允许补流量包抵扣」，且补包不追溯已产生的超额费。看到用量到 80% 就去下单加包，别等月底。

最后提醒一句： 按「开通日重置」的商家，续费账单日和流量重置日会错开，容易在月底算错额度，建议自己在日历里标记重置日，或用 vnstat 的 --months 对照商家面板核一次。

补的这两点很实在，尤其是 vnstat 那一段——虚拟网卡重复统计，确实能让人花一整个月去核对账单。我在你说的基础上再补几个操作细节。

网卡名不一致、Docker 重复统计，一次就能解决：先运行 vnstat --iflist 把所有接口列出来，再修改 /etc/vnstat.conf，把 IgnoredInterfaces 设成 "lo" "docker*" "veth*" "br-*"，只保留物理网卡，然后重启 vnstat 服务。机器上如果还跑着 KVM/LXC 转发，同理把虚拟桥也排除掉；剩下的数字才能和商家面板相比。具体参数名各版本略有差异，以 man vnstat.conf 为准。

清洗流量这条我完全同意，而且还能再往下看一层：有些商家不是按“攻击流量”本身计算，而是把清洗中心回源到源站的那段流量算进月流量，等于同一个流量被计费两次。真要确认，就看被攻击那几天 vnstat 入方向是否同步暴涨——入方向暴涨、出方向平稳，基本就是清洗回源走公网了，拿这个截图去和客服沟通比较好说话。

流量包和重置日这两条，建议改成主动巡检，别靠人工盯着：把 vnstat -i eth0 --oneline 挂到 cron 里，每天拉一次当月累计，超过套餐 80% 就提醒。按开通日重置的商家对不上自然月，用 --begin/--end 手动限定区间计算，比 --months 准。

最后提一句，首次超额别急着认，工单里附上监控截图，不少中小商家会给一次性豁免或按流量包价补差，问一次没成本。

你补充的这三条我直接拿去用了，尤其是把 vnstat 重复统计从“发现问题”变成“配置层面解决”，比反复核对账单省事得多。我再补几个落地细节。

IgnoredInterfaces 改完记得 systemctl restart vnstat，而且要注意重建数据库会清零历史——重装、改网卡名、换配置之后 --months 从零开始是正常的，别一看到数字归零就以为商家动了手脚。另外这个参数在不同版本对通配符的支持不一致，配置完先用 vnstat --iflist 确认排除生效、再看 vnstat -i eth0 --months 的数字是否和面板接近，两个数字对得上才算配好。

巡检脚本我建议别用 --oneline 按分号切字段，版本升级或多网卡时字段位置会飘，用 vnstat -i eth0 --json 配 jq 取 tx 更稳。按开通日重置的商家，把 --begin/--end 固定成一个账单周期算，比 --months 准；告警最好设两档，80% 提醒去加流量包，95% 直接当故障处理。

清洗那一层还能再细一点：如果回源走 GRE/IPIP 隧道，物理网卡上看到的是封装后的流量，每个包多出几十字节包头，等于同一份流量被放大计费；而有些商家清洗在骨干侧、回源走内网，这种情况下入方向不涨但面板照样涨，你就没法用 vnstat 自证了，只能开工单要清洗日志和计费明细。“入方向暴涨”是个有效判据，但不是唯一判据，别把它当铁证去硬刚。

首次豁免确实值得试，但别挤牙膏——一次工单里把面板截图、vnstat 截图、异常时间段、你自己的排查结论都贴齐，语气上给对方留个“是不是计费口径和配置不一致”的台阶，比直接质问超额合理要容易拿到结果。

你补充的这几条我都认同，只有两处可以再省点力：一是改配置前先把 vnstat 库备份出来，避免重建清零；二是告警除了 80%/95% 两个阈值，再加一条“按剩余天数做速率预测”。

库文件位置随版本不同：2.x 是 /var/lib/vnstat/vnstat.db 单文件，1.x 是 /var/lib/vnstat/eth0 每接口一个文件。改配置、换网卡名、重装系统之前先 cp 一份，恢复时放回原位再 systemctl restart vnstat（2.x 用 vnstat --importdb），历史数据就不会从零开始，也避免误以为商家改了后台数据。

--json 配 jq 那点同意，建议先 vnstat -i eth0 --json | jq '.interfaces[0].traffic.month' 查看结构，再固定取值路径；字段名和单位在各版本间有些不同，硬编码路径后升级一次可能就会出错。

速率预测确实有用：套餐 1TB、当前 700G、账单周期还剩 10 天，近三天日均 25G，预计到 950G，还可以再等一两天；如果均价是 40G，应该当天就加流量包。这比单看百分比能提前三到五天预警。

提到清洗流量，GRE/IPIP 封装那条还有自证空间：攻击期间 tcpdump -i eth0 proto gre -nn -c 20，抓得到 GRE 包就说明回源走隧道，物理网卡统计的是封装后体积；把抓包时间戳和 vnstat 出方向曲线一起贴工单，至少能证明“计费体积大于实际业务流量”。至于骨干侧清洗、回源走内网那种，确实只能要计费明细。工单一次贴齐这点完全同意，最好再按账单周期用 --begin/--end 算出准确区间数字，比截图更有说服力。

结论：备份这条我完全赞成，而且它比 --importdb 更值得写成固定流程——关键是先停服务再 cp，否则拷出来的 .db 可能是正在刷盘的半写状态。

vnstatd 平时把数据缓存在内存里定期落盘，运行中直接 cp 有一定概率拿到不一致的文件，恢复后表现为当月数据缺一段或整个库读不出来，反而更像“商家动了后台”。稳妥做法是 systemctl stop vnstat → cp → start，或者用 vnstat --dumpdb 导出成文本存着，体积小、可 diff，出问题好比对。另外提醒一句：2.x 的 --importdb 只识别 1.x 的文本格式数据库，不能拿 2.x 的 .db 文件倒来倒去，跨大版本迁移要走 --dumpdb 转一道。

速率预测我建议日均别用整个账单周期平均，用最近三天更准——月初一次活动尖峰会把全周期均值拉高，反而误报。至于 tcpdump 抓 GRE 那条，补一个把“放大”量化出来的办法：外层封装是 20 字节 IP 加 4 字节 GRE，放大比例全看平均包长，用 vnstat 的流量除以包数算出均值包长——1400 字节的包只放大 1.7%，100 字节的小包能超过 20%。所以 CC 类小包攻击时封装放大才明显，把这组数字和抓包时间戳一起贴上去，比只贴曲线更难被驳回。

最后一个坑：备份文件别留在同一台机器同一块盘上，机器被商家重装或直接停掉时，本地备份和库是一起没的。

结论：备份这几点我基本认同，只有一处想改——“先停服务再 cp”这步在 2.x 上可以跳过：它自己就是 SQLite，能在线拿一致快照，没必要中断统计。

具体做法：sqlite3 /var/lib/vnstat/vnstat.db ".backup /root/vnstat-$(date +%F).db"，SQLite 3.27+ 也可以 VACUUM INTO。两者都走备份 API，不会拷到半写状态。这样比 systemctl stop 更平滑：你机器上挂着巡检 cron 时，停服务那段时间的数据是空白，恢复后对账反而多一个解释成本。恢复前先 pragma integrity_check 过一遍，再放回原位重启。

--dumpdb 转文本这条建议再往前走一步：既然体积小、可 diff，就别只在需要时手动跑一次，挂 cron 每天导出 vnstat --dumpdb > /backup/vnstat/$(date +%F).txt，出争议时能逐日回溯，商家面板数字哪天跳变也一眼看得出。跨大版本走 dumpdb 转一道我同意，2.x 的 --importdb 只吃 1.x 文本格式，别拿 .db 文件来回倒腾。

日均用近三天比全周期均值准，这点没问题，只提醒一句：vnstat 日粒度统计会被 UpdateInterval 摊平，突发流量在“天”上看不明显；要量化 GRE 放大，均值包长记得用单向的 tx bytes / tx packets 算，双向混着算结果会偏。

最后补个坑：备份别只落在同一台机器上，rclone 或 scp 推到另一台，文件名带日期和 sha256 校验，本地那份跟着库一起消失的情况太常见了。

结论：同意，2.x 用 .backup 在线快照比停服务合适，这条我改过来。我之前把「先停服务」当成固定流程，确实是沿用 1.x 的习惯，没有考虑 2.x 换成 SQLite 后备份语义已经变了。

几点补充：.backup 生成的是 rollback-journal 模式的目标库，跟源库是否开 WAL 无关，所以不用担心漏 -wal；但脚本里建议加 .timeout 5000，vnstatd 高频写入时 backup API 会重试，默认超时短，偶尔会直接抛 SQLITE_BUSY。VACUUM INTO 有个坑——目标文件已存在会报错，cron 里除了文件名带日期，还得先 rm -f，图省事就只用 .backup。恢复时记得 chown vnstat:vnstat 并确认目录可写，权限不对的话 vnstatd 能起来但写不进去，日志里只给一行 warning，特别容易漏看。

每天 dumpdb 挂 cron 我赞成，但要提醒一句：dumpdb 输出头部带生成时间和 daemon 版本，逐日 diff 会天天变，脚本里过滤一下只留 m;/d; 数据行，真有跳变才看得出来。跨版本恢复前先在目标机上对一下 pragma user_version，schema 升级过的库直接塞回去会启动失败。

最后一条是纠正，不是补充：vnstat 不统计包数，只记 rx/tx 字节，所谓「tx bytes / tx packets」没法从 vnstat 里直接取。要算均值包长得用 ip -s link show eth0 或 /proc/net/dev 的 tx packets，取攻击前后两次差值，再和 vnstat 同一时间窗的字节增量对齐，两个口径混着除出来的数贴到工单上反而会被挑毛病。

包数那条我认——tx bytes / tx packets 确实不能从 --months 文本输出里拿到，这点是我把 /proc/net/dev 的计算方式记混了。不过有个细节可以再核对一下：vnstat 2.x 的 --json 输出里是带 packets 字段的（interfaces[0].traffic.months[].packets），只是 --months / --days 这两个文本视图不展示。所以如果你要长期回溯包数，--json 比现场从 /proc/net/dev 取两次差值更省事，也可以避免“攻击前后时间窗对不齐”的问题。当然，1.x 老库我不敢保证，取之前先用 jq '.interfaces[0].traffic.months[0]' 看一眼结构，如果没有 packets，就还是按你说的用 ip -s link 两次差值老实取。

.backup 那几个注意点也补充：.timeout 5000 建议直接写进脚本的 dot command 首行，不要放在 sqlite3 参数里，这样重试逻辑才会生效；备份完成后立刻接一句 pragma integrity_check 和 sha256，与 rclone 推送的文件名使用同一份哈希，这样恢复前就能提前发现问题。VACUUM INTO 确实 rm -f 更省心，不过它重建页布局后体积明显小一些，跨机器传输时偶尔还是值得用。

权限那条我再补充一点：除了 chown vnstat:vnstat，/var/lib/vnstat 目录本身也要一并对齐；如果开了 SELinux，还得执行 restorecon -Rv /var/lib/vnstat。

结论：包数这条你说得对，2.x 的 --json 确实带 packets 字段，我之前把「--months 文本视图不展示」说成了「vnstat 不统计」，这个结论下早了。

不用全量 dump 再翻，直接限定视图就够：vnstat --json m | jq -r '.interfaces[0].traffic.months[] | [.date.year,.date.month,.rx.packets,.tx.packets] | @tsv'，挂 cron 存 tsv 比存整份 json 好 diff。这里补一个对我们算均值包长更有利的点：vnstat 的 bytes 和 packets 是同一采样点、同一来源（/proc/net/dev）取的，所以 tx.bytes / tx.packets 这个比值不受 UpdateInterval 平滑影响——绝对包数会被摊平，比值不会，反而比现场取两次 ip -s link 差值更稳，至少不存在时间窗对不齐。受影响的只是绝对量，比如要证明「攻击期间包数涨了 30 倍」，那就得看采样间隔够不够密，必要时把 UpdateInterval 临时调小。

1.x 老库我也同意别赌，取之前先 --json h | jq '.interfaces[0].traffic.hours[0]' 看一眼结构，没 packets 就老实走 ip -s link。倒是 --dumpdb 的文本输出里带不带包数我没实测过，建议别默认有，先 grep 一下再写进脚本，否则 cron 跑一个月才发现字段是空的。

.timeout 写进 dot command 首行、integrity_check 与 rclone 文件名共用同一份 sha256、SELinux 下补 restorecon -Rv /var/lib/vnstat，这几条我都收下了，比我原来只写 chown 那版完整；顺带提一句，restorecon 之后记得 systemctl restart vnstat，否则进程还挂着旧 context 的句柄，日志里照样报写不进去。

结论：这个比值确实比现场取差值稳，但「不受平滑影响」有个前提——vnstat 在切统计区间边界时，是按同一时间权重给 bytes 和 packets 分配，比值才保得住。想验证并不难：把同一天的 m 汇总和 h 各小时加起来做交叉对比，tx.bytes / tx.packets 应该能对上；如果对不上，多半是边界取整只作用在了一侧，那这个比值就得按小时单独算再平均，不能拿月度值直接除。

绝对量那条你说得对，补一个取证细节：「包数涨 30 倍」这种结论，--json h 的小时粒度其实不够用，vnstat 数据库最小间隔就是 UpdateInterval（默认 30 秒），小时视图是聚合后的结果，短时突发还是会被摊平。真要提交工单，就在攻击窗口内拉 5 分钟视图（配置里开了 5MinuteHours 才有），或者用 --begin/--end 拉更短时间范围，同时用 ip -s link 打点对齐，两边互为佐证才站得住。

--dumpdb 我印象里 d; 行只有字节、没有包数，但版本间字段有增补，所以先 grep 确认这一步必须做。另外从 1.x 升级来的库，--json 里 packets 字段可能存在但值为 0，脚本里判断要用 (.tx.packets // 0) > 0，光靠 has("packets") 会误判。

restorecon 之后重启这点我赞同，再补一句：重启前先 matchpathcon /var/lib/vnstat/vnstat.db 看一眼期望的 context，对不上说明策略本身有问题，-R 只是把当前策略重新应用一遍，修不了策略。最后提醒个容易漏的：恢复备份后 vnstatd 会拿当前 /proc/net/dev 累计值当新基线，跟备份历史之间有空档，那天在图上显示无数据、cron 的 tsv 也少一行，别当成脚本挂了去排查。

结论：交叉验证这条我赞成，但别拿月度值跟月度值直接除，要把 m 的比值和 h 逐小时比值的加权平均对一次；对不上时，再区分是边界取整的问题还是时区的问题。

具体做法是把两个视图都输出成 tsv，再按年月分组合计：

vnstat --json m | jq -r '.interfaces[0].traffic.months[] | [.date.year,.date.month,.tx.bytes,.tx.packets // 0] | @tsv'
vnstat --json h | jq -r '.interfaces[0].traffic.hours[] | [.date.year,.date.month,.tx.bytes,.tx.packets // 0] | @tsv'

后一个先按 year+month 加总再相除。如果两个比值相差超过 1%，基本就是你提到的单侧取整；如果能对上，就说明加权分配是同源的，可以放心使用月度比值。还有一个容易误判的干扰项：跨 DST 或库的时区配置和系统时区不一致时，小时桶归属会整体偏移一小时，表现为某个整点数据异常，看起来像取整，实际是 tz 问题；排查时先执行 vnstat --json dbversion，再顺带看一眼配置里的时区项。

短窗口取证那块我同意，不过要强调时效性：5 分钟视图默认只保留几个小时（5MinuteHours），攻击发生后再回头补拉是拉不出来数据的。所以实际操作时，要么当时就用 vnstat --json f 落一份，要么用 --begin/--end 锁定区间并立刻导出；工单里贴时间窗时，把 ip -s link 打点的时刻一并写上，两边才能互证。

dumpdb 那个必须先 grep 再写解析，这点没问题。packets 为 0 的老库用 (.tx.packets // 0) > 0 判断，比 has() 稳，我这边脚本已经这么写了。基线空档我的处理是在恢复前把 /proc/net/dev 当前累计值单独存一份 marker，tsv 脚本发现缺行时先比对 marker 时间，落在窗口内就跳过不告警，恢复后第一天的数据也不进报表，免得后面有人拿它算基线。

最后补一句：恢复时先停 vnstatd 再动库文件，运行中直接替换 .db 有写坏的风险，matchpathcon 检查完策略再 restorecon -Rv，顺序别反了。

结论：交叉验证这条思路我完全认同，但「加权平均」需要说清楚——如果小时桶完整覆盖了该月，sum(tx.bytes)/sum(tx.packets) 在数学上恒等于月度值，两者永远相等，所以真正能检出单侧取整的只有「逐小时比值再平均」这种算法，而它本身又会被低流量小时放大误差。我一般两样都算：先看合并值是否严格相等，不相等就直接判定为聚合异常；再用小时比值的算术平均做二道确认，两者差异超过 1% 才去怀疑取整。

1% 这个阈值建议按包数量级放宽，包数只有几万的小流量月份，单侧取整造成的偏差本来就容易破 1%，误报率会很高；月包数在百万以上再收紧到 0.5% 比较合适。

时区那块我有同感，vnstat --json dbversion 只能确认库结构，真正的时区相关配置项名字我记得不太准，建议直接 grep -in time /etc/vnstat.conf 看一遍更保险，别照着我说的项名去改。另外 --begin/--end 超出保留范围时 vnstat 会静默截断，脚本里最好校验输出条数是否符合预期，否则拿到一份缺数据的区间还以为自己取全了。

marker 那条补一个坑：/proc/net/dev 的累计值在重启后会归零，光存时间戳比对会把「重启后第一份数据」误当成正常基线，建议 marker 里同时记 /proc/sys/kernel/random/boot_id，boot_id 变了就直接跳过那一天。

停 vnstatd 再换库的顺序没问题，换完启动前可以先 vnstat --dbdir /tmp/vtest -i eth0 指到临时目录试跑一次，确认能正常读再加回生产路径，比直接替换稳妥。