HTTP 请求头中的 X-Forwarded-For

X-Forwarded-For请求头格式非常简单，就这样：

可以看到，XFF 的内容由「英文逗号 + 空格」隔开的多个部分组成，最开始的是离服务端最远的设备 IP，然后是每一级代理设备的 IP。

如果一个 HTTP 请求到达服务器之前，经过了三个代理 Proxy1、Proxy2、Proxy3，IP 分别为 IP1、IP2、IP3，用户真实 IP 为 IP0，那么按照 XFF 标准，服务端最终会收到以下信息：

Proxy3 直连服务器，它会给 XFF 追加 IP2，表示它是在帮 Proxy2 转发请求。列表中并没有 IP3，IP3 可以在服务端通过 remote_address 来自 TCP 连接，表示与服务端建立 TCP 连接的设备 IP，在这个例子里就是 IP3。

详细分析一下，这样的结果是经过这样的流程而形成的：

总结：

remote_address 到 xff头，如果xff头不存在，那么xff就被设置成跟$remote_address 一样了。如果本来就存在，就追加了 ip1, ip2这样的形式

问题：

Full Cone （完全锥型）NAT：所有来自同一个内部Tuple X的请求均被NAT转换至同一个外部Tuple Y，而不管这些请求是不是属于同一个应用或者是多个应用的。

除此之外，当X-Y的转换关系建立之后，任意外部主机均可随时将Y中的地址和端口作为目标地址和目标端口，向内部主机发送UDP报文，由于对外部请求的来源无任何限制，因此这种方式虽然足够简单，但却不那么安全。

在此类型NAT后面的终端C向服务器S发起连接时，NAT会为C分配一个端口p，并将p与C绑定映射关系。此后，无论请求是否来自S，只要是发送到p端口的，NAT都会将其转发给C。

扩展资料

NAT，即网络地址转换，可以让多台上网设备共享一个IP。它的原理大概是：当一个封装了私有IP和端口的数据包经过NAT，NAT就会把私有IP和端口映射成公有IP和端口，然后重新封包再转发出去

同时NAT也会记录源私有地址与源公有地址以及目的地址这三个的映射关系，当目的地址回包时，NAT查找以前的记录，转换成私有地址。

事实上，大部分的上网设备都处在NAT之后，而我们照样上网不误。进一步说，用户的请求到达服务器，其源IP与端口是经NAT转换后的公有IP与端口，服务器回包是往NAT的公有IP发送，最后可以顺利到达NAT后面的上网设备。这就说明，数据包可以直接发往NAT转换后的公有地址。

参考资料：百度百科 - NAT

---