同样是短时间访问变多，背后的原因可能完全不同：有人连续刷新公开页面，搜索引擎在抓取更新内容，合作程序按约定读取数据，也可能是自动化请求在消耗资源。网站遭遇异常请求时的限流策略，不应把“频率高”直接等同于“恶意”，而要先辨认请求来自哪里、访问了什么，再决定限制范围。
先给请求分类，别只看来源地址
单一信号容易误判。家庭网络、公司出口和移动网络都可能由多人共享同一个公网地址；自动化程序也能伪造浏览器标识。因此，判断时应组合查看请求路径、访问间隔、登录状态、会话标识、请求方法、响应结果和资源消耗。来源地址可以作为线索，但不宜单独作为封禁依据。
- 正常用户：通常会访问多个页面，操作间隔并不完全固定，可能携带有效会话。遇到短时集中访问时，可先看是否伴随大量正常页面浏览和成功请求。
- 搜索爬虫：不能只凭 User-Agent 自称 Googlebot 就认定可信。对声称来自 Google 的爬虫，可按 Google 提供的验证说明核对来源；无法验证的请求应暂列为未知，而不是自动放行。
- 合作程序或内部任务：应能对应到已登记的凭据、调用方和用途。若多项任务共用一个身份，先拆分身份，才能单独调整额度和追查异常。
- 未知自动化流量：若请求集中在少数路径、重复参数相同，或持续触发错误，可进一步检查节奏和服务器负载。任何单项特征都只能作为判断依据之一。
按路径和消耗量制定限流规则
公开的帮助文档、图片列表等可缓存内容，和需要数据库查询或实时计算的接口，承受能力并不相同。规则应细到路径或功能，并区分匿名与已认证访问；不要因为一个重负载接口异常，就把整站访问一并拦下。
| 访问类型 | 优先识别方式 | 处理思路 |
|---|---|---|
| 可缓存的公开页面 | 路径、缓存命中情况、访问节奏 | 先利用缓存减轻源站压力，再限制明显异常的突发请求。 |
| 需要计算或查询的接口 | 身份、参数、处理耗时与并发量 | 按接口设置较严格额度；必要时缩小返回结果或排队处理。 |
| 已登记的程序调用 | 独立凭据、约定用途、调用记录 | 为调用方设置单独额度，异常时先暂停对应凭据，不影响普通访客。 |
设置额度时，可先按平稳时段的请求量和资源消耗估算，再用较短窗口控制突发、较长窗口观察持续压力。比如在秒级窗口允许少量突发，在分钟级窗口约束持续请求；具体限额应结合接口耗时、缓存能力和并发上限测试，不能把某个固定请求数套用到所有网站。令牌桶适合允许短时突发、同时约束长期平均速率；固定窗口实现简单，但窗口交界处可能出现请求集中。
按步骤上线，保留恢复通道
- 先采集基线：按路径统计请求量、错误比例、响应时间和资源占用，并区分匿名访问、已认证访问及已登记程序。观察时间应覆盖业务高峰与低谷，避免拿单一时段当作常态。
- 先观察再拦截：在日志或监控中模拟规则，记录哪些请求会被限流，确认正常用户是否集中受影响。无法确定身份的流量，可先采取较温和的降速或额外校验。
- 小范围启用：先对问题最明显的路径或部分流量应用规则，监控被拒请求、成功率和服务器负载。若正常访问失败增加，立即收紧规则适用范围或回退。
- 写清例外与告警：为必要的合作调用保留独立身份和额度；设置规则变更记录、值班联系人及临时解除方式。例外也要监控，避免成为不受控的通道。
常见问题
高频访问就一定是攻击吗？
不一定。发布更新、缓存失效或正常用户集中访问都可能带来请求上升，应结合路径、身份和资源消耗判断。
能否直接按公网地址限流？
可以把地址作为辅助维度，但共享网络会让正常用户共同受限。更稳妥的做法是结合会话、账户或调用凭据，并为匿名流量设置有边界的规则。
怎样判断限流有没有误伤？
对照限流前后的成功率、被拒请求特征、用户反馈和服务器负载；若特定地区、网络或正常会话的失败明显增加，应检查规则是否过宽。
稳妥的限流不是一味封堵，而是让规则与请求来源、访问路径和实际成本相匹配。把识别、试运行和回退机制纳入流程，网站遭遇异常请求时的限流策略才能减少资源压力，同时尽量保留正常访问。
