清洗开启后，最容易误伤的往往不是明显异常的请求，而是与攻击流量共享出口地址、访问频率偏高或行为突然变化的真实用户。恶意流量清洗期间正常用户请求的放行策略，不应只靠一份长期白名单，而应结合请求路径、身份、行为和业务影响逐步判断。
目标不是让所有请求无条件通过，而是在控制风险的同时，优先保障登录、提交和读取关键数据等必要操作。规则应能解释、能观测，也能在误判时迅速撤回。
先划清“可放行”的范围
放行可以是直接通过，也可以是降低限制或完成验证后继续。几种方式并不等价：白名单适合稳定、可确认的受信对象；速率限制适合请求合法但短时间过密的情况；挑战验证适合暂时无法确认身份、但仍可能是真实用户的流量。
不要仅凭单个来源地址放行。企业网络、校园网络和移动运营商可能有大量用户共用出口地址；放宽限制后，异常请求也可能一起通过。优先用账号、有效会话、客户端证书或经过验证的设备标识等更细的身份信号。身份信息本身也应校验来源，不能把客户端自行填写的字段当作可信凭据。
按请求风险分层处理
低风险：直接放行并持续观察
对经过身份校验、访问常见页面且行为稳定的请求，可设置较低摩擦的放行规则。规则范围尽量限定到特定操作和必要条件，不要因某个用户通过一次，就永久放行其全部请求。对只读页面与会改变数据的操作，也应采用不同标准。
中等风险：限速或要求验证
同一身份短时间重复调用时，可以先采用速率限制，而不是立即封禁。达到阈值后，可返回 HTTP 429，或要求完成 CAPTCHA 等挑战验证。阈值要根据平时流量、接口成本和活动峰值设置；没有适用于所有站点的固定数字。高成本查询、登录尝试和普通页面访问，应分别评估。
高风险：拒绝并保留复核入口
如果请求缺少必要参数、身份校验失败，或持续触发多项异常规则，可以拒绝访问。对可能影响真实用户的规则，应记录命中的条件、时间和处置结果，避免只有“被拦截”却无法解释原因。
按步骤实施，减少误伤
- 确认关键操作。列出登录、内容读取、表单提交等必须保障的请求路径，注明哪些会消耗较多计算或改变数据。
- 建立基线。按路径和身份类型观察正常请求量、失败率与响应时间。基线应覆盖日常低谷和业务高峰；时间窗口可先从数分钟到十几分钟试起，再按流量变化调整。
- 先限速，后挑战。对轻度异常设置较温和的速率限制；只有持续触发或信号相互印证时，才增加验证或拒绝。避免把一次超阈值直接等同于恶意行为。
- 小范围放量。先对一类路径或一组已验证身份启用放行，观察被拦截比例、验证通过率和关键操作成功率。每次只改少量规则，便于定位变化原因。
- 准备回退。保留规则版本和变更记录。若真实用户失败明显增加，先撤回最近的放宽或拦截规则，再检查来源识别、阈值和挑战流程。
让清洗规则可复核
清洗中心提供的来源信誉、行为分类等信号可以作为判断依据，但不宜单独决定永久放行。若某种浏览器、网络出口或用户群集中遇到挑战，应同时查看请求路径、会话状态和业务端错误，而不是简单扩大白名单。
复核时重点看三类变化：关键操作是否恢复、误拦是否集中在某类用户，以及被放行流量是否带来资源压力。清洗期间正常用户请求的放行策略应随攻击强度调整：压力上升时收紧高成本操作，风险下降后逐步恢复体验；不要在没有观测数据时一次性解除全部限制。
常见问题
白名单能否按来源地址设置？
可以用于边界明确且可验证的固定来源，但共享出口较多时风险较高。应缩小适用路径与有效时间，并定期复核。
为什么验证通过后还要限速？
验证只说明请求可能来自真实用户，不代表高频访问一定安全。对消耗资源较多的操作，仍需按账号或会话控制频率。
怎样判断是否误伤？
结合被拦截记录、关键操作成功率和用户反馈查看；若失败集中出现在同一身份类型或请求路径，应先检查对应规则。
清洗结束后要立即删除规则吗？
不必一概立即删除。先恢复正常阈值，保留必要的基础防护，再分批移除临时规则并观察变化。
简而言之，清洗时应以身份与行为为核心，按风险分级放行、验证或拒绝，并为每条规则设置观察与回退办法。这样才能让恶意流量清洗期间正常用户请求的放行策略既可执行，也便于及时纠偏。