攻击流量清洗阈值与业务误伤平衡，不能只看拦截量：阈值设得过低，突发的正常访问可能被挡；设得过高，又可能让攻击流量持续冲击源站。清洗启动后出现请求失败，先确认是清洗设备拦截、源站拒绝，还是网络链路异常，再根据证据逐项调整。
先判断请求在哪一层受阻
记录问题发生的时间、用户看到的错误、受影响的服务和清洗策略变更时间。将清洗平台的拦截日志与源站访问日志、应用错误日志按时间对齐，检查请求是否到达源站。若清洗侧显示大量丢弃而源站没有对应记录，重点排查规则与阈值；若请求已到源站，则继续查看应用状态和依赖服务，避免把所有故障都归因于清洗。
同时观察不同指标：带宽（比特每秒）、包速率（包每秒）、新建连接速率，以及业务成功率和延迟。单一指标不够判断风险。例如带宽没有明显升高，不代表小包或连接型攻击不存在；而业务访问在活动时段增长，也不自动意味着攻击。
沿着“证据—规则—影响”排查
- 圈定时间窗口。选取故障前后的分钟级数据，并与同星期、相近时段的历史基线比较。没有可用基线时，先观察一段覆盖业务波动的时间，再把异常增长作为调查信号，而不是直接封禁条件。
- 定位命中的规则。查看清洗日志中的策略名称、匹配字段、处置动作和来源特征。区分协议异常、连接速率限制、来源信誉规则与应用层特征规则；不同规则误伤原因不同，不能只靠提高一个总阈值解决。
- 抽查失败请求。在获得授权并保护隐私的前提下，对照时间戳、目标服务、请求特征及响应结果。确认被拦截请求是否来自真实业务流程，并检查是否集中在共享出口、移动网络或代理网络。共享地址可能承载大量互不相关的用户，不能仅凭单个 IP 的请求量判断恶意。
- 小步调整并验证。优先把自动封禁改为告警或挑战，或缩小规则适用范围；每次只改一项，记录旧值、新值和生效时间。观察误拦截、攻击指标、延迟与成功率，确认改善后再决定是否扩大调整。
阈值怎么调，才能避免反复误伤
固定阈值与动态基线
固定阈值便于审计，适合流量稳定、峰值边界明确的服务；缺点是难适应促销、发布或周期性峰值。动态基线更能反映时段差异，但若学习窗口中混入攻击，基线可能被抬高。实践中可用历史分时基线辅助判断，并保留人工审核和最大限值。比如把高于近期同类时段约1.5至3倍的请求速率设为排查告警起点，而非通用封禁线；实际范围需按服务容量、请求成本和历史波动校准。
先缩小范围，再考虑放行
如果确认某条规则误伤，优先针对服务、协议、路径或特定规则做例外，不要直接关闭整套清洗策略。白名单应限定对象、用途和有效期限，并设置复核；对共享 IP 或大网段整段放行，可能同时放过恶意请求。限速规则也应区分新建连接、并发连接和请求速率，避免用一个数字覆盖不同风险。
变更后的检查与回滚
每次调整前保存规则快照，并明确回滚条件，例如业务失败率持续上升、清洗侧拦截量异常下降且源站负载恶化。调整后连续观察多个采样周期；采样周期可从数分钟起步，具体取决于流量变化速度。对比调整前后的拦截原因、业务成功率、延迟和源站资源，确认没有把攻击压力转移到后端。攻击流量清洗阈值与业务误伤平衡，最终依靠可追溯的日志、有限范围的变更和及时回滚，而不是一次性寻找所谓固定最佳值。
常见问题
清洗一启动就有请求失败，是否应该立即关闭？
不一定。先确认命中规则和失败范围；若影响扩大，可按预案临时降级到告警、挑战或更窄的规则，并保留基础防护。
业务峰值能否直接加入白名单？
通常不建议。优先按时段校准基线或调整具体规则，并监控峰值中的异常来源与请求特征。
只有带宽数据，够不够判断阈值？
不够。还应结合包速率、连接变化、拦截原因和业务结果；不同攻击形态可能只推高其中一类指标。
如何确认调整确实减少了误伤？
比较调整前后的正常请求成功情况、拦截日志及源站状态，并确认攻击指标仍处于可控范围；保留变更记录，必要时回滚。
