高流量网站抗DDoS部署方案最容易出问题的地方，往往不是设备或服务选得不够强，而是流量入口、源站访问和异常处置没有连成闭环。攻击可能消耗网络带宽，也可能针对连接、协议或应用请求；只挡住其中一类，并不代表网站整体可用。
部署前先明确保护范围：哪些域名和端口对外开放，哪些服务必须持续可用，出现误拦时由谁调整规则。下面这些配置误区，适用于自建防护或使用第三方服务的场景。
入口接入了，源站却仍然暴露
网站流量经过CDN或DDoS清洗后，如果用户仍能通过历史DNS记录、其他子域名或公开配置找到源站公网地址，并直接访问，就可能绕过防护。此时入口处的过滤规则无法覆盖直连流量。
- 盘点公网DNS记录、证书中可见的域名、邮件或文件服务配置，找出可能泄露源站地址的线索。
- 确认业务请求确实经由防护入口转发，再将源站入站策略收紧为仅允许防护平台所需地址和健康检查来源；管理入口单独限制。
- 检查应用是否只信任可信代理传入的客户端地址字段，避免外部请求伪造字段影响限流或审计。
不能仅凭“DNS已指向防护服务”判断源站安全。源站若还承载邮件、远程管理等其他服务，应分别制定访问策略，避免误封必要连接。
把一种防护能力当成全套方案
网络层与应用层要分开评估
大流量UDP攻击或连接耗尽，与针对登录、搜索、接口的HTTP请求洪泛并非同一种问题。网络层的DDoS清洗可处理部分异常流量，但应用请求可能语法正常、行为异常；WAF能按协议和请求特征过滤，却不能代替上游带宽防护。Anycast可将流量分散到多个网络入口，但效果取决于服务覆盖、路由和攻击类型。
选择时应逐项核对：防护是否覆盖实际使用的协议和端口，清洗后客户端地址如何传递，流量超过能力边界时如何通知和处置。不要只看产品名称或单一峰值指标，也不要假设开启WAF后所有洪泛请求都会被拦截。
规则过宽，正常用户也可能进不来
直接按单一IP设置很低的请求阈值，可能误伤共享出口下的多个用户；对所有地区、设备或路径一刀切，也可能拦截搜索引擎、移动网络或关键接口。反过来，规则只看请求频率，也可能漏掉低频但持续消耗资源的请求。
- 先观察正常时段与业务高峰的请求特征，按路径、方法、会话状态和响应码区分关键业务。
- 先启用记录或告警模式，核对命中样本，再对高风险路径逐步执行挑战、限速或拦截。
- 设置可撤销的例外规则，并记录变更人、时间和理由；遇到异常时能快速定位是哪条规则生效。
限速阈值没有适用于所有网站的固定数字。应结合正常峰值、接口成本、用户共享网络情况和防护平台统计调整，并为规则变更保留观察窗口。
DNS切换与应急流程没有验证
把DNS解析切到备用入口，不能保证切换立即对所有用户生效：递归解析器会按缓存时间处理记录，旧连接也可能继续存在。设置较短TTL有助于缩短部分切换等待，但应提前调整并验证，不能在攻击发生后才假定全球缓存已更新。
将高流量网站抗DDoS部署方案落地时，可按以下顺序做演练：
- 确认主入口、备用入口、源站访问白名单和DNS变更权限均可用。
- 在获准的测试环境或与服务方协调的范围内，验证告警、流量切换及回源链路；不要未经授权对生产系统进行压力或攻击模拟。
- 记录切换触发条件、联系人和回切步骤，检查回切后是否会重新暴露源站或造成流量绕行。
监控至少要能区分入口流量、源站流量、请求错误和业务关键操作是否成功。只看总流量曲线，难以判断防护是否生效、还是网站已经因规则误拦而不可用。
常见问题
接入CDN后还需要单独考虑DDoS吗？
需要。CDN可代理和缓存部分内容，但防护范围受协议、端口、配置及服务能力限制，不能默认覆盖源站直连或所有应用请求。
是否应该把源站彻底关闭公网访问？
若业务架构允许，可限制为仅接受可信防护入口的回源流量；同时确认健康检查、管理和其他必要服务有独立、安全的访问通道。
怎样判断规则是否误伤用户？
对照规则命中记录、错误率和关键业务成功率，并抽查受影响路径与用户网络特征；不要只依据攻击流量下降判断效果。
配置完成后还要做什么？
定期复核公开入口、白名单和告警联系人，演练切换与回切。高流量网站抗DDoS部署方案应随业务域名、接口和流量特征变化同步更新。