DDoS清洗与业务可用性之间的权衡，关键不在于把阈值设得尽可能高或低，而在于及时识别异常，同时给正常流量留出空间。阈值过高，攻击流量可能在触发清洗前耗尽带宽或连接资源；阈值过低，促销、版本发布等正常流量高峰也可能被限速或拦截。
因此，清洗阈值应结合业务的历史流量、基础设施容量和异常时的处置能力制定，并按攻击类型分别评估，而不是只设一个全局数值。
先看业务承受力，再定触发条件
阈值不是脱离环境的固定常数。同样的流量增长，对带宽充足、可横向扩展的服务和资源紧张的单点服务，影响可能不同。除了流量大小，还应关注连接数、请求成功率、响应时间、服务器资源，以及上游链路是否接近容量上限。
建立基线流量时，可按工作日、周末和已知业务活动分别观察历史曲线，并标记发布、促销等计划事件。只用长期平均值容易忽略高峰；只看短时间峰值，也可能把突发正常访问当成攻击。基线需要定期复核，尤其是在架构、用户规模或访问路径发生变化后。
阈值太松与太严，各有代价
- 阈值偏高：触发较少，正常流量较少受影响；但检测和处置启动较晚，可能让带宽、连接表或应用资源先承压。对容量余量小、故障影响范围大的服务，这种风险尤其需要评估。
- 阈值偏低：更早进入防护流程，有助于缩短攻击流量影响时间；但可能产生误拦截，造成登录失败、接口超时或用户访问不稳定。访问量突然增长时，这种可能性会增加。
例如，TCP SYN flood 会大量发起连接请求，观察连接状态和新建连接速率，比单看总流量更有参考价值。相反，正常用户集中访问时，流量和连接数也可能同步上升；若不结合请求成功率、来源分布和业务日历判断，单项指标触发就可能伤及真实用户。
用分层处置替代“一刀切”
较稳妥的做法，是先采取影响范围较小、可回退的措施，再按风险升级。具体能力取决于清洗服务和网络架构；例如，应用层可以采用更严格的请求校验或限速，而网络层的攻击通常需要由上游防护设备处理。不要假定某一种措施适用于所有协议和流量。
- 整理近期正常流量曲线，区分常态、计划高峰和已知异常，并标出容量告警及服务错误率变化。
- 按流量类型设置检测条件。组合使用速率、连接状态和业务健康指标，避免仅凭单个瞬时峰值自动封禁。
- 配置分级动作：先告警或加强观察，再对可识别的异常流量做定向处理；只有在业务持续受损、其他措施不足时，才考虑大范围阻断。
- 演练阈值触发后的处置流程，明确谁能调整规则、如何回退，以及如何确认正常用户是否恢复。每次调整后检查错误率、延迟和资源占用。
- 攻击缓解后复盘误拦截和漏拦截，记录触发指标、持续时间、受影响服务和回退原因，再更新基线与规则。
哪些情况下应谨慎扩大阻断
若异常信号主要来自单一指标，而核心业务指标仍正常，应先核验流量特征，不宜立刻扩大拦截范围。若服务已出现明显故障，且攻击持续消耗链路或连接资源，则应及时升级处置，并与网络服务商或清洗服务提供方确认可执行的动作。
黑洞路由可能将目标流量整体丢弃，适用于优先保护网络其他部分、且目标服务暂时不可用也可接受的极端情形；它并非精细清洗的替代方案。具体是否可用、影响范围多大，取决于网络和服务商的配置。
常见问题
阈值应该按带宽还是请求数设定？
取决于被保护对象和攻击类型。带宽适合观察链路压力，请求数、连接数及业务错误率则能补充应用和连接层信息，通常应组合判断。
流量突然翻倍就应触发清洗吗？
不一定。应先与历史高峰、计划活动和服务健康状况对照；如果增长同时伴随异常连接、延迟上升或错误率恶化，再提高处置优先级。
多久调整一次阈值？
没有适用于所有业务的固定周期。发生架构变更、访问模式变化、误拦截或攻击事件后应复核；日常则按团队运维节奏检查基线和告警。
归根结底，DDoS清洗与业务可用性之间的权衡，需要用业务健康指标校验防护效果，并为规则保留回退路径。合理阈值不是一次设定后不再变化，而是随容量、流量模式和处置经验持续校准。
