Nginx反向代理层可提前拦截非法Token请求，通过map解析Authorization头并生成$invalid_token变量，再用if或auth_request实现轻量级鉴权。
直接在 Nginx 反向代理层拦截非法 Token 请求，比后端鉴权更早、更轻量。核心思路是：用 map 提前解析请求头中的 Token，结合正则匹配规则，生成布尔型变量；再通过 if + return 或 auth_request 机制实现动态拦截。
提取并映射 Token 字段
map 指令适合做无副作用的键值转换，不能直接用于条件跳转，但可将复杂逻辑“降维”为简单变量。例如从 Authorization 头中提取 Bearer Token，并判断是否符合预期格式：
map $http_authorization $invalid_token {
default 1;
~*^Bearer\s+([a-zA-Z0-9_\-]{20,})$ 0;
"" 1;
}
说明：
– 第一行匹配任意非空但不符合 Bearer 格式（如缺失空格、Token 过短、含非法字符）的 Authorization 头，标记为 1（无效）；
– 第二行用正则捕获合法 Token（长度 ≥20，仅含常见 JWT 字符），标记为 0（有效）；
– 第三行处理空头或缺失头，也视为无效。
配合 if 实现快速拦截
map 本身不执行动作，需搭配 if 使用。注意：if 在 location 块内才安全，避免在 server 级别滥用：
location /api/ {
if ($invalid_token) {
return 401 "Unauthorized: Invalid or missing token";
}
proxy_pass http://backend;
proxy_set_header Authorization $http_authorization;
}
关键点：
– 返回状态码必须明确（如 401），不能只写字符串；
– 不建议在 if 中调用 proxy_pass，否则可能绕过拦截；
– 若需透传 Token 给后端，保留 proxy_set_header 即可，无需解码或校验签名（那是后端职责）。
进阶：对接外部鉴权服务（auth_request）
当 Token 需实时校验有效性（如查黑名单、验过期时间），可将 map 作为预筛层，再用 auth_request 转发到独立鉴权服务：
- 先用
map快速过滤明显非法格式（节省下游压力）； - 对格式合法的请求，交由
auth_request /auth子请求验证； - 子请求返回 200 才放行，否则返回 401/403；
- 这样既保持 Nginx 层轻量，又支持动态策略（如 Redis 黑名单、OAuth introspection）。
避坑提醒
Nginx 的 map 和 if 组合容易误用，务必注意：
– map 变量在请求初始化阶段计算，无法访问 body 或动态上下文；
– if 内部不支持 break、set 等多数指令，仅限有限动作（return、rewrite、proxy_pass）；
– Token 若经 Base64 URL 安全编码（如 JWT），正则需适配 [a-zA-Z0-9_\-]，而非标准 Base64 字符集；
– 测试时用 curl -H "Authorization: Bearer xxx" 验证各分支，特别检查空头、错误前缀（如 “Basic xxx”）、超长 Token 等边界情况。
