Nginx反向代理中X-Forwarded-For与X-Real-IP的区别

两个头都是代理场景下用来传递客户端IP的自定义请求头，但设计逻辑和存储格式完全不同：

• X-Real-IP
  没有统一的强制标准，设计目标是存储单个IP值。Nginx中配置proxy_set_header X-Real-IP $remote_addr时，传给后端的值就是和当前Nginx节点直接建立TCP连接的对端IP，不会做任何拼接、追加操作。
• X-Forwarded-For（简称XFF）
  是多层代理链路下传递客户端IP的事实标准，值为逗号分隔的IP列表，按顺序记录请求经过的每一层代理的上一跳IP。Nginx的$proxy_add_x_forwarded_for变量逻辑为：

  如果入站请求本身携带XFF头，就把当前$remote_addr追加到原有XFF值的末尾；如果入站请求没有XFF头，就直接把$remote_addr作为XFF的初始值。

举个实际链路例子就能直观看出区别：
假设真实用户IP为1.1.1.1，请求链路为「用户 → CDN节点(2.2.2.2) → 你的Nginx反向代理(3.3.3.3) → 后端服务」：

1. 用户请求到CDN时无XFF头，CDN按规则设置XFF为1.1.1.1，X-Real-IP为1.1.1.1，转发给你的Nginx
2. 你的Nginx收到请求时，直连对端是CDN节点IP2.2.2.2，也就是$remote_addr的值为2.2.2.2
   • 如果按题目中的配置写X-Real-IP $remote_addr，传给后端的X-Real-IP值是2.2.2.2，是CDN的节点IP而非用户真实IP
   • 如果配置X-Forwarded-For $proxy_add_x_forwarded_for，传给后端的XFF值为1.1.1.1, 2.2.2.2，列表最左侧的就是最初发起请求的用户真实IP

是否同时配置完全取决于后端服务的兼容逻辑，没有强制要求：

• 很多老旧Web服务、早期框架没有实现XFF列表解析逻辑，只会读取X-Real-IP头拿客户端IP，这种场景就需要配置该头做兼容
• 目前大部分新的Web框架、网关组件默认支持解析XFF头，但需要提前配置信任的代理IP段，否则会存在头伪造风险
• 如果Nginx前面还有CDN、云负载均衡这类上层代理，不要直接写X-Real-IP $remote_addr，否则传给后端的是上层代理的IP，正确做法是透传上层代理设置好的X-Real-IP，对应配置为proxy_set_header X-Real-IP $http_x_real_ip;
• 如果Nginx直接暴露在公网、前面没有任何代理层，两个头传给后端的值完全一致，都是真实用户IP，配任意一个或者同时配都不会有问题。

注意：不管用哪个头获取客户端IP，只要服务不是直接对公网暴露，一定要在后端配置信任的代理IP白名单，否则恶意用户可以自行伪造请求头，传递虚假IP绕过校验。

内容的提问来源于stack exchange，提问作者lonix