摘要：# 突然收到流量告警短信，别慌！第一件事千万别是“重启服务器” “叮——” 凌晨两点，手机屏幕在床头柜上突然亮起，一条短信弹出来：“【监控告警】您的服务器入站流量异常，已超过阈值 300%。” 你一个激灵从床上坐起来，脑子里瞬间闪过无数念头：被打了？…

突然收到流量告警短信，别慌！第一件事千万别是“重启服务器”

“叮——”

凌晨两点，手机屏幕在床头柜上突然亮起，一条短信弹出来：“【监控告警】您的服务器入站流量异常，已超过阈值 300%。”

你一个激灵从床上坐起来，脑子里瞬间闪过无数念头：被打了？业务要挂了？老板明天会不会杀了我？

先深呼吸。 对，这就是你要做的第一件事——稳住，别慌。我见过太多人，一看到告警，第一反应就是冲进后台一顿操作：重启服务器、关端口、甚至拔网线。结果呢？往往是把小问题搞成了大事故，或者自己亲手阻断了正常的业务高峰。

说真的，这种心跳加速的感觉，干这行的应该都不陌生。但处理得当和手忙脚乱，结果天差地别。今天，咱们就抛开那些复杂的架构图，聊聊收到那条要命的短信后，最该按什么顺序来操作。记住，顺序错了，努力白费。

第一步：别碰任何开关！先判断“真假”

告警响了，不代表天塌了。第一要务是确认攻击是否真实存在，以及它到底有多严重。

1. 看一眼监控大盘（如果你们有的话） 别急着登录服务器。先打开你们的云监控、Zabbix、Prometheus Grafana面板，或者任何能看全局流量和业务状态的地方。重点看几个指标：

   • 流量图是“尖刺”还是“山洪”？ 一个瞬间的尖刺，可能是某个爬虫抽风或一次误报；而持续爬升、像山洪一样的曲线，那大概率是真中招了。
   • 业务指标还活着吗？ 看看错误率（5xx）、响应时间、在线用户数。如果流量暴涨但业务一切正常，用户没投诉，那有可能是CC攻击（瞄准某个消耗大的页面，比如搜索、登录）或者刷接口，还没打到要害。如果错误率飙升，用户开始掉线，那就是更直接的DDoS或者打到了薄弱环节。
   • 来源IP集中吗？ 瞄一眼流量来源地域或IP段。如果来自全球各地成百上千个IP，是DDoS的可能性大；如果集中在某个地区或几个IP，可能是针对性CC。

2. 快速自检：是不是自己人干的？ 这听起来很蠢，但真发生过。马上在团队群里吼一嗓子：“有没有人在跑压测/数据同步/发大促红包？” 我就吃过这亏，曾经凌晨被告警吓醒，结果发现是隔壁组的兄弟在做一个没通知的全量爬取…（此处省略吐槽五百字）

如果发现是误报或内部操作，松口气，回去睡觉。如果是真的，进入下一步。

第二步：启动“战时通讯”，别当孤胆英雄

确认是真攻击后，立刻、马上在相关协作群（运维、开发、安全、业务负责人）里同步信息。别自己闷头搞。

• 同步什么？ 用最简单的语言说清楚：“线上可能被攻击了，目前观测到流量异常暴涨XX倍，业务接口响应已变慢，我们正在排查，大家做好准备。”
• 为什么？
  1. 让业务方有预期： 客服、运营需要提前准备话术，应对可能的用户咨询。
  2. 集思广益： 开发可能立刻想到最近是不是上了有漏洞的新功能；安全同事可能有现成的IP黑名单。
  3. 避免背锅： 透明沟通是所有故障处理的第一原则。出了事大家一起扛，信息不透明，锅就是你一个人的。

第三步：根据“火力”，选择战术动作

现在，你知道了真假，也通知了队友。接下来才是动手的时候。但动手不是盲动，得分情况：

场景A：流量巨大，业务已受影响（典型的DDoS）

核心思路：保源站，引流量。

1. 立即启用高防IP/高防CDN的清洗服务。 如果你买了这类服务（现在没买的心可真大），第一时间在控制台将流量切换到高防线路。让海量的垃圾流量在高防的清洗中心被过滤，干净的流量再回源到你服务器。这是对抗大规模流量型攻击最有效、最快速的方法，没有之一。
2. 如果没买高防？ 抱歉，选项不多了。可以尝试联系云厂商（比如阿里云、腾讯云）的售后，他们可能有基础的免费清洗额度，但超过额度就……你懂的。或者，临时扩容带宽？对于DDoS来说，这基本是“用钱硬刚”，而且可能是个无底洞，不推荐。
3. 一个“土办法”但有时有效： 如果攻击流量主要是UDP或ICMP（比如DNS反射放大攻击），可以在云安全组或服务器防火墙上临时屏蔽这些协议。但这会影响相关服务，属于断臂求生。

场景B：流量不大，但连接数巨高，CPU/内存打满（典型的CC攻击）

核心思路：精准识别，掐死恶意会话。

1. 看Web服务器日志（Nginx/Apache）。 快速分析一下，是不是大量请求集中在少数几个URL上？比如 /login.php, /api/search。找到攻击目标。
2. 设置频率限制（Rate Limiting）。 在Nginx里，可以快速为可疑URL配置限流规则，比如一个IP每秒只能请求5次登录接口。这能立刻缓解服务器压力。
3. 启用WAF的CC防护规则。 如果你用了云WAF或自建WAF（如ModSecurity），立刻开启针对高频请求、慢速攻击的防护规则。
4. 人机验证（Captcha）大法。 对于像登录、注册、提交表单这类关键且容易被CC的页面，可以临时紧急加上简单的图形验证码。虽然影响一点用户体验，但能瞬间挡住90%的简易爬虫和CC工具。

第四步：稳住之后，开始“破案”

当紧急处置生效，业务指标开始回落，警报声暂时停歇后，别以为就结束了。攻击者很可能在观察你的反应，准备下一波。

这时候你需要：

1. 保存证据： 下载攻击时间段的完整访问日志、防火墙拦截日志、流量包（如果抓了的话）。
2. 分析攻击特征： 攻击持续了多久？峰值多少Gbps？主要用什么协议和端口？攻击源IP有没有共同特征（比如都来自某个AS号）？用的什么工具指纹？（从User-Agent里有时能看出来）。
3. 追溯原因（灵魂拷问）： 为什么被打？是竞争对手？是之前得罪了黑客？还是你的站点不小心被挂上了“暗链”或漏洞被公开了？检查一下近期有没有发生代码更新、新业务上线、或者在某些“灰色”论坛被提及。

最后说点大实话

• “临时抱佛脚”效果有限。 真遇到大规模攻击，靠临时反应是扛不住的。平时就得把高防、WAF这些基础设施配好，做几次切换演练。知道消防通道在哪，着火时才不会乱。
• 源站隐藏是王道。 永远别让真实服务器IP暴露在公网上。用高防IP、CDN、云机房的内网SLB来做转发，让攻击者找不到真正的“家”在哪。
• 告警阈值别太敏感。 设置得太低，天天“狼来了”，人会麻木；设置得太高，等告警时已经晚了。根据业务常态，找到一个平衡点。

收到告警短信，从惊慌到冷静，从盲目操作到有条不紊，这中间隔的就是一套清晰的应急预案和几次实战（或演练）的经验。

行了，希望你看完这篇，下次手机再亮起时，能淡定地喝口水，然后说：“知道了，按预案来。” 这才是一个老司机的修养。

（如果看完还是没底……那你可能真得去检查一下自己的防护措施是不是在“裸奔”了。）