业务高峰期网站DDoS攻击防护注意事项

业务高峰期遭遇DDoS攻击，最棘手的问题不是带宽被塞满，而是安全策略与业务可用性之间的冲突。平时有效的防护规则在流量暴涨时可能误伤正常用户，而攻击者恰恰会利用业务高峰期的流量特征做掩护，让攻击流量与正常流量高度相似。因此高峰期防护的核心不是“封堵”，而是“精准识别+弹性调度+降级预案”。

先说一个常被忽视的事实：业务高峰期你的正常流量基数本身就大，攻击者不需要打出平时那种倍率的流量就能造成拥塞。比如平时日均QPS是5万，攻击者打到15万就能让服务过载；但在高峰期你的正常QPS可能已经到12万，攻击者只需要额外注入3到5万恶意请求，就能把系统推过临界点。这意味着高峰期防护不能只看绝对流量阈值，必须建立基于基线动态调整的检测模型。

高峰期前一周，必须完成全量资产盘点。重点排查那些平时没人关注但突然在高峰期被调用的接口、活动页、回调地址、第三方API对接点。攻击者最喜欢挑这些“冷门但存在”的入口下手，因为它们的防护策略往往不完整。具体做法：拉取过去30天的访问日志，按URI聚合，找出请求量排名在尾部但高峰期会被业务逻辑触达的路径，逐一确认是否接入WAF、是否有限速策略、是否有独立的源站资源池。

同时关闭所有非必要的端口和服务。管理后台、数据库管理界面、文件传输端口如果必须开放，全部改为白名单IP访问，并启用二次认证。高峰期不是做架构调整的时候，任何临时暴露的测试接口、预发布环境入口都要在封网前关闭。

静态阈值在高峰期基本失效。你需要提前采集至少四个业务周期（如同等规模活动日）的流量数据，建立多维度的动态基线。这些维度包括：每秒请求数、每秒新建连接数、每个源IP的平均请求间隔、每个会话的请求序列特征、URI访问分布、地理来源分布、设备指纹类型分布、以及关键业务转化率。

基线的核心价值在于区分“流量上涨”和“攻击发生”。正常业务高峰期的流量上涨是有规律的：转化率稳定、会话深度稳定、地理分布与营销投放区域一致、设备类型分布符合用户画像。而DDoS攻击流量即使模拟得再好，也会在某个维度上偏离基线。例如攻击流量可能来自正常业务很少出现的自治域，或者请求间隔呈现机器特征，或者集中在少数几个URI上反复请求。

实操建议：把动态基线做成可配置的阈值带，而不是单点数值。当某个维度的实时值偏离基线带超过预设百分比（如30%）时触发告警，超过50%时自动执行预定义的防护动作。这个阈值带需要根据业务高峰期的实际波动幅度提前调宽，避免误报。

高峰期防护不能只依赖单一节点。比较稳妥的做法是三层弹性架构：边缘层做粗粒度过滤，应用层做细粒度识别，源站层做最终兜底。

边缘层主要处理网络层和传输层攻击，比如SYN Flood、UDP Flood、ACK Flood。这层的关键是保证有足够的清洗容量。如果你的业务部署在单一机房，高峰期前必须确认上游运营商能提供的最大清洗能力，以及清洗设备在满载时的时延表现。很多攻击事故不是清洗不了，而是清洗引入的时延把业务拖垮了。有条件的话，高峰期应启用多个边缘节点做流量分摊，每个节点只承担部分流量，单个节点被攻击时其他节点可以继续服务。

应用层防护的重点是HTTP Flood、慢速攻击、API滥用。这层需要配合动态基线做行为分析。具体策略包括：对每个源IP建立信誉评分，评分维度包含历史访问频率、请求合法性、会话完整性、是否触发过风控规则；对高信誉IP放行，对低信誉IP执行JS挑战或验证码，对明确恶意的IP直接封禁。注意高峰期不要对所有用户无差别启用验证码，否则正常用户的转化率会断崖式下跌。

源站层要做的是资源隔离和过载保护。把核心交易链路与内容展示链路拆开，即使内容服务被打垮，核心交易仍能继续。同时配置严格的连接数限制和请求超时控制，防止慢速攻击占满源站连接池。源站的防火墙规则要精简，高峰期每多一条复杂规则，转发性能就下降一截。

