Azure托管.NET Core服务如何限制单用户请求频率防脚本刷接口

完全可以实现按登录用户维度的每秒请求数限制，针对已登录用户携带合法认证Token发起高频恶意请求拖慢服务的场景，有以下几类可落地的实现方案：

方案1：使用.NET Core内置速率限制中间件（代码层实现） #

• 适用于.NET 7及以上版本，无需额外引入第三方付费服务，直接在服务代码中配置即可
• 核心注意点是限流中间件必须放在UseAuthentication()、UseAuthorization()之后注册，保证执行限流逻辑时已经完成身份认证，可以从HttpContext.User中提取经过服务端校验的用户唯一标识（比如JWT中的sub/oid声明、用户主键ID）作为分区键，为每个用户配置独立的限流策略
• 常用策略可选令牌桶限流、固定窗口限流，比如配置单用户每秒最多允许10次请求，突发请求上限不超过20次，超出阈值直接返回429 Too Many Requests状态码
• 单实例部署时用内置内存存储计数即可，如果是多实例横向部署，需要替换内置的内存计数存储为分布式存储，避免不同实例计数不统一导致限流失效

方案2：使用Azure网关层服务限流（低代码侵入） #

这类方案的限流逻辑在流量到达后端服务之前执行，性能损耗最低，基本不需要改动现有业务代码：

• Azure API Management（APIM）：在APIM的入站策略中配置按键速率限制规则，APIM会先校验请求携带JWT的合法性，再直接从Token中提取用户标识作为计数键，可灵活配置单用户每秒请求阈值、超限响应规则，也支持针对不同接口、不同用户角色设置差异化限流阈值
• Azure Front Door WAF/应用程序网关WAF：如果服务已经用Front Door或者应用网关做公网流量入口，可以直接在WAF中自定义速率限制规则，通过匹配Authorization头的JWT声明提取用户ID作为限流维度，在边缘节点直接拦截超限请求，不需要回源到后端服务

方案3：基于Azure Redis的自定义分布式限流 #

• 如果需要高度自定义的限流规则（比如不同用户等级对应不同阈值、动态调整限流规则、结合风控规则临时封禁恶意用户），可以基于Azure Redis Cache实现分布式限流
• 实现逻辑简单可控：编写一个自定义中间件，请求经过认证后提取用户ID，用Redis的INCR命令对「用户ID+当前时间窗口」组成的键做原子递增，首次写入时设置1秒的过期时间，当计数值超过设定阈值时直接返回429响应
• 因为Redis是多实例共享的全局存储，不管后端服务扩多少个实例，计数都是全局统一的，不会出现多实例部署下限流不准的问题

落地注意事项 #

• 所有限流用的用户标识必须从服务端验证过的认证凭证中提取，绝对不能直接使用前端传参里的用户ID、用户名等字段，防止恶意用户篡改标识绕开限流
• 触发限流时务必在响应头中加入Retry-After字段，告知客户端允许再次发起请求的等待时间
• 限流阈值要提前结合业务场景压测，给正常用户操作留足冗余，比如避免把用户连续点击提交、页面批量加载接口的正常行为误拦截
• 建议配套限流日志监控，对频繁触发限流的用户做额外的风控校验，比如临时限制访问、要求二次验证等

内容的提问来源于stack exchange，提问作者Juan Andres solanas