业务上线前部署DDoS攻击防御体系，最容易被忽略的一点是：防御不是买一台设备或开一个云防护就结束了，而是要把“攻击面收敛、流量基线、响应动作、业务降级”四件事在代码冻结前全部做完。很多团队等到业务被压垮才去接高防IP，结果发现源站IP早已暴露、API接口没有限速、数据库连接池被异常请求占满，临时接入的防护只能挡住网络层洪水，挡不住应用层慢速攻击。上线前部署的核心价值，是让你有窗口期做源站隐藏、协议加固和全链路压测，而不是在攻击发生时手忙脚乱地切DNS。
先梳理业务暴露面，把不需要公开的入口全部收掉
DDoS攻击能成立的前提是攻击者找得到目标。上线前第一件事是盘点所有对公网开放的端口、域名、IP和API端点。很多业务在开发阶段为了方便调试，会把测试环境、数据库管理后台、文件传输服务、SSH端口直接暴露在公网，甚至使用默认端口和弱口令。这些入口一旦被打或被打穿，业务主站还没受影响，运维通道先断了，或者数据先被拖走。
具体做法是：对每个对外域名做子域枚举和端口扫描，确认只保留业务必需的443和80端口；管理后台、监控面板、API文档、代码仓库、CI/CD系统全部收敛到内网或通过零信任网关访问；源站IP只允许CDN或高防回源节点访问，其他来源一律拒绝。如果业务必须提供文件上传下载，单独拆分子域名，使用独立存储和带宽池，避免攻击文件接口时把主站带宽耗尽。
源站隐藏是上线前最容易做、事后最难补救的动作。一旦源站IP在攻击前被记录，攻击者可以绕过所有云防护直接打源站。上线前要确保DNS历史记录、邮件头、证书透明日志、第三方监测平台里都查不到真实IP。新业务建议直接使用高防IP或CDN作为唯一公网入口，源站只监听内网地址，回源流量通过专线或加密隧道。
网络层防御要提前配置，但不要指望它单独解决问题
网络层DDoS防御主要处理SYN Flood、UDP Flood、ACK Flood、DNS反射放大等流量型攻击。上线前需要在云防护或高防服务里配置好基础策略：对非业务端口的流量直接丢弃；对UDP协议除非业务明确需要，否则全部封禁；对TCP协议开启SYN Cookie或代理验证；对ICMP流量做限速。这些策略配置越早，攻击发生时清洗设备越容易识别正常流量和攻击流量。
更关键的是设置流量基线。上线前做一次全链路压测，记录正常业务高峰期的QPS、带宽、新建连接数、并发连接数、包速率。把这些数值作为告警阈值和清洗阈值的基础。很多业务上线后被打，不是因为清洗能力不够，而是因为阈值设置过高，攻击流量已经混入正常流量打到源站；或者阈值过低，正常促销流量被误清洗。基线数据要按小时、按天、按活动周期分别记录，并在上线后持续更新。
对于超过一定规模的业务，建议在上线前就完成BGP高防的接入测试。BGP高防通过改变路由通告来牵引流量，接入过程涉及AS号、路由策略、回注方式，临时切换往往需要数小时甚至更久。上线前把BGP会话建立好、路由测试通过、回注流量验证无误，攻击发生时只需要触发牵引，不需要临时改网络架构。
应用层防御要落到具体接口，而不是泛泛的“CC防护”
应用层DDoS攻击的目标是HTTP/HTTPS请求，攻击者用大量看似合法的请求耗尽服务器资源。常见的攻击方式包括HTTP Flood、慢速连接、慢速读取、大流量POST、API接口高频调用、验证码接口轰炸、搜索接口恶意查询等。上线前必须对每一个对外API和页面做资源消耗评估，并设置对应的限速和防护策略。
一个实用的方法是按接口类型分级：静态资源接口只允许GET请求，限制单IP请求频率，开启浏览器缓存和CDN缓存；登录注册接口限制单IP每分钟尝试次数，启用验证码或设备指纹，失败次数过多触发锁定；搜索、列表、详情接口设置合理的分页上限和响应体大小，对异常参数直接拒绝；支付、下单等核心交易接口除了限速，还要做幂等和风控校验，防止攻击者用高并发请求制造脏数据。
慢速攻击尤其值得在上线前重点测试。攻击者建立大量TCP连接，每个连接只发送极慢的HTTP头或极慢的读取响应，导致服务器连接池被占满。防御方法包括：设置HTTP头超时时间不超过5秒、请求体读取超时不超过10秒、单IP最大并发连接数限制、连接空闲超时主动断开、对请求速率异常的连接进行挑战验证。这些参数要在Web服务器、负载均衡、WAF三层同时配置，并做一致性检查。
WAF规则不能只开默认策略。上线前要针对业务特点写自定义规则：对URL参数长度、参数个数、请求体大小、Content-Type、User-Agent、Referer做白名单或黑名单限制；对SQL注入、XSS、命令注入等攻击特征做阻断；对突发的高频URL访问做动态挑战。WAF的策略要经过压测验证，确保不会把正常业务请求误拦。
架构层面做弹性扩容和资源隔离，避免单点被打穿
DDoS攻击的最终目的是耗尽资源，资源包括带宽、CPU、内存、连接数、数据库连接池、磁盘IO。上线前的架构设计要保证任何一个资源被打满，不会导致整个业务不可用。具体做法是：静态资源与动态接口分离，静态资源走CDN，动态接口走源站；核心业务与辅助业务分离，搜索、推荐、日志、统计等非核心功能使用独立服务和独立数据库；读写分离，数据库只读副本可以横向扩容，主库只处理写请求；消息队列削峰填谷，突发流量先进入队列，后端按能力消费。
弹性扩容要提前配置好触发条件和扩容上限。云服务器的自动伸缩组、容器集群的HPA、数据库的只读副本扩容，都要在上线前完成演练。攻击发生时，扩容速度决定了业务能撑多久。但扩容不是无限度的，要设置成本上限和熔断机制，避免攻击者通过触发扩容造成云账单爆炸。熔断策略可以针对非核心功能做降级，比如关闭推荐、关闭搜索、关闭日志上报，把资源留给核心交易链路。
数据库是应用层DDoS最常打瘫的组件。攻击者通过高频查询接口让数据库CPU飙到100%，或者通过大量写请求占满连接池。上线前要对所有数据库查询做慢查询分析，对热点数据做缓存，对复杂查询做异步化，对批量写入做合并。数据库连接池要设置合理的最大连接数和等待超时，防止单个接口的慢查询拖垮整个连接池。
准备应急响应流程，把攻击发生后的动作提前写清楚
上线前没有准备应急响应流程，攻击发生时所有人都在群里问“现在怎么办”。应急响应流程要具体到人、具体到命令、具体到时间。谁负责判断攻击类型、谁负责触发清洗、谁负责切流量、谁负责通知业务方、谁负责保留证据，都要在文档里写清楚。每个角色要有备份人员，避免关键人不在线。
应急响应的第一步是判断攻击类型和攻击目标。通过监控面板看带宽、包速率、连接数、QPS、错误率、响应时间的变化趋势，结合WAF日志和流量分析工具，判断是网络层攻击还是应用层攻击，是打主站还是打某个API。判断准确才能选择正确的处置动作。网络层攻击优先触发高防清洗，应用层攻击优先调整WAF策略和限速阈值。
第二步是执行预设的降级方案。降级方案要在上线前定义好，按优先级排序：先关非核心功能，再限流非核心接口，再对核心接口做限速，最后才考虑切换静态页或暂停服务。每一步降级对业务的影响要提前评估，避免降级动作本身造成更大的业务损失。降级开关要放在独立的配置中心，攻击发生时能一键生效，不需要重新发布代码。
第三步是持续观察和动态调整。攻击者会变换手法，防御策略也要跟着变。清洗阈值、限速阈值、WAF规则、降级范围都要根据实时监控数据动态调整。攻击结束后，要逐步恢复降级的功能，观察流量是否正常，防止攻击者杀回马枪。
上线前做一次完整的攻击演练，用真实流量验证防御体系
防御体系配置得再完整，没有经过验证就是纸面方案。上线前要组织一次DDoS攻击演练，模拟不同类型的攻击流量，验证从检测、告警、清洗、降级到恢复的全流程。演练可以使用压测工具模拟HTTP Flood、慢速攻击、高频API调用，也可以使用云厂商提供的攻击演练服务，在可控范围内发送真实攻击流量。
演练要重点验证几个关键点：告警是否能在攻击开始后1分钟内触发；清洗设备是否能在5分钟内完成流量牵引；WAF规则是否能把攻击请求拦截在源站之外；限速策略是否对正常用户影响可控；降级开关是否一键生效；数据库和缓存是否在攻击期间保持稳定；攻击结束后业务能否自动恢复。演练中发现的问题要立即修复，并重新验证。
演练还要验证团队协作效率。攻击发生时，运维、开发、安全、业务方之间的沟通链路是否顺畅，信息传递是否准确，决策是否快速。很多业务在演练中才发现，监控告警发到了已经离职的员工邮箱，或者负责切流量的同事没有操作权限。这些问题在真实攻击中会直接导致业务长时间不可用。
上线后的持续监控和策略迭代，防御体系不是一次性工程
业务上线后，攻击面会随着功能迭代持续变化。新增的API、新接入的第三方服务、新开放的端口、新上线的活动页面，都可能成为新的攻击目标。防御体系要跟着业务变化持续更新：每月做一次暴露面复查，确认没有新增的不必要公网入口；每次功能上线前，对新接口做资源消耗评估和限速配置；每次大促活动前，重新做流量预估和压测，调整清洗阈值和扩容上限。
监控数据要沉淀为可分析的资产。把每次攻击的类型、流量特征、持续时间、影响范围、处置动作、恢复时间记录下来，形成攻击档案。下次遇到类似攻击时，可以直接参考历史处置方案，缩短响应时间。同时，根据攻击趋势调整防御策略，比如某个接口反复被攻击，就要考虑从架构上做隔离或重构，而不是每次靠临时限速。
业务上线前部署DDoS攻击防御体系，本质上是用工程化的方法把“不确定性”变成“可执行的流程”。攻击者永远在找新的漏洞和新的手法，但一个收敛的攻击面、清晰的流量基线、分级的限速策略、预设的降级方案和经过演练的响应流程，能让你在攻击发生时保持主动权。上线前的每一分投入，都会在攻击真正来临时变成业务存活的保障。
