服务器流量异常飙升，正确顺序是先确认方向再动手处理：先分清是带宽跑满还是连接数爆炸，再按进程、IP、日志三个维度逐层定位，最后用防火墙和限流手段处置，不要上来就重启或改配置。
服务器流量异常飙升怎么排查：先分清类型再动手
服务器流量异常飙升的场景多半发生在业务高峰期或凌晨无人值守阶段，登录后台看到带宽曲线跑成一根横线，又或者主机商发来流量超标警告，多数人第一反应是看是不是被攻击，这里有一个行业共识：相当一部分流量飙升其实来自业务自身问题，比如爬虫失控、日志循环写入、数据同步任务跑飞，先别急着下结论,按下面三个方向判断。
看带宽曲线是横向跑满还是脉冲式跳动
打开服务器监控面板或云厂商的流量监控图，注意两点，带宽占用持续保持在90%以上，曲线平滑横向延伸，大概率是持续型攻击或大文件传输，曲线忽高忽低，呈锯齿状跳动，多半是短连接请求或爬虫频繁抓取，同时观察入方向还是出方向带宽高，入方向高说明外部请求量大，出方向高可能是服务器在向外发数据,要重点排查是否被植入木马或挖矿程序。
检查连接数状态和来源IP分布
用终端登录服务器，执行netstat -ant | awk '{print $6}' | sort | uniq -c | sort -rn | head -10查看TCP连接状态分布，正常情况下SYN_RECV和ESTABLISHED占比应在一个合理范围，如果SYN_RECV数量异常庞大，基本可以判定是SYN Flood类攻击，再用netstat -ant | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20看来源IPTop20，如果某个或某几个IP的连接数远超其他来源,怀疑点就浮出水面了。
用top命令快速确认异常进程
执行top -c查看CPU和内存占用排行，重点看进程名是否为熟悉的业务进程，异常情况多表现为进程名伪装成系统服务，比如crond、sysudt、kworkerd等名称，如发现陌生进程，用ls -l /proc/[PID]/exe定位可执行文件路径,再决定是否清除。
网站被刷流量怎么排查：从系统命令到日志定位
确认异常方向后，接下来是逐层定位，这里说的“刷流量”不一定都是黑客行为，有几种常见场景：搜索引擎爬虫配置不当导致抓取频率失控，
采集程序或竞争对手恶意请求,还有CDN回源配置错误导致流量循环。
第一步：定位访问日志的爆发时间点
Nginx和Apache的访问日志是关键现场，Nginx默认路径/var/log/nginx/access.log，Apache通常为/var/log/httpd/access_log，用tail -n 1000 /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f2 | sort | uniq -c | sort -rn统计最近1000条请求的小时分布，找出哪个时间段流量最密集，再看请求的URL路径，如果大量请求同一个静态资源或某个接口，说明针对性刷量，如果请求路径随机字符且404比例偏高,多半是扫描器遍历。
第二步：区分正常爬虫和恶意采集
正常爬虫的User-Agent有明确标识，比如Baiduspider、Googlebot，执行awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20看请求来源IP排行，再比对这些IP的反查记录，如果来源IP集中在某个C段且UA伪装成浏览器，可以采集、攻击双重怀疑，行业内有几种处理手段，在Nginx层直接return 403，通过robots.txt限制路径爬取，或者用rate limit模块对单IP做并发限制。
第三步：排查业务层面的异常调用
如果你的服务器有业务应用在跑，流量飙升还有可能是某个API接口被循环调用，查看应用日志如tail -f /var/log/app/error.log，配合数据库慢查询日志，确认是否有异常的重复查询，出现过线上事故，某个定时任务因配置失误变成秒级循环，导致DB连接池耗尽，带宽和内存同时暴涨,这类情况仅靠网络层排查是找不到根源的。
处置手段：封锁、限流、高防切换
确认攻击或异常来源之后，处置手段要快，但顺序有讲究，核心原则是先隔离再清除，宁可误杀不可放行。
用防火墙临时封禁可疑IP
单IP攻击直接封禁,操作路径如下：
# iptables封禁 iptables -I INPUT -s [攻击IP] -j DROP # firewalld封禁 firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=[攻击IP] drop' firewall-cmd --reload
如果攻击IP分布在一个C段例如192.168.1.0/24，直接封整个子网，统计显示较大比例的恶意流量集中在少数几个C段,封C段比逐个封IP效率高得多。
限流和压缩并发连接
不方便直接封禁的场景，比如CDN回源IP或合作方接口，使用Nginx的limit_req模块做请求速率限制，在nginx.conf的server段加入：
limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;
location / {
limit_req zone=one burst=10 nodelay;
}
这能控制单IP每秒请求数，有效缓解应用层CC攻击，同时调整系统内核参数，sysctl -w net.ipv4.tcp_syncookies=1开启SYN Cookie，sysctl -w net.ipv4.tcp_max_syn_backlog=2048增加半连接队列长度。
有高防或CDN就先切流量
如果你的业务本来接了CDN或高防IP，流量异常时第一步就考虑切换，而不是在源站上硬扛，登录CDN控制台开启“安全加速”或“攻击防护”模式，大部分流量会被边缘节点清洗，回源压力大幅降低，据公开资料，主流云厂商的安全防护产品能承受的DDoS防御峰值都在TB级别以上，对中小规模的攻击流量基本可以做到秒级拦截，如果没有CDN怎么办？临时把DNS解析切到云厂商的DDoS高防IP上，这个过程通常需要几分钟生效，但注意高防IP的按量计费价格不低,攻击结束后及时切回。
处置后的验证与观察
封禁和限流操作后，不要马上离开终端，观察10到15分钟，看带宽曲线是否回落，连接数是否恢复正常水平，若流量还在涨，说明封禁对象判断有误，需要回到日志分析环节重新定位异常源，取证留存也很重要，把攻击期间的访问日志、系统日志、连接状态快照复制到备份目录，后续若涉及报案或投诉,这些都是依据。
事后加固与监控告警配置
流量异常处置完并不等于收工，排查这个坑往往暴露出监控和应急层面的一些薄弱点,补上才能防患于未然。
设置多层阈值告警机制
在云监控平台或zabbix等自建监控系统里，配置好带宽告警，入方向带宽超过峰值的70%触发告警，出方向带宽超过一定阈值立即通知，同时设置连接数告警，比如TCP连接数超过业务正常值两倍时触发，告警渠道至少包含短信和电话,确保大半夜流量被打满时能及时收到消息。
定期做日志轮转和归档
日志文件过大不仅挤占磁盘，还会拖慢排查速度，配置logrotate让系统日志和Nginx日志按天或按大小轮转，保留历史日志至少30天，踩过坑的人都知道，流量异常发生后的日志是判断攻击来源的第一手证据，如果因为日志轮转配置不当导致关键时段日志缺失,事后复盘就无据可查。
梳理架构层面的弹性能力
如果你的业务有周期性流量高峰，比如电商大促或游戏开服，建议提前跟云厂商沟通扩容方案和DDoS防护套餐配置，做到“平时够用，战时能扩”，云服务器和物理机在异常流量场景下的表现差异明显，物理机带宽跑了满是硬吞流量，云服务器可以配合安全组和云防火墙快速下发规则，做架构选型时，优先考虑带弹性带宽和安全能力的云方案，而不是只看价格。
服务器流量异常飙升的排查，核心无非是：看现象、判类型、查日志、封异常、做加固，整个过程不需要什么高深技巧，按本文的顺序执行，多数情况能定位到根因，关键是不要慌乱间重启服务或删除日志，保留现场比快速恢复更有价值，因为你不知道攻击是不是还会再来，运维路上被流量打满过几次,才会真正理解监控和预案的分量。
服务器流量异常飙升后，业务还能继续对外提供服务吗？
如果攻击流量持续打满带宽，业务实际上已经不可用了，就算服务器CPU和内存还算正常，用户侧的请求也无法到达服务器，建议在确认攻击后的第一时间切换高防或CDN入口,宁可短暂断服也不要硬扛到整个机房IP被封。
重启服务器能解决流量异常飙升的问题吗？
多数情况下重启解决不了本质问题，流量攻击的源不在服务器内部，重启最多清掉内存中的异常进程或临时连接，攻击流量依然会打到你当前的IP上,而且重启后系统日志有可能会覆盖关键排障证据。
怎么查看服务器带宽被什么占满？
先用iftop看实时流量画面，配合nethogs按进程维度查看占带宽的PID，两者结合基本上能在几分钟内锁定是外部攻击还是内部程序跑飞，若这两种工具都未装，可以用ss -s查看socket统计信息，再用lsof -i :80查占用80端口的进程详情。