$sent_http_location 能准确记录重定向最终目标地址，因其反映 Nginx 处理后（含 proxy_redirect 修正）实际发送给客户端的 Location 值，满足等保2.0与GDPR对操作可追溯和数据流向透明的审计要求。
要通过 log_format 记录重定向跳转的最终目标地址（即 Location 响应头），从而支撑安全审计与合规检查，关键在于捕获后端返回的 Location 头内容，并确保它在日志中稳定、可解析、不被代理层覆盖或丢失。
为什么 $sent_http_location 能反映真实重定向行为
该变量由 Nginx 提供，表示**实际发送给客户端的响应头中 Location 字段的值**（注意是 sent_，不是 upstream_http_）。它区别于：
-
$upstream_http_location：仅记录后端原始返回的Location，未经过 Nginx 重写（如proxy_redirect）； -
$sent_http_location：已包含所有 Nginx 层处理后的结果——包括proxy_redirect替换、协议/域名修正、路径前缀补全等。这才是浏览器最终收到并执行跳转的地址。
对等保2.0“操作可追溯”、GDPR“数据流向透明”等要求而言，记录这个最终生效的跳转目标，比记录后端原始地址更具审计价值。
正确配置 log_format 包含 $sent_http_location
在 http 或 server 块中定义日志格式，显式加入该变量：
log_format audit_log '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$sent_http_location" ' # ← 关键字段
'$request_time $upstream_response_time';
然后启用该格式：
access_log /var/log/nginx/audit.log audit_log;
注意：$sent_http_location 在非 3xx 响应中为空字符串，日志中会显示为 "-" 或空引号，不影响解析。
确保 $sent_http_location 可靠记录的必要条件
该变量是否有效，取决于 Nginx 是否真正发出了带 Location 的响应。需确认以下几点：
- 后端服务确实返回了 301/302/307 等状态码，并携带
Location头； - Nginx 未用
return或rewrite ... redirect指令覆盖重定向逻辑（这些场景下$sent_http_location仍有效，但来源是 Nginx 自身生成，非后端）； - 若使用
proxy_redirect，其规则必须匹配并成功重写原始Location，否则$sent_http_location将保留内网地址（此时虽记录了，但内容不合规）； - 避免在
location块中误配add_header Location ...，这会导致重复或冲突的Location头，Nginx 行为不可控。
配合审计分析的关键建议
单有字段不够，需结构化使用：
- 将日志输出为 JSON 格式（借助
log_format中嵌入 JSON 键名），便于 SIEM 工具提取redirect_target字段做聚合分析； - 对高风险跳转（如跳向外部域名、含敏感参数的 URL）设置日志过滤告警，例如用
map指令标记异常$sent_http_location； - 结合
$request_id和$upstream_http_x_request_id，将重定向日志与后端业务日志关联，验证跳转是否符合预期流程（如登录后跳/dashboard，而非/admin）； - 定期校验日志中 3xx 响应占比及目标域名分布，识别未授权跳转或开放重定向漏洞。
