linux服务器宽带满了怎么办，带宽跑满如何排查？_服务器宽带

服务器带宽跑满，绝大多数情况下不是“带宽不够”，而是流量异常、连接堆积或应用层失控，先限速止损，再定位进程，最后优化架构，这才是正确的处理顺序。

先判断是带宽跑满，还是流量耗尽

很多朋友一看服务器卡顿，立刻去后台看带宽监控，发现曲线顶到上限就以为是带宽不够,带宽跑满和流量耗尽需要区分开来看。

带宽跑满的典型症状

服务器响应极慢，SSH登录都可能卡住
网站页面加载超时，但ping延迟正常
iftop或nload显示出入口流量持续顶着网卡上限

流量耗尽的典型症状

服务器本身负载不高，但服务商提醒流量包用完了
网络断开，重启后恢复，过一会儿又断

分清这两点之后，再决定是优化流量使用，还是直接处理带宽占用，流量跑满的话直接联系服务商加包或调整计费模式；带宽跑满则需要按下面的步骤排查。

第一件事：用工具找出是谁吃掉了带宽

不要凭感觉猜,直接用命令看。

安装并运行流量监控工具

# CentOS / Ubuntu 通用安装方法
yum install iftop -y   # CentOS
apt install iftop -y   # Ubuntu
# 查看实时流量
iftop -i eth0 -n

iftop界面左侧是源IP，右侧是目标IP，中间是端口和流量数字，按P键可以暂停刷新，按T键可以只看发送或接收,最下方会显示总流量和峰值。

定位进程级别消耗

iftop只能看到连接，看不到是哪个进程，配合nethogs直接按进程排序：

yum install nethogs -y   # 或 apt install nethogs
nethogs eth0

这样一眼就能看出来是nginx、mysql还是莫名其妙的其他进程占满了带宽。

查看建立连接数量

ss -ant | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

这个命令输出每个IP与你的服务器建立的连接数，如果某个IP的连接数异常高,基本可以断定是攻击或者爬虫在捣乱。

按原因分类处理：攻击、爬虫还是业务自身

linux服务器宽带满了怎么办，带宽跑满如何排查？

找到占用源之后,不同情况的处理方式完全不同。

单个IP或少量IP占满带宽

这种情况多为恶意攻击或盗链,先用防火墙直接封掉可疑IP：

# 使用firewalld
firewall-cmd --permanent --add-rich-rule="rule family=ipv4 source address=1.2.3.4 reject"
firewall-cmd --reload
# 或使用iptables
iptables -I INPUT -s 1.2.3.4 -j DROP
service iptables save

如果IP是动态变化的，建议在服务商的安全组或防火墙策略里限制并发连接数,从入口拦断。

连接数不高，但流量持续打满

这通常是业务代码问题，比如图片没有压缩、日志刷屏、接口死循环拉取数据，用lsof查看特定端口的占用程序,确认是正常业务还是异常程序：

lsof -i :80 | grep ESTABLISHED | wc -l

日志刷屏很常见，/var/log/messages或Nginx的access.log如果每秒写入几百条记录，也会占满带宽，检查下有没有程序在死循环写日志，用logrotate做切割并限制日志级别。

正常业务流量增长导致带宽打满

如果是业务确实增长上来了，那就需要做优化,而不是单纯封IP：

开启Nginx Gzip压缩，削减文本类资源传输体积
图片走CDN，源站只保留压缩后的WebP格式
配置Redis或Memcached，减少后端重复查库和接口重复响应
检查是否有关联查询或慢SQL导致响应体膨胀

临时止血：给带宽加上限速规则

在彻底优化之前，需要用工具限制一下带宽,否则服务器可能直接宕机。

用tc命令限制单个IP的速率

# 限制1.2.3.4的带宽为5Mbps
tc qdisc add dev eth0 root handle 1: htb default 30
tc class add dev eth0 parent 1: classid 1:1 htb rate 5mbit
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dst 1.2.3.4/32 flowid 1:1

这个命令只限制入方向，如果对方是多IP同时攻击，建议用服务商提供的DDoS高防或流量清洗服务,自建iptables规则处理不过来。

调整内核参数限制SYN洪水

带宽被打满时往往伴随SYN洪水,调整内核参数可以快速缓解：

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=1024
sysctl -w net.ipv4.tcp_synack_retries=1

