带宽被打满时，最先要做的是区分“核心业务流量”和“非核心流量”，然后临时掐断或限制后者，把有限的带宽让给核心业务。很多团队一看带宽跑满就急着加带宽，其实先花五分钟做一次“流量分诊”，往往能直接缓解卡顿，甚至不用花钱。
带宽被打满怎么处理：先给核心业务留一条活路
带宽被打满,服务器响应变慢，用户端会出现加载转圈、视频卡顿、接口超时等连锁反应，行业共识认为，解决这类问题的优先顺序是“先止血、再排查、后根治”，临时缓解的核心思路只有一个：别让所有流量抢同一条路，先保命再谈优化。
具体操作时,可以参考以下三步：
- 第一步：确认带宽是真的跑满，还是只有某台机器跑满
- 第二步：找到占带宽最大的IP、进程或域名
- 第三步：给非核心流量限速、断连或丢包
如果是云服务器,登录云厂商控制台看“带宽监控”图表，能直接看到出入方向峰值，如果是自建机房，登录核心交换机或路由器查实时流量即可，有相当一部分业务卡顿，其实不是带宽总量不够，而是某个时段有异常流量把带宽“堵死”了。
查流量，第一时间定位谁在“抢跑道”
解决带宽被打满的前提是知道谁在吃带宽，直接在服务器上跑命令是最快的，不用装额外的商业工具。
用iftop快速锁定“流量大户”
登录服务器,执行：
iftop -i eth0 -n -B
按P键按端口排序，按T键按累计流量排序，几秒钟内就能看到哪些IP占用了大量带宽，如果是对外提供服务的公网IP，那很可能是正常业务峰值；如果是陌生IP或内网IP，就要警惕异常访问或内网程序在“偷跑”流量。
用nethogs定位具体进程
iftop只能看IP,想看是哪个进程在掏空带宽，用nethogs：
nethogs eth0
打印出来的列表会直接显示PID、进程名和上下行流量，多数情况下，罪魁祸首不是Web服务本身，而是备份任务、日志同步、监控采集或者某个Java进程里的“死循环”。
两种方法需要root权限,如果对命令行不熟，也可以用云厂商自带的“流量用量排行”功能，简米云、酷番云的控制台里都有类似入口，只是数据会有一定延迟，不如命令实时。
带宽不足临时解决办法：限流与优先级管理
定位到“流量大户”后，就要动手做限流，这一步目标很明确：在花一分钱的前提下，把带宽留给核心接口和主页。
在Nginx层临时限制单IP并发
Web服务对外占带宽,可以用Nginx的limit_req模块做临时限制，在虚拟主机配置里加：
limit_req_zone $binary_remote_addr zone=onelimit:10m rate=10r/s;
server {
location / {
limit_req zone=onelimit burst=20 nodelay;
proxy_pass http://backend;
}
}
这样单个IP每秒最多请求10次,超出部分直接返回503，业务高峰期打完补丁后，再把rate调回正常值即可，这种方式对“被攻击”或“被刷”的场景尤其管用。
用Linux tc给不重要的端口降速
如果是内网流量在抢带宽,比如备份系统晚上跑全量备份，把MySQL的3306端口或备份端口限速，可以用tc命令：
tc qdisc add dev eth0 root handle 1: htb default 30 tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit tc filter add dev eth0 parent 1: protocol ip u32 match ip dport 873 0xffff flowid 1:1
命令把rsync使用的873端口限速到10Mbps,注意，tc配置重启后失效，需要配合cron或开机脚本使用，对于多数团队来说，把备份任务挪到业务低谷期跑，比技术限速更省事。
在云平台控制台直接下调流量阈值
云服务器的安全组和带宽计费模式也隐藏着“临时开关”，如果使用的是按固定带宽计费的云主机，可以在控制台临时降低带宽值，强制让超出部分丢包，这种操作不一定适合所有场景，但当业务本身管理失序、不确定该限制哪个IP时，能用“全局限速”让整机恢复响应。
下表整理了三种临时限流方式的适用场景,方便快速决策：
| 方式 | 适用场景 | 生效速度 | 操作难度 | 风险 |
|---|---|---|---|---|
| Nginx limit_req | 对外Web服务被高频请求打满 | 秒级 | 低 | 有误杀正常用户的风险，需谨慎设置阈值 |
| 云平台带宽限速 | 整机带宽不足且无法定位具体应用 | 分钟级 | 低 | 所有业务全被限制，包括核心服务 |
| Linux tc 流量整形 | 明确定位到某个端口或IP | 秒级 | 中 | 配置语法不够直观，操作失误可能断网 |
需要注意,临时限流的本质是“牺牲部分用户体验来保住整体业务可用性”，不是长久之计，建议在低峰期尽快排查根因。
业务带宽不够用？先做流量整形再谈扩容
排查完突发流量,如果业务本身就在持续增长，带宽确实不够用，就需要做流量整形，这一步的价值在于：让同样的带宽承载更多业务请求。
开启TCP压缩和HTTP压缩
Nginx开启gzip压缩是立竿见影的手段,压缩HTML、CSS、JS等文本资源，传输体积能下降约六到七成，对带宽释放效果显著，配置在nginx.conf里加上：
gzip on; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript; gzip_min_length 1024;
对于API接口返回的JSON数据,也可以看情况开启压缩，但要注意CPU占用会相应上升，带宽和CPU之间的取舍，要根据实际资源余量来判断。
给图片和视频做“瘦身”
图片和视频往往是带宽消耗的大头,一个电商首页如果没做图片压缩、没有懒加载，三四张高清图就能吃掉几十MB流量，临时缓解办法：
- 图片开启WebP格式,体积约为JPEG的70%左右
- 视频改用H.265编码或降低码率
- 启用CDN,让静态文件就近返回，不走源站带宽
CDN的费用不算高,但能极大降低源站带宽压力，据公开行业数据，CDN可以覆盖互联网业务绝大部分静态流量分发需求。
动态请求和静态请求走不同路线
将静态资源分配到对象存储加CDN,源站只处理动态API请求，这样源站带宽消耗就能大幅下降，域名上做区分，
static.example.com指向CDNapi.example.com指向源站
业务方直接改代码里的静态资源地址即可,不需要动服务器架构。
现实场景模拟：一次带宽被打满的“抢救”过程
用实际场景描述,比抽象说理更直观，假设某公司有两台服务器，一台跑官网商城，一台跑内部ERP，某天下午商城页面卡死，运维登录服务器截图发现，带宽已经连续10分钟跑满100Mbps。
实际操作过程如下：
- 执行
iftop查看实时连接，发现一个IP占据近一半下行带宽 - 检查该IP归属,是某地运营商出口IP，无法确定具体用户
- 临时在Nginx层将该IP的并发连接数限制为5
- 观察2分钟,带宽下降到约70Mbps，核心接口恢复响应
- 继续观察流量,发现另外几个IP同样在大量拉取商品图片
- 将静态图片全部切到CDN域名,后端带宽占用直接降了一截
整个抢救耗时不到半小时,没有加带宽、没有重启服务，遇到的问题基本解决。
什么时候必须升级带宽
临时办法能解决眼前问题,但有些情况确实得花钱扩带宽，业内专家指出，满足以下条件时，扩容比临时限流更合理：
- 带宽连续一周以上触碰上限,且核心业务流量占大多数
- 业务预期会持续增长,且增长幅度肉眼可见
- 限流开始影响关键接口的可用性,比如支付、下单流程
- 内部系统没有合理的限流和降级机制,给运维留出的操作空间不大
类似情况,直接联系云厂商提升带宽包月套餐，通常几分钟内生效，与其反复折腾临时方案，不如一次到位，多数云平台支持按带宽计费与按流量计费的切换，可以在控制台操作，当月的差价按天折算。
Q&A：带宽被打满临时解决办法的常见问题
带宽被打满临时解决办法中最推荐哪种？
最推荐先用iftop确认“谁在吃带宽”，再根据流量类型选择限流方式，对外Web服务优先生效Nginx层限制，内网流量用tc或调整调度任务，如果你不擅长命令行，直接去云控制台临时降低带宽并配合安全组封禁可疑IP，也是可行的。
带宽被打满但业务还不算太卡，需要立刻处理吗？
需要,带宽打满往往会在短时间内拖垮服务器连接数，最终导致CPU和内存异常升高，表现为整体应用雪崩，趁业务还能扛得住时，先做临时限速，比彻底卡死之后再去抢救要稳妥得多，即使最终要扩容，先把占用带宽最大的非核心业务挪到低谷期，也能让整体更稳定。
带宽被打满和服务器CPU被打满，怎么区分？
带宽打满时,监控图上网络入方向和出方向会拉满，但CPU占用可能并不高，用户端的延迟集中在“加载很久才有数据”，CPU打满时，带宽占用通常不高，但服务器整体响应慢，命令执行也有延迟，两者最直接的区别是：带宽打满一般能看到某个IP或进程占据大量流量，CPU打满则是进程列表里有高占用进程，网络流量却平稳。