限速阈值设在CDN边缘节点，成本控制效果远优于源站层，核心原因在于边缘限流能以极低带宽成本拦截绝大多数恶意请求，避免源站资源被无效流量消耗。
为什么源站限速是最贵的成本控制方案
源站服务器的带宽成本通常是CDN回源带宽的数倍以上，国内主流云厂商的源站带宽包单价普遍在几十元/兆/月区间，而CDN节点带宽成本往往只有源站的三分之一甚至更低，把限速阈值放在源站，意味着所有流量都穿透到源站才被识别和拦截，即使限速规则再精准，源站已经为这些请求支付了全部网络成本。
更隐蔽的成本陷阱在于源站限速的计算资源消耗，以典型的PHP-FPM或Java应用为例，一个请求到达源站后，即使被限速逻辑直接拒绝，也需要经过Web服务器、应用框架的完整前置流程，CPU和内存占用并不低，据业内专家指出，在大部分业务场景中，无效请求对源站计算资源的占用比例相当可观，某些极端案例中甚至消耗了过半的应用性能预算。
限速阈值放在哪一层更省钱：三层模型对比
要理清限速阈值的成本逻辑,先得明确流量到达源站前经过的几个关键层次。
第一层：CDN边缘节点层
这是距离用户最近的防线,也是成本杠杆最明显的位置，CDN边缘节点散布在全国乃至全球各地，单个节点的带宽容量远超源站，且节点间的流量调度天然具备弹性，将限速阈值配置在这一层，比如单IP每秒请求数超过20次即触发封禁，可以拦截绝大多数爬虫、CC攻击和异常刷量请求，拦截动作发生在离用户最近的网络边缘，源站几乎零感知。
第二层：负载均衡层
四层负载均衡（如LVS）和七层负载均衡（如Nginx）是流量的第二道闸门，这一层的限速优势在于规则更灵活，可以基于URL路径、Header特征、Cookie状态做精细化的速率控制，但问题是，流量已经到达数据中心内部，占用了公网入口带宽，只是还没有打到应用服务器，从成本角度说，这个层级只能节省应用层的计算资源，网络成本已经发生了。
第三层：应用层
应用层限速（比如在业务代码中用Redis计数器实现限流）是灵活性最高的方案，可以结合用户登录态、业务逻辑做动态配额分配，但这是纯成本消耗型方案，带宽全部支付、计算资源全部消耗，还要额外占用Redis等中间件的性能，除非有强业务定制需求，否则这层限速的性价比是最低的。
从三层对比来看,CDN边缘层是唯一能在流量进入主干网之前完成拦截的位置，对带宽成本的控制效率最高。
限速阈值配置的几个关键决策依据
按请求类型区分阈值
静态资源请求（图片、CSS、JS文件）的单价成本最低，且天然支持高并发，限速阈值可以放宽；动态API请求消耗源站计算资源，阈值需要收紧；登录、支付、短信验证码等敏感接口要设置独立阈值，通常比普通API再低一个数量级。
按业务时段动态调整
大多数业务存在明显的流量波峰波谷,凌晨时段全网流量下降，但爬虫和扫描器的活跃度并不低，这一时段的限速阈值可以比白天更激进，比如将单IP每分钟请求数从300降到60，能有效减少对源站的无效回源，部分CDN服务商支持按时间计划调整限速策略，这属于纯配置操作，零额外成本。
状态码监控与阈值联动
配置限速策略时同步开启状态码监控,如果某个IP触发限速后，源站收到的请求数没有明显下降，说明限速阈值配置在了一个过低或过高的位置，需要联动调整，这个监控项在百度云、简米云等平台的CDN控制台里都能直接配置，定期观察数据变化即可。
跨地域节点差异
国内网络环境下,华北、华东、华南三大区域的带宽成本差异不太大，但运营商之间的互联质量会影响回源效率，如果业务主要面向特定区域，比如只服务华东地区用户，可以将限速阈值在华东节点群上设置更低的回源限制，配合区域内回源带宽包降低成本，华南地区存在大量跨境流量场景，需要对海外IP单独设置更严格的阈值。
什么时候源站层仍然需要保留限速
并非所有场景都适合完全依赖CDN限速,下面几种情况建议保留源站层限速作为兜底。
- 业务出现突发性热点事件,请求量瞬间暴增，CDN节点缓存命中率下降，大量请求回源，源站需要一个快速熔断机制保护可用性
- 内部系统或APP客户端绕过CDN直连源站,这类请求在边缘层完全不可见，只能靠源站和接入层限速兜底
- 某些业务场景的数字签名校验等逻辑必须在源站完成,无法在边缘层判别请求合法性
保留源站限速不等于把主防线放在源站,而是作为最后一道保险，这些年国内多次出现的源站被打穿事故，多数情况下不是CDN没有防护能力，而是源站存在绕过CDN的直连IP暴露问题，运维人员应该定期检测源站IP是否泄露，确保所有公网流量都经过CDN清洗。
限速阈值配置实操路径
第一步：评估业务正常流量基线。 通过百度统计或自建监控系统，统计近30天的平均QPS、峰值QPS、单IP最大请求数，用峰值QPS × 1.5作为CDN限速阈值的下限参考。
第二步：在CDN控制台配置限速。 以普遍使用的CDN平台为例，进入「安全防护」→「速率限制」→「新建规则」，选择域名，填写单IP每秒请求阈值和封禁时长，勾选需要限速的请求方法，保存后先在测试环境验证。
第三步：观察回源带宽变化。 配置生效后24-48小时，对比源站监控中的带宽和请求数指标，如果回源量下降明显且业务无异常报错，说明阈值设置合理，如果用户反馈访问卡顿或白屏，说明限速过严，调高阈值即可。
第四步：配置告警策略。 在云监控平台设置回源带宽超限告警和CDN拦截请求数突增告警，告警阈值建议设为正常峰值的80%。
限速阈值变更时的成本影响评估
| 调整方向 | 带宽成本影响 | 计算成本影响 | 用户体验风险 |
|---|---|---|---|
| 边缘层下调阈值 | 显著下降 | 几乎无变化 | 误伤正常用户 |
| 边缘层上调阈值 | 小幅上升 | 几乎无变化 | 风险降低 |
| 源站层下调阈值 | 无变化 | 小幅下降 | 误伤且无明显收益 |
| 应用层新增限速 | 无变化 | 需要额外计算资源 | 更精细但更复杂 |
上表的数据逻辑很清楚,调整边缘层阈值是唯一能直接影响带宽成本的操作，多数云平台CDN基础防护功能已经包含基础限速能力，不需要额外购买高防包，这也是首选边缘层限速的一个重要原因。
常见问题
限速阈值配置太低了，用户被误封怎么办？
先检查封禁时长,如果是临时封禁（如10分钟），影响相对可控，建议开启CDN提供的白名单机制，将正常用户IP加入白名单，更为稳妥的做法是使用验证码挑战替代直接封禁，在边缘层返回验证码页面，既拦截了机器人流量，又不伤害真实用户。
如何判断当前限速策略是否合理？
观察两类指标：一是回源带宽对比限速前后的降幅，二是业务侧关于访问异常的用户反馈量，也可以开启CDN日志分析，统计被拦截IP中是否存在正常用户特征（如移动端User-Agent占比过高），如果相当一部分被拦截IP都在访问正常页面的深度路径，就说明阈值偏严。
源站要不要保留限速规则？
建议保留简单的全局限速作为兜底,比如单IP每秒5次访问即拒绝，核心目的是防止源站IP泄露或CDN被绕过时完全没有防护，这个兜底阈值只是应急使用，日常流量正常情况下不会触及，因此不会成为性能瓶颈。