带宽被占满导致业务中断时，第一时间要做的不是找谁在下载，而是立刻切断异常连接或临时扩容，先恢复业务再说。很多运维人员把时间浪费在“定位凶手”上，结果业务挂了半小时，正确的顺序永远是：先止损，再排查，后加固。
业务中断的第一现场：快速止损恢复可用带宽
带宽拉满的瞬间,你手头最有效的工具是防火墙、交换机ACL和云平台的安全组，不要试图在服务器内部用脚本去杀进程，那太慢了。
- 云服务器用户：直接登录云控制台，在安全组入方向规则中，临时拒绝所有来源IP的UDP流量，或封禁目标端口，大多数流量型攻击集中在UDP 53、UDP 123或高段位随机端口，先封了，带宽立刻回落。
- 物理机用户：登录核心交换机，找到服务器接入口，执行ACL策略，丢弃该端口上超过阈值的特定协议包，命令参考：
access-list 100 deny udp any any eq 53，然后应用到接口方向。 - 通用兜底操作：如果分不清是什么协议占满，就直接在服务器上执行
iptables -I INPUT -p udp -j DROP，把UDP全部切断，TCP业务通常不受影响，而UDP洪水是带宽消耗的元凶之一。
一个容易忽略的动作是检查带宽计费模式，如果你的带宽是按固定峰值计费，拉满就是烧钱；如果是按95计费或按流量计费，瞬间的峰值可能让当天账单直接翻倍，止损的另一个含义是：立刻去云控制台把带宽临时升到3-5倍，多数云厂商支持实时升配，几分钟生效，这看似是“花钱买平安”，但在业务中断的每一分钟损失面前，这点钱微不足道。
带宽被占满怎么排查：三步定位元凶
止损之后,业务恢复了，但问题没解决，接下来用三步走把元凶揪出来。
第一步：看流量走向，区分入站和出站
登录服务器,执行iftop -n或nload，直观查看当前流量是进的方向大还是出的方向大。
- 入站流量高：外部请求打进来的，可能是CC攻击、DDoS，或者某个API接口被刷。
- 出站流量高：服务器主动向外发包，可能是服务器被植入挖矿木马、被入侵后当肉鸡发起攻击，或者业务代码存在死循环发送数据包。
这一步不需要专业知识,看数字的箭头方向就能判断，如果iftop没安装，用yum install iftop -y或者apt install iftop -y装一个。
第二步：按连接定位，找具体IP和端口
执行netstat -antp，按连接数排序：
netstat -antp | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20
这个命令的意思是：统计所有TCP连接中，哪个来源IP的连接数最多，正常业务下，单个IP的连接数很少超过几十，如果看到某个IP有几百上千个连接，基本可以锁定。
再确认这些连接在访问什么端口：
netstat -antp | grep <异常IP> | head -50
如果连接集中在80/443端口，且来自同一IP段，大概率是恶意请求，如果连接指向不常见的端口如4444、6666，那可能是木马回连。
第三步：抓包确认，看包内容
连接信息只能说明“谁在连”，抓包才能看清“在传什么”，用tcpdump抓取异常IP的流量：
tcpdump -i eth0 host <异常IP> -c 100 -w /tmp/cap.cap
抓100个包存下来,然后拉取到本地用Wireshark分析。看包长度分布：如果都是512字节或1024字节的固定大小包，且间隔均匀，基本是流量攻击，如果包内容里有明文指令字符串，那可能是木马通信。
行业共识认为,80%的带宽异常出站流量源于服务器被植入挖矿程序，剩余部分才是外部攻击，挖矿程序的特征很明显：CPU占用率飙升、出站连接指向矿池端口（如3333、4444、5555）、域名是陌生的一长串字符。
服务器带宽异常是攻击还是故障：快速判断依据
这个问题直接决定你下一步做什么,判断依据很简单，看三点：
| 判断维度 | 攻击场景特征 | 故障或木马场景特征 |
|---|---|---|
| 流量走向 | 入站流量远大于出站 | 出站流量异常大 |
| 源IP分布 | 分散，跨地域，来源数多 | 集中在少数几个IP |
| CPU与IO | 正常或略高 | CPU满载，磁盘IO异常频繁 |
| 流量曲线 | 突然飙升，呈直角拉升 | 平缓上行，或间歇性波峰 |
流量曲线是最直观的判据，去监控系统里翻带宽图：
- 如果曲线是一根直线垂直拉满，持续平坦，那是高强度DDoS。
- 如果是锯齿状波动，一会儿满一会儿掉，可能是业务被刷或木马在“工作-睡眠”切换。
还有一个更实际的办法：看带宽峰值的持续时间，DDoS攻击往往持续数小时甚至数天，而业务突发流量通常几分钟内回落，如果你刷新三次流量图，每次数据都在涨，那基本可以判定为攻击。
封禁异常IP的落地操作：从服务器到防火墙
找到异常IP后,封禁操作分两层做，只做一层不够。
服务器层封禁：立刻断掉连接，用iptables封源IP：
iptables -I INPUT -s <异常IP> -j DROP iptables -I OUTPUT -d <异常IP> -j DROP
两条命令分别封入站和出站,注意顺序，-I插到最前面，优先级最高。
防火墙层封禁：云服务器在安全组里封禁，物理机在硬件防火墙封禁，这一步的意义在于，让流量在到达服务器之前就被丢弃，不占用服务器网卡的处理能力。
如果异常IP量很大,几百上千个，手动封禁不现实，这时候写个简单脚本循环封禁，或者用云服务商提供的DDoS防护策略，开启黑名单自动添加功能。
顺带提一句,很多人在这个环节犯一个错误：只封了IP，没封端口，攻击者换个IP照样打，正确的做法是，对于明确是攻击目的的大流量，封IP的同时也要在业务侧限制该IP的并发数，比如Nginx层面配置：
limit_req_zone $binary_remote_addr zone=perip:10m rate=5r/s;
这个配置限制单个IP每秒最多5个请求,能有效拦截应用层攻击，同时不影响正常用户。
日常防御：让带宽占满事件不再发生
处理完一次突发,如果什么都不改，下次还会踩同一个坑。
部署带宽告警：不要等带宽到100%才收到通知，监控阈值设置为带宽使用率超过70%时就告警，给你留出30%的操作余量，据工信部近年的安全通告数据，带宽型攻击在夜间和节假日高发，所以告警不要设在工作时间，7×24小时推送。
限制单IP并发连接数：在负载均衡层或Nginx层配置连接数限制，同样的IP地址同时建立的连接数控制在50个以内，正常用户不会超过这个数，但CC攻击会轻松破千。
内网出口限速：如果服务器是内网架构，在核心交换机上给服务器端口做双向限速，比如业务带宽是200M，就把服务器端口限速在220M，留出冗余但又不至于让异常流量无限制地冲垮整个机房的带宽池。
定期检查连接数基线：每月抽一个时间点，抓取netstat -anp的数据保存下来，连续记录3个月后，你会清楚地知道自己的服务器平时有多少连接、连到哪些端口，有了这个基线，下次异常发生的时候，对比一下就能快速定位异常点。
相关问题
带宽突然跑满会导致服务器卡死吗？
会，服务器网卡处理能力饱和后，内核网络协议栈出现拥堵，正常业务的数据包无法被及时处理，应用层表现为响应慢、超时，最终是业务完全不可用，CPU会因为处理大量中断请求而飙升，出现恶性循环，这也是为什么重启服务器往往收效甚微只要异常流量还在，重启后依然会被拉满。
带宽被占满会影响其他服务器吗？
取决于架构，如果是云服务器且独享带宽，只影响自己，如果是物理机或共享带宽池，一台服务器的异常出站流量可能耗尽整个机房的出口带宽，造成同机柜甚至同交换机下的其他业务集体丢包，这个问题在中小IDC中尤为常见，处理方式是在机房出口做每端口独立限速策略。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/793470.html
