清洗生效但业务仍慢，根因大概率在回源链路口径上，直接查回源链路的带宽、延迟和丢包，比反复调清洗策略更有效。
很多团队遇到网站被攻击，第一反应是开清洗、拉高防护阈值，清洗一开，攻击流量确实被挡在了门外，控制台显示“清洗中”，业务却还是卡顿、超时、甚至时不时连不上，这时候，直觉会告诉你“清洗没生效”，于是继续调策略、换IP、加防御，但事实往往是另一回事：清洗确实已经生效，攻击流量也确实被拦住了，慢的根源在回源链路上。
清洗后网站还是慢什么原因，先理清这条数据路径
清洗和回源是两条完全不同的路，搞清楚这个逻辑,排查方向就不会跑偏。
清洗链路和回源链路是两回事
正常业务请求的路径是：用户 → 清洗节点（或CDN节点） → 回源链路 → 源站服务器，清洗节点负责把攻击流量过滤掉，把正常流量放行，但放行之后的流量，还是要走回源链路回到你的源站。
这里经常被忽略的细节是：清洗节点只管“过滤”，不管“加速”，如果源站和清洗节点之间的回源链路本身带宽小、延迟高、丢包多，那就算清洗把攻击流量全挡了,正常用户的请求依然会被堵在回源这一段。
业内专家指出，多数清洗服务商的能力考核指标是“攻击流量拦截率”，而不是“回源链路质量”，回源链路往往是客户自己拉的带宽，或者是默认的公网线路,跟清洗节点的高防带宽是两个独立体系。
判断清洗有没有生效，别只看控制台
控制台显示“清洗中”，不代表业务就应该恢复，判断清洗是否生效,要看三个指标：
- 源站入向流量是否降到正常水位，而不是只看清洗节点的总流量
- 攻击流量占比是否明显下降，如果清洗后攻击流量占比还很高，说明清洗策略没匹配上
- 回源连接数是否稳定，如果回源连接数持续打满，那瓶颈就在回源链路上
这三个指标可以从源站的流量监控、清洗服务商的报表、以及回源侧的负载均衡监控里交叉验证。
网站清洗后还是慢什么原因，先看这五个关键瓶颈点
清洗生效后业务仍慢，打开源站和回源路径的监控面板，按下面五个维度逐个排查，大多数情况下,问题出在这五个地方。
回源带宽被打满，最常见的慢根源
清洗节点把攻击流量过滤后，正常流量会集中回源，如果源站的回源带宽只有10Mbps或20Mbps，而业务正常的峰值流量就需要15Mbps，那清洗一开,回源链路就会持续处于满负荷状态。
怎么判断回源带宽是否打满？
- 登录源站服务器的流量监控，看入向带宽使用率是否持续超过80%
- 对比清洗前后的回源流量变化，如果清洗后回源流量反而涨了，说明清洗节点在向源站转发正常流量时叠加了额外的包头开销
- 查看清洗服务商的回源报表，看回源峰值带宽是否接近你购买的回源带宽上限
如果是这个原因，最快的解法是临时扩容回源带宽，或者在清洗节点上配置回源限速,限制单IP的源站回源速率。
源站侧连接数超限或CPU瓶颈
回源链路不只是带宽问题，清洗生效后，攻击流量被拦截，但源站每秒要处理的新建连接数可能不降反升,因为清洗节点会把所有合法请求以更快的速度转发回源。
看源站的三个数据：
- TCP连接数是否超过系统上限（
ss -s或netstat -s可查） - CPU使用率是否持续高于70%，特别是软中断（si）占比
- 后端应用服务（Nginx、Tomcat等）的请求队列是否堆积
如果连接数和CPU都偏高，先调大源站的最大文件描述符和TCP backlog，同时检查后端服务的线程池配置，不要急着继续升清洗阈值,那是治标不治本。
运营商链路丢包和绕路，严重拖慢回源速度
回源链路经过的运营商节点一旦出现丢包或绕路，业务就会表现为“转圈圈、加载慢”。
常见现象是：清洗节点回源IP和源站IP在同一个城市，但回源流量绕到了其他省份的运营商骨干节点，用 MTR 或 tcptraceroute 测一下清洗节点回源IP到源站的路径,看看有没有跨地域绕路。
- 如果中间某个跳数的丢包率超过5%，且后续跳数丢包率持续不恢复，说明该段链路质量差
- 如果路径在省际之间来回跳，说明运营商路由策略有问题，需要联系清洗服务商优化回源路由
行业内比较常见的做法是让清洗服务商提供多线BGP回源，让回源流量自动选择最优路径,避免单一路由绕路。
TLS握手和证书协商耗时过高
现在大部分业务都上了HTTPS，清洗节点回源到源站时，如果源站的TLS握手配置不合理，每次请求都要重新协商密钥,耗时就会显著增加。
排查方法：用 curl -w 输出时间分解，重点看 time_ssl 和 time_connect 两个指标。
| 指标 | 正常范围 | 异常说明 |
|---|---|---|
| time_connect | 小于100ms | 超过200ms说明TCP握手慢，链路有延迟 |
| time_ssl | 小于300ms | 超过500ms说明TLS协商慢，证书链太长或会话复用未开 |
| time_total | 小于1s | 超过2s说明整体链路有问题 |
如果是TLS慢，开启源站的
SSL会话缓存和OCSP Stapling,能明显降低回源握手耗时。
DNS解析调度异常导致回源节点不优
清洗模式下，域名解析会被切换到清洗节点IP，如果DNS调度策略没配好，用户可能被调度到距离源站很远的清洗节点,回源链路自然就长了。
排查方法不复杂：
- 用
dig命令查看域名解析结果，确认解析到的IP是清洗节点还是源站IP - 对比不同地域的解析结果，看是否存在明显的跨地域调度
- 检查清洗服务商的智能DNS配置，确认是否开启了“就近解析”
如果解析节点跨地域，联系清洗服务商调整DNS调度策略，让用户就近接入清洗节点,缩短回源路径。
CDN回源慢怎么排查，按这套命令走就能定位
手动排查回源链路，离不开几个基础但非常有效的命令，下面这些命令适用于Linux源站环境,直接在源站服务器或者能访问到源站的跳板机上执行即可。
第一步：确认清洗节点的回源IP
先到清洗服务商控制台找到分配给业务的回源IP段,然后在本机执行：
dig +short yourdomain.com
如果解析结果返回的是清洗节点IP，说明流量已经切到清洗链路，接下来用返回的IP作为目标,测试回源连通性。
第二步：测试回源链路每个节点的延迟和丢包
mtr -rwz --report 回源IP地址
重点看Loss%和Avg两列：
- 如果最后一跳（源站）的丢包率高于3%，而其他跳数正常，说明源站出口带宽饱和或本地防火墙丢弃
- 如果中间某跳丢包高，但后面恢复，运营商设备可能在做限速或整形
- 如果所有跳数都稳定，但延迟比正常值高50ms以上，说明存在绕路
一条回源链路正常延迟应该在10-30ms内（同城情况下）,超过50ms就该引起重视。
第三步：用curl看HTTPS回源耗时分解
在源站本机绕过清洗节点，直接请求源站业务接口,拿到一个基准值：
curl -o /dev/null -s -w "连接耗时:%{time_connect}snTLS耗时:%{time_appconnect}sn总耗时:%{time_total}sn" https://你的域名/healthcheck
再把请求路径改为经过清洗节点,对比两次数据的差异：
- 如果直接访问源站快，经过清洗后慢，问题在清洗节点到源站的回源段
- 如果两者都慢，先排查源站自身性能
第四步：抓包看TCP重传情况
tcpdump -i eth0 host 清洗回源IP and tcp port 443 -c 100
观察抓包结果里有没有大量 [P.] 标记后的重传包，重传率超过5%基本能判定链路存在不稳定因素,需要向清洗服务商报障提供这个抓包文件作为依据。
回源链路测试命令与场景应对对照
| 场景 | 推荐命令 | 预期指标 | 异常处理 |
|---|---|---|---|
| 链路延迟高 | mtr -rwz --report <回源IP> |
平均延迟<50ms | 联系清洗服务商优化回源路由 |
| 回源丢包 | ping -f -c 100 <回源IP> |
丢包率<1% | 更换回源线路或增加冗余链路 |
| TCP握手慢 | curl -w "time_connect:%{time_connect}" |
<100ms | 检查源站防火墙和安全组规则 |
| TLS协商慢 | curl -w "time_appconnect" |
<300ms | 开启会话缓存和OCSP Stapling |
| 带宽打满 | iftop -i eth0 -f "host <回源IP>" |
使用率<80% | 扩容回源带宽或配置回源限速 |
在配置清洗策略时，同步做两件事：一是把回源IP加入源站安全组的白名单，避免清洗节点的回源流量被源站防火墙误杀；二是在清洗服务商侧开启健康检查,确保回源IP异常时能自动切换备用节点。
回源链路怎么看是否瓶颈，Q&A 常见问题
清洗生效后，源站入向流量降了，但业务还是慢，能确定是回源链路问题吗？
大概率是，源站入向流量降了，说明清洗拦截有效，但业务响应慢取决于回源带宽的剩余容量和链路质量，建议先看回源带宽使用率，如果持续超过80%，基本可以判定瓶颈在回源带宽，如果带宽不高但延迟大，用 mtr 看链路丢包和绕路情况。
清洗服务商说回源链路没问题，但我们的监控显示回源延迟很高，以谁的为准？
以源站侧实际抓包数据为准，清洗服务商的监控视角是他们的节点出口，源站监控视角是数据到达源站入口，两者之间有运营商链路的一段盲区，用 mtr 的结果和 curl -w 的耗时分解数据去跟服务商沟通,让服务商配合排查运营商中间链路跳点的延迟情况。
回源链路带宽扩容后，业务恢复了，但成本增加不少，有没有更省钱的优化方式？
有限速和链路冗余两种思路，在清洗服务商侧配置回源限速，把单连接速率控制在正常业务峰值的1.2倍左右，避免异常流量瞬间打满带宽，同时可以考虑把静态资源剥离到对象存储，减少回源流量，行业共识认为，回源链路成本最优的做法是让回源流量只承载动态接口请求，静态资源走CDN直接回源到存储层,从架构层面降低对回源带宽的依赖。
清洗生效只是第一步，业务恢复才是目标，把排查重心从清洗策略转向回源链路，用数据定位具体瓶颈节点,才能把慢的问题彻底解决。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/651474.html
