Alibaba cloud international server special offer

腾讯云服务器带宽跑满：流量去哪了，账单为什么翻倍

客户在电话里说这个月账单翻了三倍，业务量一点没变，问是不是平台算错了。我把监控拉出来，出带宽曲线在凌晨两点到四点亮成一片，白天反而是平的——这不是业务，这是有人在夜里替他“用”服务器。腾讯云服务器上出现带宽跑满，账单只是最后的症状，真正要回答的问题是：这些字节是谁发出去的，从我哪个端口出去的。

先把计费口径摆正：出带宽、入带宽和两种计费

公网方向要分开看。出带宽是从实例流向公网，按带宽计费时它被买来的上限卡着，按流量计费时它直接换成钱；入带宽是公网流向实例，通常不单独计费，但有上限。所以“网站被大量下载”和“服务器自己在下载别人的东西”，成本结构完全不是一回事。监控里那两条线必须分开读，混着看只会得出“带宽就是满了”这种没用的结论。

再看计费方式，这决定异常流量会以什么形式打到你身上。按带宽计费，买的是一个固定天花板，超了就限速、丢包、排队，账单不会随流量线性上涨，代价是业务在峰值时变慢。按使用流量计费，天花板高甚至不设，账单随出流量线性增长，代价是被人刷一夜就可能很难看。轻量应用服务器是第三种形态：套餐里带宽和月流量包同时给，带宽先到顶就限速，流量包先用完再按产品规则处理，具体以文档和控制台为准。

这三种形态下，“跑满”的含义完全不同。按带宽跑满，是业务受损；按流量跑满，是钱包受损；轻量套餐跑满，是两者一起。

三种跑满形态，曲线的形状先告诉你方向

持续贴顶。 曲线是一条长时间贴着上限的直线，白天黑夜一个样，max 和 avg 几乎相等。这种多半是真实流量：资源下载站、软件分发、图片站被大量引用，或者 CDN 配了但回源集中打到源站。也可能是被大流量镜像抓走了整站。

周期性尖峰。 每天固定时段冲高，十几分钟到一小时回落，形状像心电图。这个用 crontab -l 一对就出来了：数据库 dump 之后传到公网、跨地域同步、日志外发、监控拉全量报表、备份直接 rsync 到另一台公网机器。这类流量有个特点——它是你自己制造的，所以最容易被忽略，也最好解决。

夜间突增。 凌晨一到五点之间突然拉高，白天恢复正常。这个方向就不一样了：扫描与爆破、盗链、被当成代理节点、木马外联、境外爬虫集中抓取。夜间没人盯监控，是这类流量最喜欢的时间窗。

我判断顺序是先看形状，再看是不是业务，最后才看是谁。腾讯云服务器的出带宽曲线不会骗人，但读懂它需要一点耐心。形状错了，后面全错。

从曲线到进程，我实际用的定位路径

第一层看云监控。出带宽、入带宽、连接数三条线一起看，粒度选最短的，重点看 max/avg 的比值和峰值的起点时间。同时瞄一眼 CPU 和磁盘 IO：带宽高而 CPU 低，通常是静态分发；带宽高且 CPU 也高，可能是动态请求或加密流量；带宽高但磁盘几乎不动，说明内容不在本地盘上，走的是内存或上游回源。

第二层看连接分布。ss -s 先给一个总量，再按来源 IP 聚合：ss -tan state established 的输出里取对端地址那一列，按 IP 排序计数。这一步的判据很实用——连接数几万、每条连接流量很小，是 CC 或者高并发爬虫；连接数正常、单条连接流量很大，是大文件下载或者盗链；连接数少、出带宽贴顶，可能根本不是 TCP，去看 UDP。

第三层看进程。iftop -nNP 看实时对端排序，nethogs 看进程级占用。这里有个坑：容器里的进程，宿主机上的 nethogs 未必能对应到具体容器，得结合 docker stats 或者 cgroup 的统计看。

第四层看访问日志。按 IP 统计前二十，按 UA 统计，按 URL 统计大文件，再按 Referer 看有没有别人的域名。Nginx 的日志格式里如果没有记录 $request_time 和 $body_bytes_sent，建议加上，否则你只能知道“有人访问”，不知道“谁把带宽吃掉了”。

