防护服务挡住了攻击，页面却依然缓慢甚至无法打开，原因可能不在过滤能力，而在源站接收剩余流量的链路。理解源站回源带宽不足对防护效果的影响，关键是把“攻击有没有被拦截”和“源站能否处理正常请求”分开评估。
流量被过滤后，为什么源站仍可能拥塞
常见的流量防护架构会在用户与源站之间检查请求，过滤可疑流量，再把需要源站处理的请求转发过去。源站的出口带宽、入口带宽和处理能力仍是独立的限制：防护层能减轻攻击压力，但不会自动扩充源站的网络容量。
当正常回源流量超过链路可用带宽时，响应可能排队、延迟上升或丢失。用户看到的表现包括加载变慢、下载中断和间歇性超时。源站回源带宽不足对防护效果的影响，正体现在“攻击已被拦截，但正常服务仍不可用”这一落差上。
还要区分带宽瓶颈与应用瓶颈。若链路尚有余量，但源站处理请求的能力达到上限，增加带宽未必能解决问题；若带宽先满，即使应用还有余力，数据也无法及时送达。缓存命中较高时，部分内容可由前置节点直接返回；动态请求、缓存未命中和大文件传输则可能持续占用回源链路。
先用峰值业务流量估算需求
核算应关注业务高峰，而不是只看月平均值。可以从源站或网络设备的历史监测中查看忙时入出方向流量、请求量及响应大小；没有可靠记录时，先对代表性请求做测量，再以预期峰值估算。规划时可预留约30%至50%的带宽余量作为起点，但这只是经验范围，突发性、流量增长和运营商线路条件都可能改变需求。
一个便于复核的估算方式是：回源吞吐量约等于每秒回源请求数乘以平均响应字节数，再换算成比特率。比如假设每秒有600个请求回源，平均响应为200KB，则数据量约为120MB/s，折合约960Mbps；这是理想化算例，未计协议开销、重传及峰值波动，不能直接当作采购规格。若响应大小差异很大，应分别核算普通页面与大文件等流量类型。
配置前后按步骤核验
- 找出链路上限：确认源站线路的实际可用带宽，区分标称速率与高峰时可持续使用的容量，并分别记录上、下行方向。
- 整理业务基线：选取忙时流量、请求速率、响应大小和缓存命中情况，排除备份、更新等非日常任务对数据的干扰。
- 估算回源需求：把正常业务峰值与可能的增长空间纳入计算，并为突发请求留出余量。不要把防护服务标注的总承载能力当成源站所需带宽。
- 检查其他限制：同时核对源站可处理的并发连接、应用响应能力和磁盘读取速度。回源链路够用，不等于整条服务路径没有瓶颈。
- 小流量验证并复查：配置后观察防护层转发量、源站链路利用率与用户侧响应。逐步增加业务压力，确认正常峰值时仍有余量；出现拥塞时，先定位是带宽还是应用处理能力不足。
用正确的指标判断防护是否有效
只看攻击流量是否下降，容易漏掉源站已经被正常回源请求压满的情况。建议把清洗流量、源站回源流量、链路利用率和业务响应表现放在同一时间线上比较。若攻击期间清洗流量上升、源站流量仍处于可承载范围，而访问恢复较好，说明过滤与回源链路配合正常；若源站带宽长期贴近上限，即使没有明显攻击，也需要调整带宽、降低不必要的回源或改善缓存策略。
因此，源站回源带宽不足对防护效果的影响，不应只在故障后追查。先量清楚正常业务峰值，再留出适当余量，并把带宽与应用能力分别验证，才能判断防护配置是否真正适合源站。
常见问题
防护带宽很大，源站带宽可以较小吗？
可以，但前提是过滤后的正常回源流量低于源站可用容量。防护层的标称能力不能替代源站核算。
只增加源站带宽就能解决访问慢吗？
不一定。若瓶颈在应用处理、存储读取或上游线路，单纯扩带宽可能没有明显改善，应先用监测数据定位瓶颈。
多久复核一次估算？
业务增长、流量结构改变或发生异常高峰后都应复核；至少应在调整防护架构前重新核算，并在配置后验证实际表现。