头部走私是通过构造含Content-Length与Transfer-Encoding冲突的HTTP请求，使前后端对消息边界解析不一致；反向代理中易导致请求拆分/合并，引发缓存污染或会话劫持。
什么是头部走私，为什么反向代理场景特别危险
头部走私（HTTP Request Smuggling）不是篡改单个Header字段，而是通过构造歧义性请求，让前端Nginx和后端应用服务器对同一段HTTP流量的“消息边界”产生不同理解。典型诱因是 Content-Length 和 Transfer-Encoding 两个头部同时存在或冲突——Nginx按一种方式切分请求体，后端按另一种方式解析，结果导致一个请求被拆成两个、或多个请求被合并成一个。
在反向代理架构中，这种不一致会被放大：攻击者发送一个精心设计的请求，Nginx认为它是一个完整请求并转发给后端；而后端却将其识别为两个独立请求，第二个请求可能“寄生”在第一个响应中返回给其他用户，造成缓存污染、会话劫持甚至账户接管。
Nginx 默认行为的风险点与关键配置原则
Nginx 本身不默认启用 Transfer-Encoding: chunked 解析（除非明确配置），但若上游使用CDN、WAF或后端开启分块编码，而Nginx未统一处理策略，就容易形成解析分歧。合规配置的核心原则是：强制标准化、禁止歧义、显式声明边界。
- 禁用不必要或易混淆的编码方式：在 proxy_pass 前清除或覆盖 Transfer-Encoding 头
- 统一以 Content-Length 为准：确保 Nginx 在转发前已准确计算并设置该头，避免后端依赖 Transfer-Encoding
- 拒绝含冲突头部的请求：用 if + return 拦截同时携带 Content-Length 和 Transfer-Encoding 的非法请求
防御性配置示例（直接可用）
以下配置应放在 location 或 server 块中，适用于标准反向代理场景：
location / {
# 拦截头部冲突请求（关键防线）
if ($http_transfer_encoding ~* "chunked|identity") {
return 400;
}
if ($http_content_length !~ "^[0-9]+$") {
return 400;
}
<pre class="brush:php;toolbar:false;"># 强制清除原始 Transfer-Encoding，防止透传
proxy_set_header Transfer-Encoding "";
# 确保 Content-Length 被正确继承或重算
proxy_http_version 1.1;
proxy_set_header Connection '';
# 后端信任的真实IP与Host信息
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://backend;}
注意：proxy_http_version 1.1 是必须项，因为 HTTP/1.0 不支持 Transfer-Encoding；proxy_set_header Connection '' 可防止 Connection: keep-alive 或 upgrade 类头部干扰解析逻辑。
配合后端协同加固的要点
仅靠 Nginx 配置不能完全杜绝走私，还需后端服务配合：
- 后端应用应拒绝任何含 Transfer-Encoding 头的请求（除非自身明确支持且严格校验）
- 禁用后端对 Content-Length 的宽松解析（如忽略超长值、自动截断等）
- 启用请求体长度硬限制，例如在 Spring Boot 中设
server.tomcat.max-http-post-size=2MB，超出即 413 - 日志中记录原始请求头组合，便于事后分析可疑走私模式
实际部署前，建议用 curl 构造典型走私载荷（如双 Content-Length、CL-TE、TE-CL 组合）进行回归测试，验证 Nginx 是否稳定返回 400 或 444。
