高防显示正在清洗但业务仍在抖动，问题通常不在清洗能力本身，而在回源链路、防护策略或源站架构上。清洗状态只是说明流量到达了高防节点并被处理，不代表业务流量已经健康地回到源站，本文直接拆解这个现象的成因,按优先级给出排查顺序和解决方法。
清洗状态下的业务抖动，根子在哪
高防IP的运作逻辑是：所有流量先到高防节点，清洗掉攻击流量后，把干净流量回源到你的服务器，页面显示“正在清洗”，说明高防节点确实在干活，但业务还在抖，说明从高防节点到源站的这一段路，或者源站本身，出了问题。
行业共识认为，这类问题七成以上出在回源环节，而不是高防节点本身，常见的有回源IP被封、回源线路拥堵、源站带宽被打满、防护策略误伤正常请求，逐项排查时，优先看回源，再看策略,最后查源站。
回源链路是第一个要检查的环节
清洗完成后的流量要通过回源链路送到你的服务器，这条链路如果状态不佳，业务照样抖动，高防节点和源站之间通常走专线或BGP线路，但线路质量会波动，尤其是跨地域、跨运营商的时候。
回源IP是不是被封了
不少用户在配置高防后，忘记了源站防火墙、安全组、主机层面的IP白名单，高防节点的回源IP段没有加白，导致清洗后的正常流量被源站自己拦掉，现象就是业务时好时坏,抖动频率跟攻击流量大小没有直接关系。
检查路径：登录高防控制台，找到回源IP段列表，把这批IP段全部加进源站的防火墙和安全组白名单。很多用户只加了一部分回源IP，漏掉另外几个段，就会间歇性抖动。
回源带宽是否被挤满
攻击流量被清洗掉后，还有一部分正常业务流量要回源，如果源站的入方向带宽本身不够大，或者同时还有其他业务在占用带宽，回源流量就会排队，此时业务表现为响应变慢,而不是直接断连。
建议在源站交换机或服务器的网卡上查看实时流量，如果入方向带宽长期超过总带宽的70%以上（这个比例越高抖动越明显），就需要升级带宽，或者在高防上配置回源限速，需要留意的是，高防IP价格里通常包含一定的回源带宽配额，超出后可能会限速,这也是部分用户遇到的隐性原因。
源站本身扛不住正常请求量
攻击流量是清洗掉了，但正常访客的请求量可能本身就不小，如果源站是单台服务器，CPU、内存、数据库连接数在高并发下被打满，业务自然抖动，高防只负责挡攻击,不负责提升源站的处理能力。
排查方式：登录源站服务器看负载情况，重点关注CPU使用率、负载均值（load average）、数据库慢查询数量，如果持续高位，说明需要扩容或者优化业务架构，有些时候，攻击流量高峰期会连带产生大量正常用户的重试请求，这种叠加效应会把源站打垮,这种情况也是造成抖动的核心原因之一。
防护策略配置不当也会引发抖动
高防的清洗策略不是越严越好，策略配置过松，攻击流量漏进来，源站被波及；策略配置过严，正常请求被误杀，业务也会抖动,关键是找到中间那个平衡点。
防护阈值设置过低
高防控制台里一般有连接数阈值、每秒新建连接数阈值、请求速率阈值等设置，如果这些数值设得比正常业务流量峰值还低，高防节点会在业务高峰期误判为攻击，主动丢弃部分请求,表现出来就是业务在某个固定时间段抖动明显。
解决思路：观察连续一段时间的正常流量曲线，把防护阈值设置在正常峰值的1.5倍左右，这个调整需要找高防服务商配合，大多数厂商的运维团队都支持这类配置调整，如果你对高防IP价格比较敏感，选择服务商时可以把“是否支持免费调优防护阈值”作为一个重要比较维度。
清洗模式跟业务不匹配
不同业务的流量特征差异很大，游戏业务多为长连接，Web业务多为短连接，视频业务多为大流量下载，高防的清洗模式如果跟业务类型不匹配,就会出现误判。
举个例子：某Web业务开启了高强度UDP防护策略，而正常业务恰好有一部分UDP流量用于语音通话，UDP策略过严后，语音数据包被当作攻击流量丢弃，业务听起来就是“一顿一顿的”，这种情况在电商大促期间尤其常见，用户一边抢购一边语音咨询,丢包直接导致体验下降。
调整建议：在控制台查看清洗策略和防护模式，对照业务实际使用的协议类型（TCP、UDP、ICMP等），关闭不必要的严格策略，不太确定的话，先开启观察模式（只记录不拦截）,持续观察几天再切换成拦截模式。
连接数限制触发
高防节点对单IP的连接数有上限保护，这是为了防止源站被大量连接拖垮，如果这个上限设得太低，正常用户建立的新连接会被拒绝，典型表现：老用户访问正常,新用户首次访问超时或打不开。
排查入口：查看高防的“连接数监控”面板，看是否经常接近上限值，如果是，把单IP连接数上限调高，同时检查源站是否开启了ulimit类限制（即文件描述符数量限制），这两处是配套的，在活动大促前,调高这两处数值是常见的准备工作之一。
攻击流量没有完全切干净的情况
页面显示“正在清洗”不代表所有攻击流量都被拦截了，有些流量伪装性强，或者攻击特征跟正常流量高度相似，高防节点会放行一部分，这部分漏网之鱼到达源站,直接消耗服务器资源。
慢速攻击和CC攻击的漏网
慢速攻击的特点是单个请求的速率很低，但持续时间很长，单个请求占用的连接资源很大，CC攻击则模拟真实用户请求，频繁刷新页面或接口，这两类攻击很难完全清洗干净,或多或少会有流量穿透。
应对措施：在源站前面加一层Web应用防火墙（WAF），或者在高防上开启HTTP协议层校验，WAF的规则匹配能力比高防的四层清洗要细致，能识别出更多Web层面的攻击行为，架构上可以做成“高防在入口，WAF在中间，源站最后兜底”。
攻击流量同时打源站IP
有些攻击者会在攻高防IP的同时，扫描并尝试直连源站的真实IP，如果历史DNS解析记录里泄露过源站IP，或者子域名没有走高防，攻击者就能绕过高防节点直接打源站，此时高防页面显示“正在清洗”，但源站已经被打垮了,业务照样崩溃。
验证方法：登录源站服务器，用netstat -an查看当前连接的高危IP来源，如果看到连接不通过高防节点而是直连源站，说明源站IP已经暴露，解决办法是更换源站IP,并且在DNS配置中只保留高防IP的解析记录。
攻击持续时间与业务响应的关系
实际运维中大家会发现一个现象：攻击开始后，业务流量往往不会立即恢复平稳从攻击切换到正常需要一定时间，这就是“恢复期”，在恢复期内，高防节点逐渐放行新请求，业务表现为缓慢恢复，此时会有短暂抖动，通常这个恢复期不会太长，正常情况下等待几分钟即会恢复正常，针对这种情况，建议将高防的“流量清洗完成后的保持时间”调短一些,可以缩短业务恢复的等待窗口。
高防IP与CDN联合使用时的坑
不少用户的业务架构是“DNS解析到CDN，CDN回源到高防IP，高防再回源到源站”，这种三层链路保护强度高，但故障点也多,每一层都可能出现问题。
CDN节点缓存回源超时怎么办
CDN节点访问高防IP时，如果高防正在清洗攻击流量，回源请求可能在高防侧排队，导致CDN节点等待超时，超时后CDN节点会返回502或504错误码（即网关错误）,业务端就表现为页面打不开或图片加载失败。
排查方法：用curl -I命令直接测试高防IP的响应速度，再对比测试CDN节点的响应速度，如果高防响应正常但CDN节点异常，问题出在CDN到高防这一段链路，多数情况下，调整CDN的回源超时时间（从默认的几秒调到10秒以上）可以缓解。
国内高防节点选择与地域关系
高防节点的物理位置会影响回源速度，如果高防节点在华东，源站在华北，跨地域转发会带来额外延迟，攻击发生时，这个延迟会被放大，如果业务对延迟敏感（比如在线游戏），选择高防服务商时要关注节点分布和是否支持BGP线路，国内高防IP价格在几百元到几千元每月不等，价格差异很大程度上取决于节点规模、防御峰值和线路质量，选择服务商时，优先选择节点覆盖低延迟线路的方案,不要单看价格。
一整套排查步骤照着做
按下面的顺序排查，每一步都做记录,很快能定位问题。
- 看高防控制台：确认清洗状态正常后，查看“回源流量统计”,看是否有流量波动异常。
- 看源站带宽：登录源站服务器，用iftop或nload查看实时流量,判断回源流量是否正常。
- 看源站负载：用top命令查看CPU和内存占用，用uptime查看负载均值,判断是否需要扩容。
- 看协议分布：用tcpdump抓包，观察源站收到的流量中TCP、UDP、ICMP的占比,判断是否与业务特征相符。
- 看错误日志：检查Nginx、Apache或业务应用的访问日志，看是否出现大面积5xx错误（即服务器端错误码）,定位误杀来源。
- 看回源IP连通性：在源站上ping高防节点的回源IP，看延迟和丢包率，如果超过正常水平（通常延迟在几十毫秒内）,联系机房排查线路问题。
- 检查连接数限制：查看源站系统级ulimit -n的值、高防控制台的单IP连接数限制。
有些情况要联动服务商处理
上面所述的自查步骤之外，还存在一些需要高防服务商配合调整的深层配置项，大多数服务商支持提交工单或电话沟通来排查故障，在联系服务商前，提前整理攻击开始时间、结束时间、波动规律、抓包数据，能显著缩短沟通和排查时间，多数服务商的技术团队支持远程协助配置，这类支持力度在选择高防IP服务商时,比单纯比较价格更重要。
Q&A：高防显示正在清洗但业务仍在抖动相关问题
问：为什么高防显示清洗结束了，业务还在抖一阵子？
答：清洗结束不代表源站立刻恢复平稳，恢复期内，TCP连接需要重新建立，源站积压的请求需要慢慢消化，数据库连接池要重新分配资源，这一过程通常需要几十秒到几分钟，如果抖动持续时间超过10分钟,说明源站或链路还有未处理完的问题。
问：高防清洗过程中，业务方有哪些事情不能做？
答：不要重启源站服务器，不要改动源站防火墙规则，不要修改DNS解析记录，这几项操作会打断正在进行中的回源链路，让恢复过程变得更慢，建议先观察监控数据，记录抖动规律,等待清洗结束再做调整。
问：如何判断抖动原因到底在高防还是源站？
答：在清洗状态下，用另一台不在攻击范围内的服务器直接访问源站IP，如果访问正常说明源站没问题，问题出在高防回源，如果访问也异常，说明源站本身已经不堪重负,这个对照测试是定位问题最直接的办法。