限制的目的是压住压力，不是拒绝访问

速率限制解决的是同一个人或同一段来源在短时间内发起大量请求的问题。它的目标不是把所有可疑请求都挡在门外，而是让压力保持在业务能承受的范围内，同时给正常访客留出空间。

想清楚这一点，配置时的取舍就容易做了。阈值定得过低，正常用户刷新几次就看不到页面，投诉可能比攻击还多；定得过高，等于没设。先观察再定，比照搬别人的数字靠谱。

还有一个前提容易被忽略：站点本身能承受多少。如果一台机器每秒只能处理五十个请求，限制设在一百就失去意义，因为在到达这个数字之前，网站已经先撑不住了。

统计的维度选哪个

常见的选择有三个：来源地址、会话、以及访问路径。按来源地址统计最直接，能挡住单点高频；按会话统计能应对同一批人换地址的情况；按路径统计则适合保护那些开销大、容易被反复调用的接口。

实际配置里往往是组合使用。整站设一个宽松的上限，再对登录、查询、提交这类敏感位置单独设更严的限制，既能挡住集中压力，又不至于让正常的浏览受影响。

时间窗口的粒度同样重要。按秒统计能挡住突发，但容易误伤；按分钟统计更平稳，代价是压力已经进来一部分。两种可以一起用，分钟级别的上限做总量控制，秒级别的上限挡瞬时洪峰。

例外名单要提前准备

搜索引擎的正规来访者、监控探针、支付回调、合作方的接口调用，这些来源的频率天然高于普通用户。如果不在名单里，限制一开就会出问题，而且往往是在夜里发现。

名单的写法要尽量窄。按具体地址放行比按整段放行好，能写清楚的就不要写范围。名单越宽，被利用的空间越大，日后也没人敢清理。

另外，把名单里每一条的来源和用途记在旁边。过一段时间回头看，能很快判断哪些还有效，哪些对应的服务早就下线了。

上线之后怎么观察

规则刚生效的几天，先别把动作设成直接拒绝。可以选择只记录，让命中规则的请求照常通过，同时把日志留下来。观察几天，看看命中的都是什么人，再决定是否真的拦。

观察期里重点看两类数据：命中次数最多的来源，以及被命中最多的页面。前者能帮你判断规则是不是太宽，后者能提示哪些功能正在被集中使用或者被滥用。

正式拦截之后，也要保留申诉和排查的路径。用户在反馈里说打不开，要能很快从他提供的时间反查到规则日志，这件事本身就要求日志至少留够几天。

速率限制不是一劳永逸的配置。业务上线新功能、做活动推广，访问形态都会变，定期回看比设完就不管更实际。

几个容易被忽略的细节

限制规则对静态资源和动态接口的影响完全不同。图片、样式这类请求量大但开销小，被限速的体验损失不明显；接口一旦被限，用户看到的是功能不可用。

缓存命中率会影响实际压力。同样的请求打到缓存上和打到后端，代价差很多，配置限制之前先看缓存有没有起作用。

代理和负载均衡会改变来源的识别方式。如果拿不到真实的访客地址，按来源统计就会把所有人算成一个，规则一开就是全站受影响。

接口调用方的行为也要考虑。定时任务、批量导出往往在短时间内集中发起请求，规则上线前和这些使用方确认一遍，能少很多投诉。

白名单与规则要有明确的负责人。名单加得越多，越需要有人定期清理，否则判断逻辑会慢慢失效。

规则生效之后的第一周，最好每天都看一下命中情况，及时调整比事后补救容易。

如果限制影响到了业务，先回退再分析，别一边排查一边让用户等着。

调整记录写清楚原因，下次改动时才知道当时是怎么想的。这些细节加起来，决定了限制是有效还是只增加噪音。

限制的日志本身也要留，它是判断规则是否合理的唯一依据。

规则命名写清楚用途，日后维护时不需要打开每一条去看。

条件允许的话，把限制行为做成开关，出问题时能快速回退。