X-Forwarded-For

HTTP 请求头中的 X-Forwarded-For

大富帅

0.3 2018.05.22 11:40* 字数 1768 阅读 21691评论 0喜欢 6赞扬 1

X-Forwarded-For和相关几个头部的理解

• $remote_addr
  是nginx与客户端进行TCP链接过程当中，得到的客户端真实地址. Remote Address 没法伪造，由于创建 TCP 链接须要三次握手，若是伪造了源 IP，没法创建 TCP 链接，更不会有后面的 HTTP 请求

• X-Real-IP
  是一个自定义头。X-Real-Ip 一般被 HTTP 代理用来表示与它产生 TCP 链接的设备 IP，这个设备多是其余代理，也多是真正的请求端。须要注意的是，X-Real-Ip 目前并不属于任何标准，代理和 Web 应用之间能够约定用任何自定义头来传递这个信息

• X-Forwarded-For
  X-Forwarded-For 是一个扩展头。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 请求到达服务器以前，通过了三个代理 Proxy一、Proxy二、Proxy3，IP 分别为 IP一、IP二、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。

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

1. 用户IP0---> 代理Proxy1（IP1），Proxy1记录用户IP0，并将请求转发个Proxy2时，带上一个Http Header
   X-Forwarded-For: IP0
2. Proxy2收到请求后读取到请求有 X-Forwarded-For: IP0，而后proxy2 继续把连接上来的proxy1 ip追加到 X-Forwarded-For 上面，构造出X-Forwarded-For: IP0, IP1，继续转发请求给Proxy 3
3. 同理，Proxy3 按照第二部构造出 X-Forwarded-For: IP0, IP1, IP2,转发给真正的服务器，好比NGINX，nginx收到了http请求，里面就是 X-Forwarded-For: IP0, IP1, IP2 这样的结果。因此Proxy 3 的IP3，不会出如今这里。
4. nginx 获取proxy3的IP 能经过$remote_address获取到，由于这个$remote_address就是真正创建TCP连接的IP，这个不能伪造，是直接产生连接的IP。$remote_address 没法伪造，由于创建 TCP 链接须要三次握手，若是伪造了源 IP，没法创建 TCP 链接，更不会有后面的 HTTP 请求。

x-forwarded-for 实践研究：

1. uwsgi_pass的状况下，nginx 没有设置proxy_pass x-forwarded-for: $proxy_add_x_forwarded_for;
   若是请求头传了XFF，在flask里面能正常读取请求头里面的XFF,就是当是一个普通的头读出；若是header不传这个XFF的话，就读不到

2. proxy_pass 状况下

• 没有传 # proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for 的话，跟上面的uwsgi_pass 同样，都是在没有设置header XFF状况下，读不到。

• 若是传了 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for， header 不传xff 的话，也是能够在程序里面读到Xff 头： X-Forwarded-For: 10.0.2.2 （这个IP就是真正连上nginx 的IP， 也就是$remote_address），由于这句proxy_set_header 会让nginx追加一个$remote_address到XFF。

• header 传xff的话， 程序里面能够读到Xff 头： X-Forwarded-For: 188.103.19.120, 10.0.2.2 （第一个是我本身编的，第二个是$remote_address），nginx仍是会由于proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for 这句而追加$remote_addr到XFF。

总结：

1. 只要nginx前端（例如lvs， varnish）转发请求给nginx的时候，带了x-forwarded-for ,那么程序就必定能读到这个字段，若是nginx还设置了proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for， 那么程序能读到XFF是：ip0, ip1 (客户端Ip，lvs或者varnishIP)。 若是nginx没有设置，那么nginx仍是会原样把http头传给程序，也就是说程序也能读到XFF，并且XFF就是ip0 客户端IP。

2. proxy_pass 设置这个头 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 是站在一个做为代理的角度把。能继续传输多级代理的头。

3. nginx的日志格式写了$http_x_forwared_for 说明前端（lvs）确实传了这个头过来。因此是程序是读取到的

4. uwsgi_pass 不能设置 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 这个头，是由于这个头是对http代理来讲，用来传递IP的，uwsgi 不可能充当一个代理。

5. nginx->程序，这里其实有两个连接过程，其余IP与nginx的TCP连接， nginx与程序的TCP连接。因此$remote_addr都是对各自来讲的。
   程序的remote_addr: remote_addr 127.0.0.1 (跟它连接的是nginx 内网127.0.0.1)
   nginx的remote_addr : X-Real-Ip: 10.0.2.2 （跟它连接的是个人电脑，IP 10.0.2.2）

6. 对程序来讲，读取的request.remote_addr 也永远是直接跟他连接的ip， 也就是反向代理nginx

7. The access_route attribute uses the X-Forwarded-Forheader, falling back to the REMOTE_ADDRWSGI variable; 也就是说access_route默认读取XFF头，若是没有，降级读取WSGI的REMOTE_ADDR变量,这个 WSGI的REMOTE_ADDR变量 就是 $remote_addr

8. request.envron 是WSGI的变量，都是wsgi server转过来的，普通的头都是加了HTTP_前缀的 ，包括proxy_set_header Host $host:8000;
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   添加的头都会出如今处理，由于他们就是普通的http头

9. LVS->nginx的状况下， 请求的时候主动加XFF，程序读取的时候没显示。由于LVS设置XFF的时候，直接把直连的IP赋值给LVS，忽略掉全部原本有的XFF，要从LVS这里开始。 因此程序读到的XFF是 ：XFF headers 218.107.55.254, 10.120.214.252
   前面的是个人IP， 后面的是LVS的IP

{
  "wsgi.multiprocess": "False", "SERVER_SOFTWARE": "Werkzeug/0.11.10", "SCRIPT_NAME": "", "REQUEST_METHOD": "GET", "PATH_INFO": "/api/get_agreement_url/", "SERVER_PROTOCOL": "HTTP/1.0", "QUERY_STRING": "", "werkzeug.server.shutdown": "<function shutdown_server at 0x7f4a2f4e5488>", "CONTENT_LENGTH": "", "SERVER_NAME": "127.0.0.1", "REMOTE_PORT": 58284, "werkzeug.request": "", "wsgi.url_scheme": "http", "SERVER_PORT": "6000", "HTTP_POSTMAN_TOKEN": "666cfd97-585b-c342-f0bd-5c785dfff27d", "wsgi.input": "", "wsgi.multithread": "False", "HTTP_CACHE_CONTROL": "no-cache", "HTTP_ACCEPT": "*/*", "wsgi.version": "(1, 0)", "wsgi.run_once": "False", "wsgi.errors": "", "CONTENT_TYPE": "", "REMOTE_ADDR": "127.0.0.1", "HTTP_CONNECTION": "close", "HTTP_USER_AGENT": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36", "HTTP_ACCEPT_LANGUAGE": "zh-CN,zh;q=0.8,en;q=0.6", "HTTP_X_FORWARDED_FOR": "10.0.2.2", "HTTP_ACCEPT_ENCODING": "gzip, deflate, sdch", "HTTP_HOST": "[test.mumu.nie.netease.com:8000](http://test.mumu.nie.netease.com:8000/)", } 

$proxy_add_x_forwarded_for; nginx的这个变量含义就是，每次都追加$remote_address 到 xff头，若是xff头不存在，那么xff就被设置成跟$remote_address 同样了。若是原本就存在，就追加了 ip1, ip2这样的形式

问题：

为何lvs-nginx ， nginx的日志记录$http_x_forwarded_for仍是能够的