那天凌晨2点17分，手机短信轰炸般响起——宝塔面板的带宽监控预警红彤彤地弹出：“出站带宽连续5分钟超过80Mbps”，我揉着眼睛爬起来，心想这破服务器平时峰值也就20M，半夜哪来这么猛的流量？第一反应是遭贼了,被植入挖矿脚本或者被DDoS了。
踩坑第一步：我像个无头苍蝇一样直接去看了实时流量图
打开宝塔的“监控”页面，那条曲线确实像心电图发疯，锯齿状往上蹿，出站带宽直接顶到100Mbps的物理上限，但奇怪的是，CPU和内存负载却低得可怜，只有个位数，这就很诡异了——正常被DDoS的时候，CPU会先崩掉，因为要处理海量无效连接；如果是挖矿，CPU必然飙红，所以我当时断定：这不是服务器自身资源吃紧，而是有东西在“纯吐”流量，不带任何计算压力。
报错截图描述（凭记忆复述给排查用的关键信息）：
当时我截了三张图：第一张是“带宽监控”页，显示 eth0 出站流量爆表，入站几乎为零；第二张是“进程列表”按网络排序，但奇怪的是没有任何可疑进程占满网络；第三张是“系统日志”，全是重复的 kernel: TCP: time wait bucket table overflow，第三张图其实才是真正要命的线索,但当时我忽略了。
宝塔面板带宽监控半夜报警，我差点把服务器供应商客服骂哭—这5个坑你们千万别再踩
坑中坑：我第一个想到了“是不是宝塔的监控插件坏了？”
别笑，这是真事，因为之前宝塔有一次更新，把流量统计的接口从 /proc/net/dev 改成了 netlink 方式，结果统计翻倍了，所以我干了一件蠢事：把宝塔的监控插件关了重启，又清了缓存，没用，然后我又去看了 iftop 和 nethogs，结果发现 iftop 显示的流量峰值只有30M，和宝塔的80M完全对不上！ 那一刻我几乎确定了是宝塔的统计bug。
直到我打开了宝塔的“计划任务”列表，真相差点让我把键盘砸了。
里面躺着一个我三天前写的Shell脚本，用于每天凌晨2点把网站备份打包传到另一台存储服务器，但脚本里我用了 rsync，而且忘了加 --bwlimit 限速参数，更糟糕的是，前两天那台存储服务器跑了一个全量扫描任务，导致它的写入变得极慢，rsync 就开始疯狂重试，每次重试都会把本地老数据重新读一遍再传，这相当于我自己的备份脚本，在给自己服务器做“自杀式DDoS”——数据在出站口堵成一团，反复重传,带宽直接拉满。
排查思路复盘（你们以后遇到“带宽爆了但CPU正常”的情况，按这个顺序来）：
- 先看入站还是出站——如果和我一样是“出站爆”，基本排除外部攻击,因为攻击大多是入站流量打满。
- 立刻用
lsof -i看连接数最多的进程，别只看CPU占用,要按网络连接数排序。 - 检查宝塔的计划任务和 Cron，特别是最近新加的备份、同步脚本,很多人忘了这茬。
- 用
iftop -i eth0 -P看具体端口——我当时要是早一步看端口，就会发现是22端口的SFTP流量（rsync底层走SSH）,而不是80或443。
解决方案（急救三步）：
第一步，直接到宝塔“软件商店”里把 rsync 对应的进程 Kill 掉（或者 pkill rsync），带宽瞬间掉回20M，第二步，改脚本，加上 --bwlimit=5000（限速5MB/s），并且加上 --timeout=60 --partial，防止死等重试，第三步，把备份任务从凌晨2点挪到凌晨4点,避开目标存储服务器的扫描时段。
预防建议（血泪总结，照着做能省下半条命）：
- 宝塔面板的带宽监控页面，建议把“出站带宽”的告警阈值设置成你平时峰值的5倍，而不是默认的“绝对值”,不然半夜容易误报。
- 所有涉及外传数据的命令，一律强制写限速参数，rsync 用
--bwlimit，wget/scp 用--limit-rate,别偷懒。 - 每周五下午看一眼“计划任务”列表，把不用的脚本注释掉，我身边至少三个朋友出过一模一样的问题,全是备份脚本发疯。
- 如果宝塔显示的流量和 iftop 对不上，优先相信 iftop，宝塔的监控是5秒采样平均，而 iftop 是瞬时值，两者差10倍都正常，但如果是“宝塔报警”吵醒你，别急着骂宝塔，前提是：先把计划任务里最近三天新增的东西全部禁掉。
最后说一句：那次排查花了我整整40分钟，其中30分钟浪费在怀疑宝塔插件上，如果一开始就去看计划任务，两分钟解决，现在每次看到服务器带宽曲线正常，我都有点PTSD，总想打开计划任务列表再确认一眼,你们千万别学我。
发表评论