要真实完整记录403请求，需移除日志过滤逻辑、增强log_format包含$request_method、$http_authorization等关键字段，并用map+if分流至独立403日志文件。

要让 access_log 真实、完整地记录所有触发 403 的请求上下文，不能只依赖默认日志——因为 Nginx 在返回 403 时，很多变量（如 $request_body）可能为空或未解析，且默认日志不区分拦截原因。关键在于：**主动捕获 + 精确匹配 + 上下文补全**。

确保 403 请求不被过滤或跳过记录

Nginx 默认会记录所有响应（包括 403），但常见配置隐患会导致漏记：

• 检查 log_format 中是否用了条件记录（如 if=$status != 403），这类排除逻辑必须移除
• 确认没有在 location 块中误配 access_log off; 或覆盖为其他日志路径而遗漏 403 场景
• 若使用了 limit_req 或 auth_request 模块拦截，需确保其内部返回的 403 仍走主日志流（默认是走的，但自定义 error_page 可能绕过）

增强日志格式，显式包含 403 关键上下文

仅记录 IP、时间、状态码远远不够。应至少加入以下字段，便于定位权限拦截根源：

• $request_method $request_uri：确认是 GET /admin/delete 还是 POST /api/user/role
• $http_authorization 或 $http_x_api_key：验证认证凭据是否存在或格式异常
• $http_x_forwarded_for：识别真实客户端 IP（尤其经代理时）
• $sent_http_content_type：确认响应体类型（如 text/plain vs application/json），辅助判断是否为 Nginx 原生 403
• $request_time $upstream_response_time：若 403 来自 upstream（如后端鉴权服务），该值通常为 0；若非 0，则可能是后端返回而非 Nginx 拦截

示例格式定义：

Web Accessibility (WCAG 2 AA))

将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。

下载

log_format blocked '[$time_local] $remote_addr "$request" $status ' '$request_time $upstream_response_time ' '"$http_user_agent" "$http_x_forwarded_for" ' 'auth:"$http_authorization" x-api:"$http_x_api_key" ' 'content_type:"$sent_http_content_type"';

单独隔离 403 日志（推荐生产环境）

避免从海量 access.log 中 grep，直接分流记录：

• 用 map 指令标记 403 请求：

map $status $log_403 { 403 1; default 0;}

• 在 server 或 location 中启用条件日志：

access_log /var/log/nginx/403-blocked.log blocked if=$log_403;

这样所有 403 都集中落盘，配合 logrotate 可按天归档，审计时直接查该文件即可。

补充说明：为什么通常不记录 $request_body？

$request_body 在 403 场景下多数为空——因为 Nginx 仅在需要读取请求体时（如做 body filter、proxy_pass、或开启 client_body_buffer_size 后实际接收）才缓存它。而权限校验常发生在请求头解析阶段（如检查 Authorization 头），此时 body 尚未读入。若确需 body，需前置启用 client_body_in_single_buffer on; 和足够 buffer，并在 location 中强制读取（如用 echo_read_request_body; 配合 echo 模块），但会带来性能开销，非必要不建议。