被流量攻击后别急着重启服务器，先登录服务器把Web访问日志、防火墙日志、系统认证日志、应用日志这四类日志按时间轴拉出来，交叉比对请求频率、来源IP、User-Agent和状态码，多数情况下能在10分钟内定位到异常请求的主要来源。
流量攻击和CC攻击日志区别在哪里
排查前先分清攻击类型,因为两种攻击在日志里的表现完全不同，用错方法会浪费时间。
- 流量攻击（DDoS/洪水攻击）：日志里通常看不到大量HTTP请求，反而会出现连接超时、日志中断、进程崩溃，攻击流量在到达Web服务器之前就把带宽或连接表占满了，Web访问日志可能只有少量记录或者完全没有新增。
- CC攻击（应用层攻击）：Web访问日志会突然出现大量正常但重复的请求，比如同一个URL、同一个参数、同一个User-Agent，请求频率远高于正常水平，状态码多为200或503。
- 混合型攻击：先打流量把带宽占满，再打CC消耗CPU，日志表现为前半段空白或断档，后半段出现密集请求，需要结合防火墙日志和云监控才能还原完整链路。
行业共识认为,先看日志是否断档，是区分流量型和应用型攻击的最快方式，如果Web日志在攻击时间段突然停更，优先查服务器带宽监控和机房提供的流量采样记录；如果日志还在增长且请求数暴涨，直接进入Web日志分析环节。
网站被攻击日志在哪里看：先翻这四个位置
很多运维一上来就翻网站根目录找日志,其实服务器上的攻击痕迹分散在多个位置，按下面的顺序找最高效。
Web服务器访问日志
这是排查CC攻击和扫描行为的第一现场。
- Nginx：默认路径通常为
/var/log/nginx/access.log，部分编译安装环境在/usr/local/nginx/logs/access.log。 - Apache：默认路径
/var/log/httpd/access_log或/var/log/apache2/access.log。 - IIS：通过“Internet Information Services管理器”查看站点日志，路径一般为
C:inetpublogsLogFilesW3SVC站点ID。 - 面板环境：宝塔面板在“网站-设置-日志”里直接看，Kangle和WDCP也有对应日志入口。
系统安全日志与防火墙日志
流量攻击在到达应用层之前,网络层和系统层会先留下痕迹。
- Linux：用
journalctl -u firewalld -n 200查看firewalld日志，用dmesg | grep -i drop
查看内核丢包记录，用
cat /var/log/messages | grep -i syn查看SYN洪水相关记录。 - Windows：在“事件查看器-Windows日志-安全”里筛选事件ID 5152和5157，能看到被防火墙拦截的连接。
- 云服务器安全组：登录云控制台查看安全组日志或流量监控，多数云厂商会记录被安全组丢弃的入站包数量。
应用层日志
如果网站有登录、评论、支付等动态功能，应用日志往往能暴露出攻击者的具体动作。
- PHP应用：查看框架日志如Laravel的
storage/logs/laravel.log，或ThinkPHP的runtime/log目录。 - 数据库日志：用
mysqladmin status查看连接数，慢查询日志里可能出现大量相同SQL。 - 网站后台审计日志：如果后台有登录审计功能，查找异常登录IP和连续爆破记录。
云平台流量监控日志
机房和云厂商提供的流量图是排查流量攻击的补充证据,登录云控制台，查看攻击时间段的入站带宽和PPS（包转发率），如果带宽被拉满但Web日志稀疏，基本可以判断为流量型攻击。
被流量攻击后怎么查日志：nginx日志分析攻击来源实例
拿到Web访问日志后,用几条命令就能把异常IP筛出来，下面以Nginx默认日志格式为例。
统计请求数最高的IP
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
请求数排名靠前的IP如果远高于正常水平,且集中在同一时间段，就是重点嫌疑对象。
按时间窗口提取日志
grep "2026-01-15T14:3" /var/log/nginx/access.log > attack.log
把攻击发生那几分钟的日志单独切出来,避免被正常流量干扰。
统计请求最集中的URL
awk '{print $7}' attack.log | sort | uniq -c | sort -rn | head -20
如果某个URL被反复请求数千次,而正常访问中它的比例很低，说明攻击者瞄准了这个接口。
统计User-Agent分布
awk -F'"' '{print $6}' attack.log | sort | uniq -c | sort -rn | head -20
攻击工具通常会使用固定UA,比如python-requests、Go-http-client或者空UA，正常用户UA则五花八门。
统计状态码比例
awk '{print $9}' attack.log | sort | uniq -c | sort -rn
如果503和502大量出现,说明后端被请求压垮；如果200占绝大多数，可能是CC攻击在打慢接口。
服务器被流量攻击排查步骤：按时间线还原攻击路径
光看零散日志容易误判,建议按时间线从网络层往应用层逐层排查。
- 第一步：确认攻击时间段，从监控告警、用户反馈、日志断档点三个来源确定攻击开始时间，缩小排查范围到5到15分钟以内。
- 第二步：检查防火墙和系统层丢包，Linux执行
netstat -s | grep -i syncookie查看SYN Cookie触发次数，Windows查看安全日志中5152事件数量，如果系统层出现大量半开连接或丢弃记录，说明攻击到达了传输层。 - 第三步：分析Web日志请求特征，用上面提到的命令提取高危IP、高频URL、异常UA，把攻击来源IP整理到一个列表里。
- 第四步：交叉比对云监控和机房流量数据，把云平台提供的入站流量曲线和Web日志时间轴对齐，确认攻击从哪个地区、哪个时间段开始爆发。
- 第五步：封禁异常来源并调整防护策略，在防火墙或安全组里封禁确认的IP段，同时开启限速和WAF规则，注意封禁单IP对分布式攻击效果有限，需要配合特征过滤。
北京服务器被攻击排查：机房联动比单机查日志更快
国内不少网站部署在北京的机房或云节点,北京服务器被攻击排查有一个特殊点：机房的清洗设备通常能提供比服务器本地更完整的攻击样本。
- 北京地区的骨干网节点流量较大,攻击流量在进入服务器前往往会先触发机房的上游清洗，登录服务器后如果发现Web日志完全空白，先联系机房索要攻击时段的流量采样报告，比在服务器上盲目翻日志更有效。
- 如果使用北京地区的BGP高防线路,机房后台一般有“攻击日志”或“抓包下载”功能，可以直接看到攻击来源的省份和运营商分布。
- 地域因素还会影响延迟和封禁范围,比如攻击源大量来自同一省份的某个运营商，在服务器上封禁IP段的优先级要高于封禁单IP，否则封禁列表会迅速膨胀。
高防服务器租用价格和日志留存时长的关系
排查需要日志,但不少服务器默认的日志留存时间只有7到15天，被攻击后如果延迟排查，关键日志可能已经被轮转覆盖。
- 高防服务器租用价格通常比普通服务器高出一截,但多数高防套餐会附带更长的流量监控留存和攻击抓包服务，部分机房提供30天以上的流量采样记录。
- 如果预算有限,可以把Web日志通过
logrotate
- 业内专家指出,日志留存策略比盲目堆高防更重要，因为事后追查来源、提交网警报案都需要完整的攻击记录。
三种常见攻击场景的日志取证要点
根据实际遇到的情况,取证侧重点不同。
| 攻击场景 | 优先看的日志 | 关键特征 |
|---|---|---|
| 网站变卡但不完全打不开 | Web访问日志 | 某IP高频请求某动态接口，UA固定 |
| 服务器带宽跑满 | 云监控+防火墙日志 | 入站流量远大于出站，Web日志稀疏 |
| 后台被暴力破解 | 应用日志+系统认证日志 | 大量401/403状态码，登录失败记录密集 |
- 网站变卡：直接跑
awk统计请求数和URL分布，找到被打的接口后临时加验证码或限速。 - 带宽跑满：立即联系机房或云厂商查看上游清洗情况，同时在服务器上确认是否有进程异常外发数据。
- 后台破解：查看认证日志中失败次数最多的IP，用防火墙直接封锁，并检查是否有成功登录后进行横向操作的行为。
被流量攻击后从哪些日志入手排查异常请求来源常见问题
被流量攻击后从哪些日志入手排查异常请求来源，防火墙日志和Web日志哪个更优先？
防火墙日志优先,因为流量攻击在网络层就被丢弃时，Web日志可能完全没有记录，而防火墙日志能看到SYN包数量、丢弃连接数和来源IP，确认攻击类型后，再决定是否深挖Web日志。
网站被攻击日志在哪里看如果已经过了几天，日志被覆盖了怎么办？
先查看服务器上的日志轮转目录,比如/var/log/nginx/access.log.1或access.log-20260115.gz，轮转后的历史文件可能还在，如果本地确实没有了，联系云厂商或机房调取流量监控历史数据，多数云平台控制台提供至少30天的带宽采样曲线。
被流量攻击后从哪些日志入手排查异常请求来源能直接封IP吗？
可以封禁确认的单个攻击IP,但对于分布式攻击，只封单IP几乎没有作用，更有效的方式是根据日志中的共同特征，比如相同的User-Agent、相同的URL参数、相同的请求频率，在WAF或Nginx层配置特征拦截规则，封禁IP段时要谨慎，避免误伤同段正常用户。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/654375.html
