X-Accel-Redirect 不会出现在客户端响应头或常规 access log 中，因其是 Nginx 内部指令且默认被 proxy_hide_header 屏蔽；确认是否触发需查 error log、用 $sent_http_x_accel_redirect 变量调试、观察文件服务行为或抓包验证。
X-Accel-Redirect 本身不会出现在客户端收到的响应头中，也不会直接记录在 Nginx 的常规 access log 里——它是一个内部指令，只对 Nginx 自身生效，且默认被屏蔽出最终响应。
为什么日志里看不到 X-Accel-Redirect
Nginx 默认会过滤掉所有以 X-Accel- 开头的响应头，防止后端误传或泄露内部路径信息。这是由 proxy_hide_header X-Accel-*（或隐式默认行为）控制的。
即使后端（如 Python/Java/PHP）设置了：
response.setHeader("X-Accel-Redirect", "/protected/report.pdf");
Nginx 在代理返回给用户前，会主动移除该 header。所以你在浏览器开发者工具或 curl -I 中永远看不到它。
如何确认 X-Accel-Redirect 是否真正触发
不能靠查响应头，而应通过以下方式交叉验证：
-
检查 Nginx error log：若配置了
internallocation 但被外部直接访问，会记 404 或 403；若重定向成功，通常无错误，但可加debug日志级别临时排查流程 -
启用自定义日志变量：在 log_format 中加入
$sent_http_x_accel_redirect—— 这个变量会记录后端实际设置的原始值（仅限调试，生产慎用） - 观察文件服务行为：比如访问 /download?id=123，后端返回 X-Accel-Redirect 后，Nginx 应从磁盘读取对应文件并返回 200，Content-Length 正确，且不经过后端再次读文件；若后端反而开始流式输出大文件，说明重定向未生效
- 抓包看真实响应体来源：用 tcpdump 或 Wireshark 抓 Nginx 到客户端的流量，确认响应体是 Nginx 直接 sendfile 发出的（无后端进程参与 I/O），而非后端拼接返回
常见失效原因与日志线索
当预期走 X-Accel-Redirect 却没生效时，典型表现是后端完整读取并输出文件（CPU/内存升高、响应延迟明显）。可查：
-
location 路径不匹配：后端返回的
X-Accel-Redirect: /files/a.pdf，但 Nginx 中定义的是location /protected/ { internal; alias /data/; }→ 不匹配则忽略，回退到后端输出 -
缺少 internal 指令：对应 location 未加
internal;，Nginx 会当作普通请求处理，可能 403 或直接暴露路径 -
alias 与 root 混用导致路径解析错误：例如
alias /data/;+ 返回/files/a.pdf→ 实际查找/data/files/a.pdf；若用root /data;，则变成/data/files/a.pdf—— 差一个层级就 404 - 后端未正确结束响应：比如 Java 中 setHeader 后忘了 return，或 PHP 中 header() 后仍有 echo，会导致 Nginx 收到不完整响应而放弃解析 X-Accel-Redirect
安全提示：别依赖日志记录原始值
虽然 $sent_http_x_accel_redirect 可用于调试，但切勿在生产 access log 中长期记录它——里面可能含敏感路径、文件名或临时 token。权限校验逻辑应在后端完成，Nginx 只负责高效投递，日志只需记录「谁、何时、下载了什么（脱敏 ID）、状态码、字节数」即可。
