Nginx访问策略是否生效需三方面交叉验证：一是请求响应状态（如403/401/502），二是错误日志中SSL_do_handshake()或certificate verify failed等关键记录，三是响应头或access_log中策略执行痕迹（如X-Auth-Status、$ssl_client_verify）。
校验 Nginx 访问策略是否生效，关键在于“验证行为是否按预期触发”，而不是只看配置语法正确。需结合请求发起、响应状态、日志输出三方面交叉确认。
检查基础访问控制（IP 或基础认证）是否起作用
对 allow/deny 或 auth_basic 类策略，最直接的验证方式是模拟受限与放行两类请求：
- 用 curl 或浏览器从被
deny的 IP（如 192.168.1.100）访问受控路径，应返回 403 Forbidden - 从被
allow的网段（如 10.0.0.0/8）访问同一路径，应正常返回内容或跳转到登录框 - 启用
auth_basic后，未带认证头访问应返回 401 Unauthorized，且响应头含WWW-Authenticate: Basic realm="xxx" - 用正确用户名密码请求（
curl -u user:pass https://site/private），应能成功获取响应
验证客户端证书校验（mTLS 路径级控制）是否真正拦截
针对 /api/secure/ 等强制校验路径，需分三类测试：
- 不带客户端证书访问：应返回 403（由
if ($ssl_client_verify != "SUCCESS") { return 403; }触发） - 携带无效或过期证书访问：同样返回 403，且错误页中可显示自定义提示（如配置了
return 403 "Client certificate required and valid";） - 携带有效证书访问：Nginx 日志中应出现
$ssl_client_s_dn信息（可通过log_format加入），且后端能收到X-Client-DN头
确认 upstream 证书校验（proxy_ssl_verify）是否真实生效
开启 proxy_ssl_verify on 后，不能仅凭服务启动无报错就认为已生效。必须主动触发失败场景：
- 临时将后端 HTTPS 服务证书替换为自签名证书（或修改
proxy_ssl_name为不匹配值），此时访问对应location应立即返回 502 Bad Gateway - 查看 Nginx 错误日志（
error_log），应有类似SSL_do_handshake() failed或certificate verify failed的记录 - 若关闭
proxy_ssl_verify后该 502 消失，即可反向确认校验机制原本在工作
借助日志和响应头快速定位策略执行点
在关键 location 中添加调试信息，让策略“可见”：
- 用
add_header X-Auth-Status "$ssl_client_verify";暴露证书校验结果（仅限测试环境） - 在
log_format中加入$status $http_authorization $ssl_client_s_dn，便于从 access_log 查看每次请求的实际鉴权结果 - 对
auth_request模块，可在子请求 location 中加add_header X-Auth-Subreq "hit";，确认是否真进入了鉴权流程
