一般来说，X-Forwarded-For是用于记录代理信息的，每经过一级代理(匿名代理除外)，代理服务器都会把这次请求的来源IP追加在X-Forwarded-For中。
X-Forwarded-For
通过名字就知道，X-Forwarded-For 是一个 HTTP 扩展头部。HTTP/1.1（RFC 2616）协议并没有对它的定义，它最开始是由 Squid 这个缓存代理软件引入，用来表示 HTTP 请求端真实 IP。如今它已经成为事实上的标准，被各大 HTTP 代理、负载均衡等转发服务广泛使用，并被写入 RFC 7239（Forwarded HTTP Extension）标准之中。
X-Forwarded-For 请求头格式非常简单，就这样：
X-Forwarded-For: client, proxy1, proxy2
可以看到，XFF 的内容由「英文逗号 + 空格」隔开的多个部分组成，最开始的是离服务端最远的设备 IP，然后是每一级代理设备的 IP。
如果一个 HTTP 请求到达服务器之前，经过了三个代理 Proxy1、Proxy2、Proxy3，IP 分别为 IP1、IP2、IP3，用户真实 IP 为 IP0，那么按照 XFF 标准，服务端最终会收到以下信息：
X-Forwarded-For: IP0, IP1, IP2
Proxy3 直连服务器，它会给 XFF 追加 IP2，表示它是在帮 Proxy2 转发请求。列表中并没有 IP3，IP3 可以在服务端通过 Remote Address 字段获得。我们知道 HTTP 连接基于 TCP 连接，HTTP 协议中没有 IP 的概念，Remote Address 来自 TCP 连接，表示与服务端建立 TCP 连接的设备 IP，在这个例子里就是 IP3。
Remote Address 无法伪造，因为建立 TCP 连接需要三次握手，如果伪造了源 IP，无法建立 TCP 连接，更不会有后面的 HTTP 请求。不同语言获取 Remote Address 的方式不一样，例如 php 是 $_SERVER[“REMOTE_ADDR”]。
说明
- 直接对外提供服务的 Web 应用，在进行与安全有关的操作时，只能通过
Remote Address 获取 IP，不能相信任何请求头；
- 使用 Nginx 等 Web Server 进行反向代理的 Web 应用，在配置正确的前提下，要用
X-Forwarded-For 最后一节 或 X-Real-IP 来获取 IP（因为 Remote Address 得到的是 Nginx 所在服务器的内网 IP）；同时还应该禁止 Web 应用直接对外提供服务；
- 在与安全无关的场景，例如通过 IP 显示所在地天气，可以从
X-Forwarded-For 靠前的位置获取 IP，但是需要校验 IP 格式合法性；
示例
例如，来自4.4.4.4的一个请求，header包含这样一行
X-Forwarded-For: 1.1.1.1,2.2.2.2,3.3.3.3
代表 请求由1.1.1.1发出，经过三层代理，第一层是2.2.2.2，第二层是3.3.3.3，而本次请求的来源IP4.4.4.4是第三层代理，而X-Real-IP，没有相关标准，上面的例子，如果配置了X-Read-IP，可能会有两种情况
// 最后一跳是正向代理，可能会保留真实客户端IP
X-Real-IP: 1.1.1.1
// 最后一跳是反向代理，比如Nginx，一般会是与之直接连接的客户端IP
X-Real-IP: 3.3.3.3
所以 ，如果只有一层代理，这两个头的值就是一样的。
一般使用 X-Forwarded-For：
- 他在正向(如squid)反向(如nginx)代理中都是标准用法，而正向代理中是没有x-real-ip相关的标准的，也就是说，如果用户访问你的 nginx反向代理之前，还经过了一层正向代理，你即使在nginx中配置了x-real-ip，取到的也只是正向代理的IP而不是客户端真实IP
- 大部分nginx反向代理配置文章中都没有推荐加上x-real-ip ，而只有x-forwarded-for，因此更通用的做法自然是取x-forwarded-for
- 多级代理很少见，只有一级代理的情况下二者是等效的
- 如果有多级代理，x-forwarded-for效果是大于x-real-ip的，可以记录完整的代理链路
按照HTTP 请求头中的 X-Forwarded-For这篇文章的例子，如果在Nginx的反向代理中添加了配置proxy_set_header X-Real-IP $remote_addr，X-Real-IP的值为3.3.3.3