装上预警先锋漏洞扫描后，日志先炸了

扫描器一装上去，日志先炸。装预警先锋漏洞扫描的人十有八九都撞过这个场面：本来站点跑得好好的，装完第二天面板磁盘报警，告警群刷屏，nginx 的 access.log 一夜之间胖了一大圈。你第一反应是扫描器出毛病了，其实它只是太实在——它干的活就是不停敲你站点每一扇门，敲一次记一笔，门多了账自然就厚。

预警先锋漏洞扫描为什么这么吵

主动扫描和坐在那儿等流量完全两码事。它会把站点里能点的链接、能提交的表单、能带参数的 URL 全撸一遍，再叠上规则库里那些探测用的 payload，一个页面能被它敲出几十条记录。再加上扫描器自己的运行日志、每次同步规则库的请求记录、还有一堆连接超时和被拒的连接，量级就上去了。这不是故障，这就是它的工作方式，你嫌吵得先明白它在吵什么。

先救火：磁盘满了什么都跟着倒

日志炸了最直接的下场不是难看，是磁盘写满。写到 100% 之后 MySQL 起不来、session 写不进去、面板打不开，一堆看着毫不相干的毛病同时冒出来，人在这种时候最容易乱。所以别急着研究规则，先 df -h 看一眼 /var 和 / 的使用率，把大的那几个文件揪出来。腾地方可以 truncate，或者 gzip 压一下，千万别手一抖 rm 掉正在写的文件——句柄还开着，空间不会马上还给你，得重启对应服务才放得出来。

日志级别不调，等于让它一直喊

扫描器默认的日志级别通常是给排障用的，debug 或者 info 满天飞，正常跑起来根本用不着。改成 warn 甚至 error，输出量能掉一大截，剩下的还都是值得看的。web 服务那头也一样，静态资源、健康检查、favicon.ico 这些请求记它干嘛，直接不写。nginx 里用 map 或者单独 location 把那几类请求的 access_log 关掉，改完 nginx -t 测一下再 reload，别图快把自己关在门外。

logrotate 这行配置，多数人装完就忘了

系统自带的 logrotate 是个好东西，问题是新装的扫描器没人给它写规则。默认那套按周轮转对它来说太奢侈，日切都嫌慢。在 /etc/logrotate.d/ 下面单独建一个文件，daily、rotate 留 7 份、compress、copytruncate 或者 postrotate 发信号让进程重开文件，这几项写清楚。别指望默认的 delaycompress 帮你省空间，压不压得动看你有没有开 gzip。配完拿 logrotate -d 空跑一次，看它认不认你这份配置，比出事了再猜强。

扫描器自己的 IP，得单独拎出来

有个坑特别常见：扫描流量和正常访问日志混在一个文件里，出了事想查真实用户行为，全被扫描记录淹了。给扫描器的出口 IP 单独开一个 access_log，或者在日志里打个标记，后面过滤、统计、排查都省事。防火墙那侧同理，把扫描器 IP 加进白名单，别让 WAF 把它当攻击者拦下来——拦了扫描结果就不准，你会以为站点干净得很，这种自我安慰最要命。

误报比漏报更耗人

日志里一堆高危告警，点开一看是误报，这种消耗最磨人，磨几次人就不看告警了。判断方法很土：拿扫描器给的那条请求自己手动发一遍，看服务端到底返回什么。能复现、返回内容确实异常，那才值得动手；复现不了、返回的是 404 或者登录页，多半是规则匹配太宽。别看见报错就改代码，改到最后把正常业务改坏，那才是真麻烦。规则库的更新节奏和匹配强度以服务商或官方页面说明为准，别自己乱调。

告警别全塞进一个群

扫描器接告警的时候顺手分个级：能直接利用的、需要人工确认的、纯提示的三类分开走。全塞一个群，第一天热闹，第三天全员静音，第四天真出事没人抬头。邮件、短信、IM 各有各的脾气，重要的走能吵醒人的渠道，提示类的写进日报就行。这事不费什么技术，纯靠一开始想清楚。

别指望装完就一劳永逸

扫描跟体检一样，是一次一次做的，不是装个软件就自动免疫。装上之后至少养三件事：日志别让它无限长、告警要有人看但得分级、扫描频率跟业务错峰。半夜跑比白天跑省心，白天扫一次，客服电话能被打爆——说法夸张了点，道理在那儿。另外系统日志也顺手管一下，journald 的 SystemMaxUse 设个上限，别让扫描器把整个 /var/log 都带跑偏。

真落地就三句话：先看磁盘，再压日志，最后才去翻漏洞报告。顺序反了，你就会在磁盘满、服务挂的状态下研究一条压根不成立的告警，越查越远。装扫描器是为了少踩坑，别让它自己变成新坑。