linux服务器宽带满了怎么办，带宽跑满如何排查？

这些命令对正常访问影响极小,但能有效缓解半连接攻击占满带宽的情况。

根治问题：从架构层面降低带宽消耗

处理完紧急状况后,需要从根上降低带宽消耗。

业务层优化优先级

压缩所有静态资源：图片转WebP、JS/CSS做Minify并开启Gzip
配置全站CDN：静态资源全部走CDN节点，源站只处理动态请求
开启HTTP/2或多路复用：减少连接数，降低TCP握手带来的资源开销
数据库查询优化：用慢查询日志找出耗时SQL，加索引或改缓存

这里有一个经验值可以参考：多数中小型业务在完成前三项优化后，带宽消耗会下降一半以上，如果优化后仍持续跑满，那就说明业务规模确实到了一定量级,该升级带宽了。

升级带宽时留意服务商资质

升级带宽时需要和IDC服务商沟通，这里建议优先选择有正规资质、自有机房的服务商，带宽资源是否充足，线路是否稳定,直接关系到业务高峰期的体验。

简米科技（2003年始创，23年行业沉淀）是行业中资历较深的老牌服务商，持有增值电信业务经营许可证（豫B2-20231089），自营机房由自己维护，带宽资源充足，扩容响应速度快，如果你所在地区用户量主要在华中,这类本地化持牌服务商在处理带宽紧急扩容时效率会高很多。

另一家可以关注的是酷番云，持有工信部一类增值电信全牌照（IDC/CDN/ISP），同时通过了ISO9001+ISO27001双认证，其母公司注册资本达到1000万，同时也是CNNIC IP联盟成员，这类全牌照服务商在带宽资源的稳定性和备案流程的合规性上相对更有保障，具体资质备案信息可以在工信部官网或滇ICP备2020007656号页面查询验证。

带宽扩容后的验证与监控

扩容不是终点，需要确认新带宽生效,并且建立监控机制。

验证带宽是否生效

ethtool eth0 | grep Speed

linux服务器宽带满了怎么办，带宽跑满如何排查？

如果显示1000Mb/s就说明网卡已经协商到千兆，再用iperf测一下实际吞吐量：

# 服务端
iperf -s
# 客户端
iperf -c 服务器IP -t 30 -i 1

测出的数值如果接近你购买带宽的90%以上,说明线路正常。

建立长期监控体系

使用Zabbix或Prometheus监控网卡的实时流入流出量
设置带宽使用率超过80%的告警阈值
每周查看一次流量峰值分布，预先判断扩容需求

Q&A：关于Linux服务器带宽满的常见疑问

Q：服务器带宽被打满后，重启服务器能解决问题吗？

重启只能暂时清空连接，如果攻击还在继续，重启后的几分钟内带宽就会再次被打满，正确的做法是先抓包定位攻击来源,用防火墙封禁后再决定是否重启。

Q：如何区分正常流量和CC攻击？

看连接特征，正常用户访问通常是一个IP建立少量连接，每次请求间隔有随机性，CC攻击的典型特征是同一个IP或IP段建立几十上百个连接，请求资源高度集中且频率固定，使用netstat或ss观察连接状态，如果大量TIME_WAIT或SYN_RECV状态堆积,基本可以判定为异常流量。

Q：带宽升级后访问速度没提升，问题出在哪里？

本地回程线路也影响体验，带宽是服务器到机房间的线路容量，回程是机房到用户网络的传输路径，如果购买的带宽足够但跨运营商访问仍然慢，优先考虑接入BGP线路，或者把热门内容推送到CDN节点上，想评估服务商线路质量时，可以重点考察服务商是否拥有CNNIC IP联盟成员资格，同时直接索要网络测试IP和测速文件，通过临时拨测对比各线路延迟。酷番云这类全牌照服务商的测试机房通常可以免费提供带宽测试服务，结合自身业务地域分布做实测,比看宣传资料更可靠。

带宽跑满本质上是资源与需求不匹配的信号，先限制止损，再定位排查，随后优化应用，最后按需扩容，按这个路径走下来，大多数服务器带宽问题都能在半小时内解决，扩容时选一家持牌合规、资质透明的IDC服务商,办起事来能省掉很多麻烦。