高峰期发生DDoS攻击时，最怕的是运维团队临场慌乱，做出扩大故障面的决策。因此必须提前写好降级预案，明确什么条件下触发什么动作，谁来执行，执行后如何恢复。

降级预案至少包含三级：一级降级是关闭非核心功能，比如推荐位、排行榜、动态评论、实时统计，保留核心交易和登录功能；二级降级是启用静态化页面，把动态内容替换为预生成的静态快照，减少后端计算压力；三级降级是切换到只读模式，暂停写操作，保证用户能浏览但不能下单或提交表单。

每一级降级都要明确触发指标，比如“源站CPU持续5分钟超过85%且边缘清洗流量超过基线2倍”触发一级降级。同时要指定恢复条件，防止降级后无法自动回切。降级操作最好做成脚本化或一键执行，避免高峰期手工操作出错。

熔断机制同样重要。对于依赖的第三方服务（支付、短信、地图、物流查询），高峰期前要确认对方的限流阈值和降级接口。当第三方服务不可用时，本地要有超时快速失败和默认值兜底，不能让一个外部依赖把整个请求链路拖死。

现在的DDoS攻击越来越多地直接打API接口，尤其是那些不需要登录就能调用的公开API。攻击者会抓取App或小程序的接口定义，构造合法的请求格式，然后用代理池发起海量请求。这类攻击在流量特征上非常接近正常用户，传统WAF规则很难识别。

针对API的防护要做几件事：第一，所有公开API必须启用签名校验，请求头中携带时间戳和签名，服务端校验时间窗口和签名合法性，防止请求被重放；第二，对每个API端点单独设置限速，限速值根据该端点的正常业务峰值设定，而不是全局统一；第三，对返回错误码比例异常的源IP进行自动封禁，比如某个IP在短时间内大量触发404或参数错误，直接加入黑名单；第四，对敏感接口启用设备指纹和风险评分，识别模拟器、代理IP、数据中心IP。

移动端防护还要注意证书校验和请求完整性。攻击者可能绕过App直接调用API，因此服务端不能只依赖客户端的安全措施。所有关键请求必须由服务端验证签名，签名密钥不要硬编码在客户端，而是通过安全下发机制定期更新。

监控是高峰期防护的眼睛。你需要提前配置好专门的监控大屏，展示核心指标：边缘清洗流量、源站入流量、源站CPU和内存、数据库连接数、关键API的QPS和错误率、当前封禁IP数量、降级状态。这些指标要能实时刷新，并且设置分级告警。

应急响应流程要明确到人。高峰期安排专人值守，每个人负责什么系统、什么情况下可以执行什么操作，都要提前书面确认。攻击发生时，第一优先级是保住核心业务可用，第二优先级是记录攻击证据，第三优先级是分析攻击特征并调整策略。不要在攻击进行中做大规模的策略变更，除非已经确认变更不会影响正常用户。

攻击结束后要做复盘，重点分析三个问题：攻击流量与正常流量的差异在哪里，现有防护策略为什么没有完全拦住，下次高峰期需要调整哪些参数。复盘的结论要更新到动态基线和防护规则中，形成闭环。

DDoS攻击不一定直接打你的服务器，打DNS解析服务同样能让业务不可用。高峰期前要确认DNS服务商提供的防护能力，启用多DNS供应商冗余，缩短TTL以便在切换时快速生效。同时检查DNS解析记录是否暴露了源站真实IP，如果暴露了，攻击者可以绕过CDN直接打源站。高峰期前最好更换源站IP，并确保新IP不会通过邮件头、历史DNS记录、证书透明度日志等渠道泄露。

证书层的问题也值得注意。高峰期如果证书即将到期，攻击者可能利用证书更新窗口发起中间人攻击或服务中断。提前检查所有域名的证书有效期，确保在高峰期结束前不会过期。同时确认CDN节点上的证书配置正确，避免因为证书链不完整导致部分用户访问失败。

业务高峰期的DDoS防护是一个系统工程，考验的是事前的准备深度和事中的响应速度。把动态基线建好，把降级预案写细，把API防护做实，把监控告警调准，你就能在攻击来临时保持业务的基本可用。最忌讳的是高峰期临时抱佛脚，指望靠加带宽或买高防IP解决所有问题——那些只是基础，真正决定成败的是你对自身业务流量特征的掌握程度，以及面对攻击时能否做出精准的、有节奏的应对。