最直接、安全的方式是用proxy_set_header HeaderName "";原生删除请求头，Nginx 会彻底省略该字段而非传空值；它仅作用于发往后端的请求头，与处理响应头的proxy_hide_header本质不同。
最直接、安全的方式是在 proxy_set_header 指令中将目标请求头赋值为双引号包围的空字符串 ""，Nginx 会将其识别为“删除该头”，而非传递一个空值字段。
为什么空字符串是首选方式
这是 Nginx 原生支持的行为，无需额外模块或编译选项。只要写法正确（必须带双引号），Nginx 在构造发往后端的请求时，会彻底省略该 Header 字段——不是传一个空值，而是不出现该行，从协议层面移除。
- 语法必须是
proxy_set_header X-Forwarded-For "";，不能写成proxy_set_header X-Forwarded-For;（语法错误）或proxy_set_header X-Forwarded-For " ";（会传一个空格） - 该操作仅影响**Nginx 发送给后端的请求头**，不影响客户端到 Nginx 的原始请求
- 它和
proxy_hide_header完全不同：proxy_hide_header处理的是后端返回给 Nginx、再由 Nginx 返回给客户端的响应头
哪些 Header 适合用空值删除
重点清理那些易伪造、无业务依赖、可能暴露信息或干扰逻辑的字段：
- X-Forwarded-For：单层可信代理下无需透传，避免 IP 伪造链污染
- Authorization：防止后端误用客户端 Token 或 Basic 凭据，尤其在聚合网关或静态资源代理场景
- User-Agent：后端不需识别终端类型时，统一抹除可降低指纹攻击面
- Origin：CORS 由 Nginx 统一控制时，不应信任客户端随意提交的 Origin
- Proxy-Connection / Connection / Keep-Alive：Nginx 已管理连接生命周期，透传可能干扰复用
典型配置示例
放在 location 或 server 块中，且必须位于 proxy_pass 之前：
location /api/ {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For "";
proxy_set_header Authorization "";
proxy_set_header User-Agent "";
proxy_set_header Origin "";
}
注意：多个 proxy_set_header 指令顺序无关紧要，但同名指令以最后出现的为准；若某 Header 被多次设置，只有最后一个生效。
验证是否真正删除
关键看后端实际收到的请求中该字段是否**完全缺失**，而非显示为空：
- 在后端服务日志中打印原始请求头（如 Python Flask 的
request.headers），确认目标 Header 不在字典中 - 用
tcpdump -i lo -A port 8000 | grep "X-Forwarded-For:"抓包，对应行应不出现 - 临时加一句
add_header X-Debug-Auth "$http_authorization";（仅调试），响应头里值为空字符串或未出现，说明客户端原始值已被屏蔽
