## 症状现象
接入高防的服务器在攻击时段或流量尖峰之后，业务明显变慢：延迟升高、部分请求超时，但源站 CPU 与带宽都不高。攻击已经过去或正在被防御，为什么正常的用户反而变慢了，这类现象指向两个方向：清洗策略误伤，或回源链路成为新瓶颈。
## 定位过程
第一看清洗数据：高防的防护记录会展示被丢弃与被挑战的请求量与特征。清洗阈值过低的场景，正常高峰流量也会被部分丢弃或牵引到验证流程，用户体感就是变慢与偶发失败；对比清洗触发的流量特征与正常用户的访问模式，重叠度高即存在误伤。第二看回源链路：清洗后所有流量经清洗节点回源，回源带宽与源站连接数承载能力成为新的闸口，回源侧饱和时表现同样是慢而非报错。
curl -o /dev/null -s -w "ttfb:%{time_starttransfer} total:%{time_total}\n" \
源站内网地址/health
从清洗节点与本地分别探测源站响应时间，两边差异大说明慢在链路，差异小说明慢在源站自身。
## 解决方法
误伤侧：向服务方申请调整清洗阈值与策略，把已知正常业务的特征加白，如固定接口的高频轮询、大文件上传的特征流量。回源侧：扩回源带宽、源站侧开启长连接复用、必要时源站前置缓存分担，让清洗流量的压力不在回源这一跳堆积。两项都处理后再观察一个完整攻击时段验证效果。
## 预防建议
接入高防后必须做一次正常高峰的对照压测，记录清洗前后的延迟差，作为日后判断的基线。顺云高防服务器的防护记录与回源监控平时就要看熟，真出事时才有对比可言，工单沟通附上时间线与两端探测数据，处理最快。
经验上再记一条：清洗期间的性能数据要单独留存，包括触发时间、清洗量级、回源峰值三项。这份档案既能支撑后续的阈值调优，也是与服务方沟通的客观材料，长期积累后，业务流量的画像会越来越清晰，误判越来越少。