上个月底客户发来一张账单,说这台机器上个月业务量没涨,出网流量却比上个月多出了三成。他一直跑着同一个站点、同一场活动、同样的流量曲线,账单却跳了一截。客户怀疑是被人刷了流量,我查了一圈,最后发现不是攻击,是三件很朴素但加在一起就不能忽略的事:协议头开销、弱网重传、还有统计口径本身就不一样。这篇就把我当时怎么算这笔账的整个过程写下来,顺带把阶梯计费、超额流量费这些容易看晕的规则也捋一遍。
如果你也在琢磨一台机器每月的流量成本到底怎么算、账单和监控面板为什么老对不上,下面这两家服务器商家的产品说明里有比较清楚的带宽和流量口径描述,可以先拿来做横向对比:profitserver(全球云服务器,不限流量套餐)、恒创科技(香港及亚太带宽资源)
我那天把机器的网络计数器按小时拉出来,和客户业务后台的下载量对了一遍。业务后台显示全天真传了 2.1TB,网卡口径算出来是 2.74TB,差了 630GB 左右。这个差值不是玄学,它基本能拆成三块:
所以「账单比实测多」这件事,很多时候根本不需要怀疑任何人,先问一句「这两个数字是同一个口径吗」。

我现在排查这类问题的顺序基本固定。第一步,读网卡计数器,这是最接近计费口径的数据:
cat /sys/class/net/eth0/statistics/tx_bytes
cat /sys/class/net/eth0/statistics/rx_bytes
这两个数是网卡视角的累计字节,会包含所有进程的收发。把它和下面这几个交叉验证,就能快速定位差距来源。
第二步,看应用层真实传输量。如果你的服务是 Nginx,用 access log 里的 $body_bytes_sent 加总,这是发出去的响应体字节,不含请求头和响应头。再往下就是业务埋点了。用一条 awk 把一天的日志加起来,几秒钟就能出结果:
awk '{s+=$10} END {printf "%.2f GB\n", s/1024/1024/1024}' access.log
第三步,用 vnstat 或 nload 看时间维度上的分布。vnstat --hours 能按小时给出收发的字节数,配合数据库里的业务量曲线一起看,很容易发现「凌晨三点还在跑流量」这种异常那次就顺手抓到过一个同事在拿服务器跑同步盘。
第四步才是抓包。tcpdump 抓一小段,然后看 seq 号的缺口和重复,能直接量化重传:
tcpdump -i eth0 -nn -c 2000 'tcp port 443' -w /tmp/cap.pcap
拿到包里重传段的比例,再乘上当天总流量,重传这块的账就算平了。三块加起来,账单和实测的差值基本能对上九成以上,剩下那一成通常是小数点进位、采样时间点错位,以及商家侧四舍五入。

说回计费本身。包月套餐里带的那个流量额度,很多商家不是「用完就停」,而是用完之后按更高的单价继续算,这就是阶梯计费。
典型的三段式是这样的:
关键在于「超出」是按整个区间的量还是按超出部分的量计价,这两种算法结果差得很多。举个数:套餐 2TB,超出后第一档单价是套餐单价的 2 倍。假设你用满了 3TB,如果按「超出部分算双倍」,你付的是 2TB 原价 + 1TB 双倍;如果按「用满 3TB 全部按双倍算」,你付的是 3TB 双倍。前者比后者省整整 1TB 的钱。所以签约前一定要问清:跳档是分段计价还是整段重算。
另一个坑是超额之后的处理方式。有的商家是限速但不收费(端口从 100M 降到 1M,流量继续跑不计钱),有的是直接停机,还有的是限速加收费。业务如果对时延敏感、只是需要大文件传输,限速不断机可能是最划算的;如果是跑对等节点或者备份任务,停机反而能逼你及时发现问题。这三种模式没有优劣之分,取决于你能不能接受。

不限流量的机器听着很香,但要看清楚它的限制在哪。常见的三种:
第一,不限流量不等于不限带宽。端口还是 100M 甚至 1Gbps,流量随便跑,但速度封顶。适合下载站、镜像站、备份机这种带宽敏感的场景;如果你要的是高并发小请求,不限流量帮不了你,因为瓶颈在端口不在总量。
第二,不限流量通常附带公平使用条款。持续跑满带宽跑满端口,可能触发限速;月流量超过某个阈值也可能被要求迁移。这类条款各家写得都不太一样,买之前最好让客服给一条明确的书面答复,别只信页面上的「不限」两个字。
第三,要看清不限的方向。有的商家不限出网但计入网(回源流量、跨机房同步就可能踩雷),有的商家双向都算。我那次帮客户对账,就是因为他以为「拉回来的流量不算钱」,结果对方的计费口径是出入双向都算,一台做数据同步的机器,账单直接翻了倍。

结合这些年的排查经历,我现在给客户的固定建议是这么几条。
第一,装一个不依赖应用的流量监控。服务器上跑一个 NetWorx 之类的工具,直接读网卡计数器,它跟计费口径的差距远比应用埋点小,也能第一时间发现异常进程。这个工具免费版就够用,win 和 linux 都有。
第二,给流量设三条线。我一般设 60%、80%、95% 三个告警阈值,分别对应「注意」「该查了」「快超额」。80% 那条线最关键,超额之后如果是分段计价,代价其实没想象中高,但如果是整段重算就非常贵。
第三,把静态资源和动态接口分开算。如果你的流量大头是图片和视频压缩包,那优先考虑的优化手段是压缩率和缓存命中率,而不是换更大的带宽。用 gzip 或者 brotli 把体积压掉三成,效果比把端口从 10M 提到 30M 直接得多。
第四,跨机房同步和备份流量单独记账。这类流量往往是突发且单向,容易在月结时吓你一跳。可以用 iptables 或者 tc 工具给这类流量打上单独的标记,在监控里拆出来看,账才算是算明白了。
说到底,流量这件事没有神秘的公式,它就是「网卡上跑过的字节」乘以「那个区间的单价」,难的是把它和业务量对上、和合同条款对上、和每天的监控曲线对上。把口径统一了,账单上多出来的那三成就再也吓不到你了。