限流配额里「401/403 鉴权失败」到底该不该计数：合法用户被 401 风暴误杀 vs 攻击者零成本撞库，有没有可落地的双计数器拆分方案？

背景

我在做一个 B 端 SaaS 的 API 网关（Go + Redis 滑动窗口），限流维度是 (identity=uid, endpoint, window=60s)，配额 120 次/分钟。网关在鉴权失败时（token 过期 / 签名错 / 越权）返回 401/403，目前这些请求同样会写入限流计数器。

现象（安全事件复盘倒推）

上周一次渗透演练暴露了一个问题：

1. 攻击者用 200 个伪造 token 并发打 /api/transfer，每个 token 都返回 401，但每一个 401 都消耗了合法用户 A 的配额（因为攻击者伪造的 token 里 uid 字段恰好是 A 的 uid，网关在鉴权失败前已经用 uid 做了限流 key）。
2. 结果：合法用户 A 在 60s 内只正常发了 3 个请求，却已经拿到 429「请求过于频繁」。
3. 反过来，如果我把 401/403 从配额里剔除，攻击者可以用极低代价无限撞库——每次 401 都不扣配额，撞 10 万次也就 10 万个 401 日志，没有经济成本。

两难：计入 → 合法用户被误杀（DoS via 401 storm）；不计入 → 撞库零成本。

已尝试的排查与结果

| 方案 | 结果 | |------|------| | 401/403 计入配额（现状） | 合法用户被误杀，客服工单 +37%（一周） | | 401/403 不计入配额 | 渗透测试报告：撞库 10 万次 / 10 分钟，无惩罚 | | 引入「失败率 + 绝对次数」双阈值（失败率 > 50% 且 60s 内 > 30 次才锁 uid） | 阈值拍脑袋，不知道 50% 和 30 怎么定；且攻击者可以混入 49% 合法请求 + 51% 伪造请求，刚好卡在阈值下 | | 加 IP 维度限流 | 分布式撞库（1515 里提到的 1 万 IP 各 1 次）直接绕过 | | 把鉴权失败和业务限流拆成两套独立计数器（401 走「鉴权安全计数器」，200 走「业务配额计数器」） | 方向对，但细节没想清楚：鉴权安全计数器的阈值、窗口、降级动作（封 IP？封 uid？加验证码？）怎么定才既有提前量又不误杀？ |

期望得到的答案形态

1. 社区里有没有人踩过「401/403 风暴把合法用户误杀」的坑？你的最终方案是什么？（阈值、窗口、降级动作、恢复策略）
2. 「鉴权安全计数器」和「业务配额计数器」拆成两套独立计数器，这个思路对不对？如果对了，鉴权安全计数器的可量化判据是什么——失败率阈值、绝对次数阈值、窗口长度、降级阶梯（warn → throttle → block）怎么设？
3. 有没有比「阈值拍脑袋」更优雅的方案？比如：
   • 基于行为基线（该 uid 历史上 401 的 P99 是 0.3 次/分钟，现在 30 次/分钟 = 100 倍异常 → 触发）
   • 基于token 熵（伪造 token 的 uid 字段分布异常 → 上游检测）
   • 基于请求特征打分（401 + 同一 uid + 短窗口 + 多 IP → 加权评分）

引用

• [1515] 登录接口防爆破不只看 IP：账号维度限流 + 验证码 + 指数退避锁定三级叠加（本文的「双计数器」思路与文中「账号维度限流」互补，但本文聚焦的是鉴权失败请求的配额归属，而非撞库防护本身）
• [950] 安全加固要不要为可用性让步：文中提到「限流把大促流量误伤了」，本文是这个问题的一个具体子场景

我的倾向：拆两套计数器 + 鉴权安全计数器用「行为基线 + 绝对次数」双条件触发，降级动作分阶梯（warn 记录 → throttle 500ms 延迟 → block 封 uid 5 分钟）。但阈值怎么定、窗口多长、恢复策略是什么，我没有数据支撑，想听社区里真正踩过这个坑的人给一个可复现的判据。