client_body_in_file_only 仅控制请求体是否强制写入临时文件，与请求头调试无关；调试请求头需用 logformat 记录 $http* 变量、tcpdump 抓包或配合 error_log debug。
直接启用 client_body_in_file_only 并不能用于“调试请求头”，它只影响请求体（即上传的文件内容）的处理方式，与请求头（如 Content-Type、Content-Disposition、自定义 header 等）完全无关。想调试复杂的文件上传请求头，需配合其他 Nginx 指令和外部工具，而非依赖该参数本身。
理解 client_body_in_file_only 的真实作用
该指令控制 Nginx 是否强制将整个请求体写入临时文件（即使很小），取值为 on、off 或 clean：
-
on：总是存为文件，不进内存；适合大文件或需后端读取磁盘路径的场景 -
off（默认）：小请求体走内存，大请求体才落盘 -
clean：存文件，且请求处理完自动删除
⚠️ 它不解析、不记录、不透传任何请求头，也不改变 header 的可见性。调试 header 必须另寻方法。
真正有效的请求头调试方法
要查看客户端发送的完整原始请求头（尤其是分块上传、带签名、多部分边界等复杂场景），推荐以下组合方案：
-
启用 Nginx 请求日志记录 header：在
log_format中添加$http_*变量，例如：log_format debug '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_content_type" "$http_content_disposition" "$http_x_signature"';
再在access_log中使用该格式 -
用 $request_body 记录请求体（谨慎）：仅限开发环境，需同时设
client_body_buffer_size和client_max_body_size合理值，并开启log_subrequest on（若含子请求）。注意：$request_body在非POST/PUT或 body 被读取后为空，不可靠 -
抓包验证（最可靠）：在 Nginx 机器上用
tcpdump抓 HTTP 流量，再用 Wireshark 或ngrep过滤，可看到原始字节级 header 和 boundary
配合 client_body_in_file_only 的实用调试技巧
虽然它不处理 header，但在调试大文件上传流程时，可借助其行为辅助定位问题：
- 设
client_body_in_file_only clean+client_body_temp_path /tmp/nginx-body 1 2;，然后监听/tmp/nginx-body目录变化，确认文件是否生成、大小是否匹配、是否被及时清理 - 结合
error_log /var/log/nginx/debug.log notice;和debug_connection（需编译含 debug 日志模块），可输出更细粒度的 body 处理日志，包括临时文件路径 - 若后端需要原始文件路径（如 FastCGI 的
CONTENT_LENGTH不足时），可通过fastcgi_param REQUEST_BODY_FILE $request_body_file;透传——此时client_body_in_file_only on是前提
常见误区提醒
避免把以下操作误当作 header 调试手段：
- 以为设置
client_body_in_file_only on后，Nginx 日志会自动打印所有 header —— 不会，必须显式配置$http_* - 试图用
$request_body打印 multipart boundary 行 —— boundary 在 header 里（Content-Type: multipart/form-data; boundary=xxx），不在 body 中 - 忽略客户端实际发送的 header 与 Nginx 接收到的差异 —— 比如反向代理、CDN、浏览器自动添加的 header，需在最前端（如 tcpdump）确认原始请求
