Nginx可通过map指令结合limit_req实现按Token或用户ID的伪动态限流：先提取标识（如X-User-ID），再映射为分组键（如vip/common），最后关联不同rate的limit_req_zone，支持分级限流与突发控制。
Nginx 本身不直接支持按 Token 或用户 ID 动态限流，但可以通过 map 指令结合 limit_req 实现“伪动态”限流：把 Token 或用户 ID 映射为一个限流 key，再用该 key 关联到不同的限流区域（limit_req_zone），从而实现差异化速率控制。
提取 Token 或用户 ID 作为限流标识
通常 Token 存在请求头（如 Authorization: Bearer xxx）或查询参数（?token=xxx）中；用户 ID 可能来自 JWT 解析、后端透传 Header（如 X-User-ID）或 Cookie。Nginx 无法解析 JWT，所以推荐由上游服务（如网关）提前解析并注入可信 Header：
- 让认证服务验证 Token 后，把
user_id写入X-User-ID头部，Nginx 直接信任该头 - 若必须从 Authorization 提取，可用正则粗略匹配（不推荐用于生产敏感场景）：
map $http_authorization $uid_from_auth {<br> ~^Bearer\s+([a-zA-Z0-9\-_]{1,})$ $1;<br> default "anonymous";<br>}
用 map 将不同用户映射到不同限流策略
核心思路：用 map 把原始标识（如 user_id）转换成“限流分组名”，再让 limit_req_zone 基于该分组名定义不同速率。例如区分 VIP 和普通用户：
map $http_x_user_id $limit_key {
# VIP 用户（ID 列表可扩展为外部文件或 Redis，但 Nginx 原生不支持运行时查 Redis）
~^(1001|1002|2005)$ "vip";
default "common";
}
<p>limit_req_zone $limit_key zone=vip_common:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=ip_base:10m rate=5r/s;这样，VIP 用户走 vip_common 区域（10r/s），其他人走同一区域但实际共享配额；若需完全隔离，可定义多个 zone：
-
limit_req_zone $http_x_user_id zone=user_1001:1m rate=20r/s;→ 针对单个用户（内存开销大，慎用） -
limit_req_zone $limit_key zone=by_tier:10m rate=10r/s;→ 按等级分组，更实用
在 location 中应用限流并处理拒绝逻辑
使用 limit_req 引用对应 zone，并设置突发容量和拒绝行为：
location /api/ {
limit_req zone=by_tier burst=20 nodelay;
limit_req_status 429;
proxy_pass http://backend;
}-
burst=20允许短时突发，配合nodelay立即响应（否则排队等待） -
limit_req_status 429统一返回 429 Too Many Requests，便于前端识别 - 注意：同一个
$limit_key值的所有请求共享该 zone 的计数器，因此分组逻辑必须稳定（如 user_id 不变、VIP 标识不漂移）
进阶：结合 geo 或 external file 实现更灵活分组
如果 VIP 用户列表较大，不建议硬编码在 map 中。可行替代方案：
- 用
geo指令加载 IP 段或用户 ID 段（需定期 reload 配置）：geo $user_tier {<br> include /etc/nginx/conf.d/vip_ids.conf; # 每行 "1001 1;"<br> default 0;<br>}<br>map $user_tier $limit_key {<br> 1 "vip";<br> 0 "common";<br>} - 通过 Lua（OpenResty）调用 Redis 实时查用户权限，再 set $limit_key —— 这才是真正动态，但已超出纯 Nginx 范围
纯 Nginx 场景下，“动态”本质是配置级动态：靠 reload 加载新 map 规则，适合变更不频繁的分级策略。
