服务器频繁遭受攻击如何应对？从流量排查到多层防护的实战思路
服务器频繁掉线、网站访问变慢、CPU突然满载，不一定都是攻击，也可能是程序异常、数据库慢查询或正常业务突增。处理这类问题，关键不是立即封禁大量IP，而是先判断故障发生在哪一层，再选择止损措施。有效的防护体系，应当同时覆盖监测、入口清洗、访问控制、应用限流和故障恢复，避免一次流量冲击演变成长时间宕机。
一、先保业务，再确认攻击类型
发现异常后，先查看云监控、负载均衡和业务状态，记录异常开始时间、带宽、连接数、请求量及错误率。如果公网带宽已经接近上限，应优先联系云厂商或运营商启用清洗、调整高防接入；此时仅在服务器上添加防火墙规则，通常无法解决链路拥塞，因为恶意流量已经占用了入口带宽。
如果带宽正常，但CPU、内存或数据库连接数激增，应重点检查应用层请求。必要时临时关闭高消耗的非核心功能，例如复杂搜索、批量导出和公开统计接口，同时保留登录、支付等核心链路。调整前记录现有配置，准备回滚方案，避免应急操作造成二次故障。
二、用多项证据定位异常流量
排查时至少结合网络、系统、应用三个维度。网络层关注入站带宽、每秒数据包数、新建连接数和连接状态；系统层关注CPU软中断、内存、文件描述符及连接跟踪表使用情况；应用层关注访问路径、响应时间、状态码和后端调用量。只看某一个指标，很容易把正常访问高峰误判为攻击。
Linux环境可用ss -s查看连接概况，用ip -s link检查网卡统计，用top或pidstat观察资源消耗。连接大量停留在SYN-RECV状态，可能存在SYN洪泛，也可能与链路异常有关；请求集中访问昂贵接口、缓存命中率骤降，则更像应用层消耗。大量登录失败还需检查是否存在口令爆破，而不能统一按DDoS处理。
分析访问日志时，应统计来源、URL、请求频率、状态码和时间分布，并与历史基线比较。经过CDN或反向代理后，只能信任受控代理写入的真实客户端地址，不能直接采信任意请求中的X-Forwarded-For。必要时进行短时、限量抓包，避免抓包文件占满磁盘，并注意其中可能包含账号、令牌等敏感信息。
三、防火墙策略要少而准确
防火墙应坚持最小暴露原则：公网只开放业务必需端口，数据库、缓存和管理接口放入私网；SSH等运维入口通过VPN、堡垒机或固定来源访问。优先在云安全组或边界设备收紧入口，再用主机防火墙补充控制，避免所有压力都落到业务服务器。
修改规则前，应备份配置、保留当前管理会话，并确认有控制台等带外恢复通道。先验证管理来源放行、必要业务端口和已建立连接处理是否正确，再逐步收紧策略。不要在远程操作中直接清空规则，也不要照搬未经验证的参数，否则很可能先把自己锁在服务器之外。
对明确恶意来源，可采用带过期时间的临时封禁；来源较多时，使用nftables集合或ipset管理，通常比持续追加大量独立规则更便于维护。限速要结合正常业务基线设置，不能把所有用户一刀切。企业出口、校园网和移动网络可能共享公网IP，单IP阈值过低会误伤大量真实访问者。
四、应用层防护必须理解业务
针对HTTP攻击，可在CDN、WAF或网关实施分层限流：普通页面尽量缓存，搜索与导出接口限制并发，登录接口结合账号和来源控制尝试频率，短信接口增加发送间隔与额度。仅按IP限流难以应对分布式请求，也容易误伤，应结合会话、账号、路径和行为特征判断。
验证码、人机验证和挑战机制适合在风险升高时按需触发，不宜长期覆盖全部用户。对明显异常的请求，应尽量在进入数据库前快速拒绝，避免拦截动作本身触发复杂查询。Fail2ban适合依据可靠日志处理部分重复登录失败，但不能替代带宽清洗，也不适合承担大规模分布式攻击的主要防护任务。
五、建立真正的多层防护链路
常见架构是“高防或CDN—WAF—负载均衡—应用集群—私有数据服务”。各层分工不同：高防处理大流量冲击，CDN分散和缓存请求，WAF识别部分异常访问，应用负责权限与业务风控。接入后还要限制源站仅接受可信入口访问，并同步检查IPv4和IPv6规则，防止攻击者绕过防护直连源站。
应用集群应配合超时、熔断、连接池上限和队列长度限制，避免单个接口拖垮整个系统。自动扩容可以缓解压力，但必须设置容量及费用上限，防止攻击转化为高额账单。备份、跨故障域部署和恢复演练用于降低故障损失，不能替代入口防护。
六、用复盘让每次处置更有效
实际处置最容易忽略两件事：一是封禁后只看请求量下降，却没有确认正常用户是否恢复；二是开启过量日志，最终把磁盘写满。因此应同时观察成功请求率、延迟、错误率和资源余量，对高频重复日志进行采样或汇总，并设置磁盘告警与轮转。
事件结束后，整理攻击时间线、异常特征、有效措施、误封情况和恢复耗时，将其沉淀为值班手册。提前明确云厂商紧急联系方式、清洗能力、黑洞触发条件及解除流程。服务器安全不是一次性封IP，而是通过可观测、可回滚、可恢复的防护体系，把攻击影响限制在可控范围内。
