保护敏感API需“限流+封禁”双管齐下：基于请求速率实时限流（如IP级登录限5次/分钟）、动态IP黑名单（5分钟3次401/403即封15分钟）、身份与网络层联合校验（JWT+设备指纹+mTLS），并辅以灰度发布、可观测监控及真实载荷回归验证。
保护敏感API接口，核心是“限流+封禁”双管齐下：既要防突发流量压垮服务，也要阻断恶意IP反复试探或爆破。关键不在堆砌工具，而在策略分层、指标可测、响应及时。
基于请求速率的实时限流（QPS/并发数）
对登录、密码重置、短信发送等高风险接口，必须按IP或用户维度做细粒度限流。推荐用Redis+Lua原子脚本实现滑动窗口计数，避免多实例间计数不一致。
- 单IP每分钟最多5次登录尝试，超限返回429并记录日志
- 全局短信接口每秒不超过100次调用，使用令牌桶平滑突发流量
- 后端网关（如Nginx、Spring Cloud Gateway）配置fallback逻辑：限流触发时返回统一JSON错误，不暴露后端状态
动态IP黑名单与自动封禁机制
静态白/黑名单只能应对已知威胁，真正有效的是基于行为自动升降级。将WAF日志、API网关访问日志、业务异常日志（如连续失败的鉴权）统一接入实时分析管道。
- 同一IP 5分钟内触发3次401/403且无合法Token，自动加入临时黑名单（15分钟）
- 命中SQL注入或路径遍历规则的请求，立即写入永久黑名单表，并同步至边缘节点（如CDN或OpenResty）
- 提供管理接口支持手动解封，所有封禁操作留痕，含来源、原因、操作人、生效时间
身份凭证与网络层联合校验
仅靠IP控制易被代理绕过，需叠加业务身份信号。例如：登录接口要求同时满足“IP未封禁 + JWT有效 + 设备指纹匹配历史登录设备（可选）”。
- 敏感操作（如转账、删库）强制二次验证，且验证Token绑定发起IP与User-Agent
- 内部服务调用走内网地址+双向mTLS，公网入口一律禁止直连后端服务
- 对高频低价值请求（如健康检查、埋点上报），在负载均衡层剥离并路由到独立集群，避免挤占核心API资源
监控告警与策略灰度发布
限流和封禁策略上线前必须可灰度、可观测、可回滚。所有策略变更应走配置中心（如Apollo、Nacos），而非硬编码或重启生效。
- 核心指标看板至少包含：各接口QPS、限流触发次数、黑名单IP数量、封禁命中率、误杀率（如白名单IP被误封）
- 设置分级告警：限流率突增50%发企业微信提醒；单IP被封禁超100次触发P1工单
- 新封禁规则先对1%流量生效，持续观察2小时无异常再全量推送
不复杂但容易忽略：每次安全策略调整后，务必用真实攻击载荷（如Burp Suite重放+IP轮换）做回归验证，而不是只测“正常流程”。
