业务高峰期遭遇DDoS攻击，最棘手的问题不是带宽被塞满，而是防御策略切换时误伤正常用户。很多团队在平时防御看似有效，一到促销、发布会或结算日就出问题，原因在于预案只考虑了“抗住攻击”，没有考虑“在攻击中保持业务可用性”。DDoS云防御的高峰期预案，核心要解决的是容量预估、策略分层、自动化响应和回源保护四个环节的衔接问题。
先做业务容量和攻击面盘点
高峰期到来前，必须明确正常业务的流量上限。这个上限不是拍脑袋定的，要结合历史同期数据、市场投放预算、活动力度综合计算。例如某电商平台日常峰值QPS为5万，大促期间预计峰值15万，那么云防御平台的清洗阈值就不能按日常的8万QPS设置，否则活动流量刚上来就被判定为攻击。正确的做法是提前与云防御服务商沟通，将业务IP、端口、协议、正常峰值带宽、预期QPS全部报备，并要求在防御策略中设置业务专属的流量模型。攻击面盘点同样重要，很多业务只盯着主站域名，却忽略了API子域、文件下载域、WebSocket长连接端口，攻击者往往从这些薄弱点打穿。
策略分层：把正常流量、灰度和攻击流量分开处理
高峰期DDoS防御最忌讳“一刀切”。云防御平台通常提供基础防护、应用层防护和自定义规则三层能力。基础防护负责SYN Flood、UDP Flood、ACK Flood等网络层攻击，这部分交给云厂商的清洗中心即可，但要注意清洗阈值不能设置过低。应用层防护针对HTTP Flood、CC攻击、慢速连接，这里必须启用智能防护模式，并配置人机识别。关键点在于：不要对全站启用强验证码，只对疑似攻击的URL路径启用JS挑战或滑块验证。例如登录接口、搜索接口、下单接口的CC攻击频率和正常用户行为差异明显，可以针对这些路径单独设置频率限制，而不是全站统一限制。灰度流量是指那些无法立即判定为攻击但行为可疑的请求，例如单个IP每秒请求20次但User-Agent正常，这类流量可以引导到独立的缓存节点或降级页面，而不是直接丢弃。
自动化响应必须提前配置，不能等攻击来了再手动调
高峰期攻击往往在几分钟内达到峰值，人工响应根本来不及。云防御平台一般支持阈值触发和事件触发两种自动化机制。阈值触发要设置多级告警，例如带宽超过正常峰值30%时自动启用增强清洗，超过50%时自动切换至严格模式，超过80%时启动备用线路或静态化页面。事件触发则基于攻击类型，例如检测到SYN Flood自动启用源认证，检测到CC攻击自动对目标URL启用频率控制。这些自动化规则需要在高峰期前反复演练，确认触发后不会把正常用户误拦。一个常见错误是：自动化规则只写了“触发后启用严格模式”，但严格模式的具体策略没有细化，导致触发后所有请求都要过JS挑战，移动端用户大量超时。自动化响应脚本中，建议加入白名单豁免逻辑，例如已登录用户的Cookie、特定App的SDK标识、合作伙伴的固定IP段，在严格模式下优先放行。
回源保护是高峰期最容易忽略的致命环节
很多人以为流量经过云防御平台清洗后就安全了，实际上攻击者会直接绕过云防护节点，对源站IP发起攻击。高峰期源站一旦暴露，所有云防御都形同虚设。预案中必须包含源站隐藏和回源链路加固。源站IP要使用独立的、不对外解析的地址，并且只允许云防御平台的回源IP段访问源站的80和443端口。如果业务使用CDN，还要确保CDN回源地址与云防御回源地址一致，避免出现多个回源入口。对于必须暴露源站的场景，例如邮件服务或FTP，需要在源站前端部署高防IP或本地硬件防火墙作为第二道防线。回源保护还包括回源带宽的冗余，高峰期正常回源流量可能比平时高3到5倍，如果源站出口带宽不足，即使攻击被清洗，正常用户的回源请求也会拥塞。建议在高峰期临时提升源站带宽，或者将静态资源全部缓存到云防御节点，减少回源请求量。
针对HTTPS和API业务的特殊处理
HTTPS业务在DDoS攻击中面临额外的计算资源消耗，攻击者发送大量TLS握手请求就能耗尽源站CPU。云防御平台应启用TLS卸载和会话复用，将握手压力转移到防御节点。同时，对于API业务，攻击者常用低速慢连接攻击，每个连接只发送少量数据但保持连接不释放。预案中要配置连接超时时间、最大并发连接数和单IP连接数限制。例如将API网关的空闲连接超时从60秒缩短到15秒，单IP最大并发连接限制在50个，超过即断开。对于使用HTTP/2的业务，要防范RST Flood和设置帧滥用，云防御平台需要支持HTTP/2的深度检测，不能只按TCP连接数统计。
高峰期防御预案的执行流程和分工
预案不能只写在文档里，必须明确谁在什么时间做什么事。高峰期开始前24小时，运维团队要确认云防御平台的策略已切换到高峰期模式，安全团队要检查所有域名解析是否指向防御节点，开发团队要准备静态化降级页面。攻击发生时，一线值班人员负责监控云防御平台的实时流量图和攻击类型，如果触发自动化响应则记录时间点和策略变更；二线安全工程师负责分析攻击特征，必要时手动调整规则；业务负责人负责判断是否需要启动降级方案，例如关闭非核心功能、限制部分地区的访问、启用排队系统。高峰期结束后，必须做复盘，对比防御前后的流量数据、误拦率、业务可用性，把有效策略固化到日常防护中。
几个容易踩坑的细节
第一，DNS TTL要提前调低。很多业务在切换云防御时，因为DNS缓存导致部分用户还在访问旧IP，攻击者也可能利用这个窗口直接攻击旧IP。高峰期前至少提前一周把TTL降到300秒以下，切换时才能快速生效。第二，云防御平台的日志要实时导出。攻击期间平台控制台可能卡顿，如果日志只存在平台上，事后分析会很被动。建议配置日志实时推送到自己的存储系统。第三，不要完全依赖云防御的默认策略。每个业务的流量模型不同，默认策略往往偏向保守，高峰期前必须根据业务特点做定制化调整。第四，准备备用云防御线路。单一云防御服务商可能出现区域性故障或清洗能力不足，有条件的业务可以同时接入两家云防御，通过DNS轮询或智能解析分流，但要注意两家平台的回源IP都要加白。
预案的验证和压力测试
高峰期预案不是写完就完事，必须通过模拟攻击验证有效性。可以联系云防御服务商提供测试攻击流量，或者使用内部的压力测试工具模拟HTTP Flood。测试重点不是能不能扛住，而是扛住之后业务表现如何。例如模拟CC攻击时，观察正常用户的登录、下单、支付流程是否顺畅，页面加载时间是否在可接受范围内。测试过程中记录误拦的请求特征，调整白名单和挑战策略。压力测试还要覆盖自动化响应的触发链路，确认告警能及时通知到人，策略切换能在30秒内完成。如果测试中发现云防御平台的清洗延迟超过2秒，就要考虑更换更高规格的防护套餐或增加缓存层。
高峰期DDoS防护预案的本质是“用确定性对抗不确定性”。攻击手法会变，攻击规模会变，但业务容量、防御策略分层、自动化响应机制和回源保护架构是可以提前确定的。把这四件事做扎实，即使遇到超出预期的攻击，也能在最短时间内恢复业务，而不是手忙脚乱地临时调策略。
