nginx通过提取cookie字符串、判断键值匹配实现访问控制，三种方式：①if+$http_cookie简单拦截；②auth_request委托后端鉴权（推荐生产）；③map预定义策略（高效复用）。
Nginx 本身不直接解析或验证 Cookie 的业务逻辑（比如登录态、权限等级），但它可以通过匹配 Cookie 请求头的值，结合内置指令或模块，实现轻量、高效的基于 Cookie 的身份识别与访问控制。核心思路是：**提取 Cookie 字符串 → 判断是否含指定键值 → 拒绝/重定向/透传请求**。下面分三种常用且实用的方式说明。
方式一：用 if + $http_cookie 简单拦截（适合基础校验）
适用于只需检查某个 Cookie 是否存在且值固定（如 auth_token=abc123 或 vip=true）的场景。Nginx 在 server 或 location 块中直接判断：
- 使用
$http_cookie变量获取原始 Cookie 字符串（注意大小写：Cookie 头转为小写加下划线） - 用正则匹配，例如
if ($http_cookie !~ "auth_token=abc123") { return 403; } - 若需忽略大小写或空格干扰，可写成
if ($http_cookie !~* "auth_token=[a-z0-9]+") { return 403; } - ⚠️ 注意：
if在 location 中有性能开销，不建议嵌套多层或用于高并发核心路径
方式二：用 auth_request 模块做委托鉴权（推荐生产环境）
当 Cookie 需要解密、查库、校验时效性或关联用户角色时，应交由后端服务处理。Nginx 仅作“守门人”，转发认证请求并依据响应状态码放行或拦截：
- 确保 Nginx 编译时启用了
--with-http_auth_request_module - 在受保护路径中添加
auth_request /_auth;，例如：location /admin/ { auth_request /_auth; } - 定义内部认证接口：
location = /_auth { internal; proxy_pass http://auth-service/verify; proxy_pass_request_body off; proxy_set_header Content-Length ""; proxy_set_header X-Cookie $http_cookie; } - 后端服务（如 Python/Node.js）收到请求后解析 Cookie、校验有效性，返回
200 OK表示通过，401/403表示拒绝
方式三：用 map 指令预定义访问策略（高效、可复用）
适合多路径共用同一 Cookie 规则，或需根据 Cookie 值动态设置变量（如限流标识、上游分组）：
- 在
http块中定义映射关系：map $http_cookie $allowed { default 0; ~* "session_id=[a-f0-9]{32}" 1; ~* "role=admin" 1; } - 在 location 中引用：
location /api/ { if ($allowed = 0) { return 403; } } - 优势：map 在配置加载时编译，比每次执行 if 更快；支持正则、默认值、多条件覆盖
- 注意：map 不支持嵌套逻辑（如 AND/OR 组合），复杂判断仍需后端
实际部署时，建议优先采用方式二（auth_request），它把业务逻辑下沉，Nginx 保持无状态、高性能；方式一和三适合运维快速上线或灰度控制。所有方案都依赖 Cookie 正确携带（前端需设 SameSite=None; Secure 跨域场景，且后端设置域名一致），否则 $http_cookie 将为空。