第五层做反向确认。CDN 开了，回源是不是还在直连源站 IP？对象存储里的图片是不是被别的站直接引用？这两件事都属于“你付了 CDN 的钱，流量还是从源站出来”。

第六层排除自己人。备份窗口、日志外发、监控上报、镜像同步、跨地域复制，这些任务在账单上和在攻击上长得一模一样。

一条很省时间的判据：访问日志里有对应流量，问题在应用层；日志里没有但出带宽很高，去看非 HTTP 流量。 前者修配置，后者要查入侵。

把上面几条线索收在一张表里，现场就按这张表逐行对：

流量形态 典型成因 观测入口 止损动作

持续贴顶，昼夜无差 资源下载站、软件分发、CDN 回源集中打到源站 云监控出带宽日曲线，配合访问日志的 URL 维度 静态资源切到 COS 加 CDN，源站只留动态请求

每天固定时段尖峰 数据库 dump、跨地域同步、日志外发走公网 出带宽曲线时间点与 crontab 逐条对齐 备份改走内网或对象存储内网端点，错峰执行

凌晨突增后自行回落 扫描爆破、盗链、被当代理跳板、木马外联 连接数曲线、ss 来源 IP 聚合、iftop 对端分布 安全组限源，关掉非必要端口，轮换密钥与账号

出带宽高但访问日志几乎没量 非 HTTP 流量：代理、挖矿、邮件中继、自定义端口 nethogs 进程级占用，ss 看监听端口 定位进程与启动项，留存证据后再决定是否重装

单个 URL 占用绝大部分流量 安装包或视频被外站直链，图片被盗链 访问日志的 URL 与 Referer 维度 加 Referer 校验、签名 URL、对象存储开防盗链

连接数暴涨但单连接极小 CC 攻击、高并发爬虫、短连接未复用 ss -s 总量、WAF 日志、UA 维度统计 WAF 频控加 Nginx 的 limit_req 与 limit_conn

轻量套餐带宽与流量包同时见底 套餐额度用尽，之后限速或转按量 轻量控制台的流量包用量与实例监控 先压流量，再评估升套餐或迁到 CVM

两种计费方式，遇到异常流量时差在哪

按带宽计费像包月的水管，管径固定。被刷的时候水压下降，你的正常用户先受影响，账单不动。这种模式适合日均流量平稳、能接受峰值受限的业务，比如内部系统、API 服务、访问量稳定的企业站。

按流量计费像按吨买水，管子粗，但每一吨都记账。被刷的时候业务不一定卡，账单会先炸。它适合波峰波谷差距大、平时流量很低的业务，比如有活动期的电商、季节性明显的报名系统。用这种模式，出流量告警和用量上限必须配，不然等于把钱包交给陌生人保管。

切换计费方式不是随时来去自由的，生效规则、变更次数、结算周期都以控制台账单页面的说明为准，别在故障当晚临时改，改完的计费口径跟你想的可能不一样。

我的建议很朴素：新业务先按流量跑满一个完整月，看清日均、峰值和峰谷比，再决定要不要锁带宽。有推广计划的，提前把带宽顶上去，活动结束调回来，别让活动页把整月预算吃掉。

爬虫、AI 训练爬虫与盗链：哪些流量不算业务

现在抓取流量的构成比几年前复杂。搜索引擎的正常收录、各类 AI 训练语料爬虫、聚合站、比价站、以及大量伪装成浏览器的脚本，混在一起。判断不能只看 UA 字符串，那东西可以随便写。能做的验证是反向解析来源 IP 看归属，再结合请求频率、请求路径的规律性（是否只抓列表页、是否无视 robots、是否集中在夜间）。

robots.txt 是声明，不是强制。遵守的爬虫会读，不遵守的照抓。所以对确认高频且不遵守规则的来源，处理位置应该放在 WAF 规则或者 CDN 层，而不是只改一个文本文件然后等它自觉。

按 UA 直接封是个危险动作。我见过有客户一刀切封掉某类 UA，顺手把正常的收录也封了，两个月后才发现关键词排名掉了一半。正确做法是先按 UA 维度限速，观察一周，确认影响面之后再收紧。

盗链是另一条线。图片、视频、安装包被别的站直接引用，源站出带宽上涨，日志里 Referer 全是别人的域名。处理手段是 Referer 白名单、给下载链接加签名和过期时间、对象存储侧开防盗链。要注意的是空 Referer 的请求要单独想清楚放不放——有些正常用户从 App 里点进来就是空 Referer，一刀切会误伤。

