下载站半夜带宽跑满，九成不是真的访问高峰，而是定时任务、盗链、恶意采集或者回源异常在作怪。 与其盲目加带宽，不如先花半小时做一次流量画像分析，按”流量定性→连接分析→策略调整”三步走,多数情况下两小时内就能定位根因。
半夜带宽跑满，先分清是真忙还是假忙
凌晨两点，监控平台突然弹出一片红色告警，第一反应是被人打了？先别急着抓包，登录服务器看一眼流量方向，比什么都管用，半夜带宽跑满有一种典型的假象：带宽占满了，但网站访问量并没有涨，这时候要做的第一件事,就是判断流量到底是进还是出。
看实时带宽跑满的方向
登录服务器,一条命令快速确认：
- 用
iftop -i eth0 -n看实时连接，按流量排序,找出占带宽最多的几个IP。 - 用
vnstat -l看最近五分钟的实时速率,确认上下行占比。 - 用
nload看图形化的流入流出趋势，rx是接收,tx是发送。
这里有个容易忽略的细节：下载站对外提供文件下载，正常流量是下行大、上行小，如果反过来，上行跑满，大概率是服务器在往外推数据要么是备份同步，要么是被攻击者当了跳板，这个方向判断错了,后面全白查。
看连接数和单一IP占比
方向上没问题，就要看连接结构，半夜带宽跑满报警时,先统计连接数：
netstat -anp | grep :80 | wc -l
netstat -anp | grep :80 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20第一条是总连接数，第二条是单IP连接数排名,两种典型情况对应两种不同结论：
- 连接总数几百，带宽却满着单大流量下载在拖文件，比如迅雷离线下载、IDM多线程拖走整个压缩包,或者凌晨跑的采集程序。
- 连接总数破万，来源IP分散恶意请求的概率大,比如CC攻击或全网扫描。
从时间维度再看一眼：如果每天固定在凌晨两点到四点准时跑满，那先别怀疑黑客，很大概率是你服务器上自己的计划任务在作妖，行业共识认为，正常下载站的凌晨流量曲线应该是一条平稳的低谷,不该有明显尖峰。
下载站带宽跑满怎么办？先查定时任务
这一步最容易忽略，却也最常见，很多站长把半夜带宽跑满归咎于被攻击，查了一圈防火墙，最后发现是服务器上挂着的自动备份脚本在搞鬼，定时任务的问题,十个里有八个是这种画风。
排查crontab里的意外任务
用管理员账号依次执行：
crontab -l
cat /etc/crontab
ls /etc/cron.d/ && ls /etc/cron.hourly/ && ls /etc/cron.daily/重点找三类可疑项：
- 整点或半点执行的脚本，比如数据库备份、日志切割、文件同步。
- 命令行里出现了wget、curl、rsync的传输任务。
- 任务目标指向外部IP或云存储地址。
真实场景里就有过这种坑：网站程序里的自动备份插件，每天凌晨三点把SQL和附件打包传到云存储，一次传输几十GB，把100M带宽直接怼满，把那个定时任务注释掉,流量曲线立刻恢复平稳。
看Web日志里的规律性请求
定时任务不只在crontab里，网站程序自带的计划任务同样是半夜带宽跑满的惯犯,典型场景：
- WordPress的wp-cron.php，触发频率设置不合理,导致反复拉取外部更新。
- 会员系统的邮件队列，白天积压了一整天,凌晨一次性发送。
- CDN回源预热脚本，定点批量刷新缓存,引发回源流量激增。
这时候翻Web日志最直接：
grep "03:00" /www/logs/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head如果某些IP在固定时间点规律性出现，行为单一且访问路径固定，基本就是程序任务,不是真实用户。
用流量连接分析定位盗链和恶意采集
定时任务查完没收获，就该往外部找原因了，凌晨正好是采集程序和盗链最活跃的时段，它们专挑站长睡觉的时间干活，这两个问题各自有鲜明的流量特征,对比起来很容易分辨。
| 判断维度 | 真实用户下载 | 恶意采集/盗链 |
|---|---|---|
| 请求规律 | 时间随机，上下行均衡 | 间隔均匀，路径固定 |
| 单IP请求数 | 通常个位数到几十次 | 上千次以上 |
| UA特征 | 浏览器混用 | 单一工具或伪造随机UA |
| Referer | 站内或空 | 外部域名集中 |
识别盗链的典型特征
盗链有两个显著标签：Referer不是你的站点域名，User-Agent集中在某个下载工具或采集器,抓一下Referer分布：
grep "http://" /www/logs/access.log | awk '{print $11}' | cut -d/ -f3 | sort | uniq -c | sort -nr | head -20如果排名靠前的是一堆外部影视站、资源站域名，那就直接上防盗链策略，现在很多盗链工具会伪造Referer，所以这一步只能作为参考,真正的判定还要结合单IP下载量和UA特征一起看。
识别恶意采集的流量特征
采集不直接拖走文件，而是一遍遍抓取下载页、搜索页，消耗的是动态请求的带宽和数据库连接,这类流量的特征是机器味十足：
- 对某个目录或搜索页面高频访问，间隔均匀,精准得像闹钟。
- 单个IP每天请求数千次,页面停留时间接近零。
- 访问路径固定：先首页进列表页，再从列表页进下载页,从不点击外链。
针对采集，业内专家建议在Nginx层配置限速和并发限制，比单纯封IP更长效,下面这段配置可以直接落地：
limit_req_zone $binary_remote_addr zone=crawl:10m rate=5r/s;
server {
location / {
limit_req zone=crawl burst=10;
limit_conn perip 10;
}
}
下载站服务器带宽怎么选？先看完流量曲线再决定
如果定时任务没有、盗链没有、采集也没有，流量就是实打实的用户下载，那问题就变成了资源规划问题：现有带宽压根不够用,这里给个参考公式：
总带宽需求 ≈ 热门文件大小 × 平均同时下载人数 / 8 × 冗余系数
单个文件500MB，平均同时有30人下载，那瞬时流量就是500×30=15GB，换算成带宽要预留至少1.5Gbps（不含冗余），这种情况下100M带宽白天跑不满就怪了，半夜看起来没那么挤，但根源是容量不足,加带宽才是正解。
下载站半夜带宽跑满的防护策略怎么落地
定位根因只是第一步，把防护措施落地才是目的，下面的操作按优先级排列，从应急到长效,可以照顺序执行。
封禁恶意IP与限流
先用脚本把连接数异常的IP揪出来：
netstat -anp | grep :80 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20单IP连接数超过100的,直接封：
iptables -A INPUT -p tcp --dport 80 -s 1.2.3.4 -j DROP更省事的方式是配合Fail2ban，设置好阈值自动封禁，并且加上时间限制，比如封24小时后自动解封,避免误伤。
配置防盗链与UA黑名单
Nginx下针对下载文件类型配置防盗链：
location ~ .(zip|rar|7z|exe|apk|iso)$ {
valid_referers none blocked .yourdomain.com yourdomain.com;
if ($invalid_referer) {
return 403;
}
}
同时在http层拦截已知的采集器UA，把请求直接挡在Nginx这一层,不进PHP和数据库。
启用CDN和对象存储分流
如果流量确实在稳定增长，最干净的解法是把文件分发交给CDN，源站只保留后端服务，半夜带宽跑满很大一部分是文件下载流量，CDN可以直接扛住这部分压力，源站出口占用会骤然降到很低，据CDN厂商公开的技术文档，下载类站点接入CDN后，源站带宽占用普遍能降一半以上，选择CDN时注意回源策略，把大文件缓存时长拉长到30天以上,回源流量自然会进一步减少。
别被凌晨的报警短信唬住
带宽跑满本身不可怕，可怕的是没搞清楚就跑去找机房投诉，按”先查自己、再查连接、最后考虑加钱”的顺序排查，绝大多数半夜带宽跑满的问题都能靠自己解决。先看流量方向，再翻定时任务，然后分析连接来源，层层排除后剩下的才交给带宽扩容去解决。 下次半夜再收到告警，先登录服务器看一眼睛crontab,多半会有意外收获。
关于下载站半夜带宽跑满排查的常见问答
下载站半夜带宽跑满，要不要直接升级带宽？
不建议，半夜跑满和白天高峰跑满的原因完全不同，白天跑满大概率是真实用户需求，半夜跑满优先排查定时任务和盗链，不定位原因就升级带宽,等于花钱养着一群采集器。
网站半夜流量异常，怎么区分CC攻击和正常爬虫？
看单IP连接数和请求频率，CC攻击通常是大批IP同时高频请求，且集中在同一个URL上；正常爬虫UA特征明确，请求间隔规律，访问路径符合爬虫逻辑，配合netstat看TCP连接状态，如果SYN_RECV占比明显偏高,CC攻击的可能性就很大。
下载站服务器带宽怎么选才够用？
没有固定答案，取决于文件大小、并发下载数和是否使用CDN，个人小站、文件在几百MB级别，50M到100M足够；面向全网公开的软件或游戏下载站，建议至少G口起步并配合CDN分发，多数情况下，中等带宽加CDN分流比一味拉大带宽更省成本，国内主流云厂商的按量付费带宽通常比包年包月贵出一大截,采购前先把流量模型算清楚。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/759173.html
