后端服务能否正确识别客户端真实信息，关键在于nginx是否准确设置、过滤和信任请求头；需显式配置x-real-ip、x-forwarded-for、host、x-forwarded-proto等头部，并针对http、websocket、grpc等协议差异化处理，同时规避host丢失、xff重复、大请求头被拒等常见陷阱。
直接用 Nginx 做反向代理时，后端服务能否正确识别客户端真实信息、协议类型和原始路径，关键不在转发本身，而在于请求头是否被准确设置、过滤和信任。默认行为往往不够安全或不满足业务逻辑，需针对性优化。
必须显式设置的关键请求头
默认情况下，Nginx 不会自动添加 X-Real-IP、X-Forwarded-For 等标识性头部，后端若直接读取 remote_addr，拿到的只是 Nginx 本机 IP。应在 proxy_pass 所在 location 或 upstream 上游块中统一配置：
-
Host 头：用
proxy_set_header Host $host$host_port;（nginx-proxy 模板写法）或更稳妥的proxy_set_header Host $http_host;，保留原始 Host，避免后端因 Host 错误返回 404 或重定向异常 -
客户端真实 IP：设
proxy_set_header X-Real-IP $remote_addr;；若经多层代理，用proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;追加而非覆盖 -
协议与端口**：设
proxy_set_header X-Forwarded-Proto $scheme;（比硬编码 https/http 更可靠），proxy_set_header X-Forwarded-Port $server_port;
需要谨慎处理的敏感头部
某些头部若未经校验直接透传，可能被恶意构造，导致后端逻辑被绕过或信息泄露：
-
Connection 和 Upgrade 头：WebSocket 场景必须显式设置
proxy_http_version 1.1;、proxy_set_header Upgrade $http_upgrade;、proxy_set_header Connection "upgrade";，否则连接降级为 HTTP/1.0，长连接失败 -
Proxy 头：始终设
proxy_set_header Proxy "";清空，防止 httpoxy 类攻击 - 下游伪造风险头：如 nginx-proxy 中 TRUST_DOWNSTREAM_PROXY=true 时，会无条件信任客户端发来的 X-Forwarded-Proto/Host/Port。生产环境建议设为 false，并在 Nginx 层通过 map 或 if 判断可信来源后再赋值
适配不同后端协议的头部策略
后端是 HTTP、HTTPS 还是 WebSocket，头部需求差异明显：
- 普通 HTTP/HTTPS 后端：重点保障 X-Forwarded-* 系列完整、Host 正确、Cookie 和 Authorization 等业务头默认透传（Nginx 默认即传递）
-
WebSocket 后端：除上述外，必须禁用缓冲（
proxy_buffering off;）、关闭重试（proxy_next_upstream off;），并确保 Upgrade/Connection 头严格匹配 -
gRPC 后端（HTTP/2）：需启用
proxy_http_version 2.0;，且不能设 Connection、Upgrade 等 HTTP/1.1 特有头，否则连接拒绝
避免常见头部陷阱
几个高频出错点，直接影响负载均衡效果和后端行为：
-
Host 头丢失或错误：若 proxy_pass 后 URL 带域名（如
proxy_pass http://backend.example.com;），Nginx 默认用该域名覆写 Host；应改用 upstream 名称或显式设 Host 头 -
X-Forwarded-For 被重复追加：多个 Nginx 层级嵌套时，若每层都用
$proxy_add_x_forwarded_for，会导致 IP 链过长甚至被后端截断；可考虑只在最外层做追加，内层直接透传 -
大请求头触发 400 错误：当 Cookie 或自定义头超长，需调大
client_header_buffer_size（如 2k）和large_client_header_buffers（如 4 8k），否则 Nginx 直接拒收
