Nginx 通过拦截后端返回的状态码（如401、403）并配合error_page、proxy_intercept_errors、响应头判断及日志审计实现敏感接口保护，而非直接依赖状态码本身。
在 Nginx 中，状态码拦截本身不是直接“保护敏感接口”的手段，而是配合后端响应、反向代理和错误处理机制，实现对异常或非法访问的快速识别与阻断。真正起保护作用的是：基于后端返回的状态码（如 401、403、500），由 Nginx 主动拦截、重定向、日志记录或拒绝透传。关键在于把状态码作为决策信号，而非被动透传。
用 error_page 拦截并重定义敏感响应
当后端对未授权访问返回 401 或 403 时，Nginx 可拦截并统一处理，避免暴露后端细节或跳转逻辑泄露：
- 开启 proxy_intercept_errors on：这是前提，否则 Nginx 默认透传后端错误页，不触发 error_page
- 用 error_page 401 =302 /login 将未登录请求重定向到登录页（=302 表示重置状态码为 302）
- 对管理类接口，可返回统一 JSON 提示：error_page 403 = @forbidden，再定义 location @forbidden { return 403 '{"code":403,"msg":"禁止访问"}'; }
- 慎用 error_page 500 502 503 504 = @backend_error 避免把后端故障伪装成业务拒绝，影响排查
结合 proxy_pass 响应头做条件拦截
后端可在响应头中主动标记敏感操作结果（如 X-Auth-Required: true、X-Risk-Level: high），Nginx 利用 add_header 和 if 判断做动态拦截：
- 在 proxy_pass 后添加 proxy_pass_request_headers on（默认开启），确保响应头能被后续指令读取
- 用 if ($upstream_http_x_auth_required = "true") { return 401; } 实现“后端声明需鉴权，Nginx 立即拦截”
- 配合 map $upstream_http_x_risk_level $block { "high" 1; default 0; } + if ($block) { return 403; }，支持分级风控
- 注意：if 在 location 中可用，但不能嵌套，且仅支持有限变量（$upstream_http_* 是安全可用的）
拦截失败认证并防止凭证泄露
当后端返回 401 且含敏感信息（如 WWW-Authenticate 头或调试堆栈），Nginx 应剥离或覆盖响应内容：
- 用 proxy_hide_header WWW-Authenticate 防止暴露认证机制类型（Basic/Bearer/JWT）
- 用 proxy_set_header Authorization "" 清空上游可能透传的原始 token（避免日志或中间件误用）
- 对含敏感 body 的 5xx 错误，用 proxy_intercept_errors on + 自定义 error_page 返回精简提示，避免堆栈泄漏
- 启用 server_tokens off，隐藏 Nginx 版本，减少指纹暴露面
日志联动：让状态码成为审计线索
单纯拦截不够，需通过日志关联请求上下文，支撑事后追溯：
- 自定义 log_format，加入 $status（响应状态码）、$upstream_status（后端真实状态）、$http_authorization（脱敏后）、$request_time
- 对返回 401/403 的请求，单独写入 audit.log：access_log /var/log/nginx/audit.log main if=$blocked;（配合 set $blocked "1" 触发）
- 用 limit_req_log_level warn 把限流触发（常伴随 429）也记为 warning，与认证失败日志交叉分析
- 避免在 access_log 中记录 $request_body（性能与隐私风险），敏感操作日志应由后端生成并推送 SIEM