还有一个最容易被忽略的：源站 IP 泄露。CDN 配好了，但源站有公网 IP，而历史 DNS 记录、证书透明度日志、邮件头、甚至论坛帖子都可能把它暴露出去。攻击者拿到源站 IP 就直接打源站，CDN 形同虚设。必要动作是换一个干净 IP，并且只允许 CDN 的回源网段访问源站的业务端口。

止损四层：先留证据，再止血，最后才优化

第一层是安全组和防火墙限源。只放行必要端口和必要来源——CDN 回源段、办公出口 IP、运维跳板。这一层一分钟就能生效，但它同时会挡住你正在看的证据，所以顺序必须是先抓一份 ss 输出、一份日志片段、一份 iftop 截图，再去改规则。

第二层是应用层限速。limit_req_zone 控请求速率，limit_conn_zone 控并发连接，limit_rate 控单连接下载速度。下载类 URL 单独限速，不要整站限，整站限会把正常用户一起限死，投诉电话比攻击更难受。

第三层是 WAF 与 CDN 兜底。CC 防护、频次控制、人机校验放在前面，静态资源上 CDN，让源站只见回源请求。这一层生效需要时间，DNS 和缓存都有惯性，别指望改完立刻见效。

第四层才是计费和规格。临时升带宽、临时换计费方式，本质是花钱买时间，让业务先活下来，它不是解决方案。而且规格变更的生效方式和结算规则要提前确认，故障当晚现查文档很容易踩空。

顺序如果反了，你会得到一个很典型的结局：止血成功了，攻击停了，但你不知道是谁打的，下周同一时间它还会来。

把带宽当成本项：长期要做的几件事

静态资源全部搬到 COS 加 CDN，源站只处理动态请求。这一条能解决大部分“带宽不够用”的问题，而且顺带把源站 IP 藏起来了。

图片按需处理。首页几张几 MB 的原始图，是带宽最沉默的杀手。转 WebP 或 AVIF、按展示尺寸裁切、懒加载，三件事做完，首屏流量能降一大截。

开压缩、合并请求、减少首屏请求数。gzip 和 brotli 对文本类资源的效果很直接，字体文件本地化能省掉第三方请求，视频一律走点播而不是从 CVM 直出。

备份和同步改走内网或对象存储内网端点。同一个地域内的内网流量不计公网出流量，这个改动通常只需要换一个域名。

告警设两档，七成和八成五。等到 100% 才告警，你收到消息的时候业务已经在排队了。

FAQ

Q：账单翻倍，但监控里的出带宽峰值并不高，是怎么回事？

A：按流量计费时，账单跟你一个月累计发了多少字节有关，跟峰值关系不大。峰值不高但持续有量，累计一样会上去。另外要逐项核账单明细：跨地域的内网跨区流量、NAT 网关、负载均衡、对象存储的外网下行、快照或镜像的跨地域复制，都可能单独计费，不一定体现在这台 CVM 的出带宽曲线上。

Q：带宽跑满会不会连 SSH 都进不去？

A：会。公网带宽打满时新建连接很难挤进去，表现出来就是 SSH 卡住或者超时。这时候优先用控制台的 VNC 或者远程登录，或者从同内网的另一台机器连内网 IP，别在公网上反复重试。

Q：轻量应用服务器的流量包用完了会怎样？

A：按产品规则处理，常见是先限速、再按量计费或者暂停公网访问，具体以控制台提示和文档为准。轻量的套餐是带宽加流量包绑定的，别把它当成不限量。用轻量跑下载类业务之前，先把流量包的量级算清楚。

Q：直接把带宽升上去不就行了？

A：升带宽只是把天花板抬高，流量还在涨，账单会跟着涨，而且攻击者也会跟着把你的新上限打满。正确的顺序是先定位是谁在发流量，能挡的挡掉，能挪的挪走，最后才是升规格。

结语

今天能做的三步：打开云监控，把这台腾讯云服务器的三十天出带宽曲线和 crontab 时间表放在一起对一遍，先认领自己制造的那部分流量；给出带宽设两档告警，七成和八成五，通知到人而不只是一个群；把首页的图片和静态资