凌晨两点，网站手机突然连震十几下。被攻不开我眯着眼摸过来一看，击打监控群炸了——网站打不开，网站502 Bad Gateway。被攻不开运维老张发了张截图，击打流量曲线像被人从悬崖边推下去，网站垂直坠落。被攻不开

这不是击打第一次了。但这次不一样。网站

我爬起来开电脑，被攻不开先试了试直接访问IP。击打能通。网站域名解析也正常。被攻不开问题出在应用层。击打Nginx日志里全是超时记录，PHP-FPM进程池满了，每个进程都卡在数据库查询上。再看MySQL，CPU 100%，慢查询日志里堆了几百条一模一样的SELECT语句——全是同一个IP段发来的。

典型的CC攻击。攻击者用大量看似合法的请求，把数据库连接占满，正常用户根本挤不进来。老张在群里说：“封IP？”我说先别急，看看请求特征。

翻了几页日志，发现所有恶意请求都带着同一个User-Agent，访问路径全是搜索接口，参数里塞了超长字符串。攻击者没用什么高级工具，就是写了个脚本，循环发请求。成本极低，效果拔群。

网站被攻击打不开，最直接的原因往往不是服务器扛不住流量，而是某个薄弱环节被精准打穿。就像这次，带宽没跑满，CPU也没被DDoS打死，但数据库连接池只有那么几十个，攻击者用慢查询把它们一个个占住，正常请求就只能排队。排到超时，页面自然打不开。

我让老张先在WAF上加规则，拦截那个User-Agent。五分钟后又不行了——攻击者换了UA，继续打。再封IP段，对方用代理池，封一批换一批。这时候才意识到，对方不是随便打打，是在盯着我们的防御动作调整策略。

临时方案是上验证码。搜索接口加一层人机校验，正常用户多点一下，攻击脚本直接废掉。效果立竿见影，数据库连接数从爆满掉到个位数。但这不是长久之计，验证码影响体验，而且对方如果上打码平台，照样能破。

真正解决问题是在第二天下午。我们翻了更早的日志，发现攻击前三天就有大量探测请求，像是在扫描接口结构。攻击者摸清了搜索接口没有频率限制，才决定从这里下手。于是我们给所有API加了令牌桶限流，单IP每秒最多五个请求，超出直接拒绝。同时把数据库连接池从50调到200，加了Redis缓存热点查询。

网站恢复那天，老张在群里发了句话：“攻击成本太低，防御成本太高。”我盯着屏幕想了很久。一个脚本小子用一台笔记本就能让一个中型网站瘫痪几小时，而我们要动用一个团队、折腾一整天才能补上漏洞。这种不对称，才是网站被攻击打不开背后真正让人头疼的事。

后来我养成了个习惯：每天上班第一件事，不是看流量涨了多少，而是翻一遍错误日志。攻击不会提前打招呼，但日志里总有痕迹。那些异常的请求频率、奇怪的参数组合、突然增多的404，都是信号。网站能不能打开，有时候不取决于你防得多好，而取决于你发现得多早。

现在那个搜索接口还在跑，限流规则也还在。偶尔会有用户抱怨“怎么点一下没反应”，老张就回一句：“稍等两秒再试。”没人知道那两秒背后，我们挡掉了多少恶意请求。网站安安静静地开着，像什么都没发生过。