Varnish(前)+Nginx(中)时,让Apache(后)获取用户真实IP(多重代理)

不得不说我有点问题，网站一个Apache+Varnish不够，还要在Apache和Varnish之间插入个第三者——Nginx。

因为某些需要，也给该服务器上的个别网站上了CDN。
Apache做后端，前面多一个Nginx Proxy Cache+Varnish，获取用户的真实IP不难，只需给Apache上一个rpaf模块就行了，然后让Varnish处理XFF的内容就好了：

     if (req.restarts == 0) {
       if (req.http.x-forwarded-for) {
           set req.http.X-Forwarded-For =
               req.http.X-Forwarded-For + ", " + client.ip;
       } else {
           set req.http.X-Forwarded-For = client.ip;
       }
     }

if (req.restarts == 0) {

if (req.http.x-forwarded-for) {

set req.http.X-Forwarded-For =

req.http.X-Forwarded-For + ", " + client.ip;

} else {

set req.http.X-Forwarded-For = client.ip;

}

无CDN的情况下访问网站，可以正确获取到用户的真实IP。

最近给网站上多了一个CDN，rpaf模块就显得无能为力了。因此，这几天一直苦恼如何让我的网站获取用户真实IP。
问了下那家CDN的客服，给了我这个回答：
当使用CDN后，网站服务器访问日志中的IP地址都将记录为CDN服务器的官方IP。您可以通过下列方式获取访问用户的原始IP：
ASP
Request.ServerVariables(“HTTP_X_FORWARDED_FOR”)
PHP
$_SERVER[“HTTP_X_FORWARDED_FOR”]
JSP
request.getHeader(“HTTP_X_FORWARDED_FOR”)

似乎是要我修改我的网站的代码吧，不过这指标不治本，况且Ioncube加密后的，修改是没什么可能的了，问他们能否修改Nginx配置文件实现，不理我了……

看来还是得靠自己。他们既然能把那些代码发来，就证明他们的cdn服务器把真实IP存放在了HTTP_X_FORWARD_FOR里面，那么让nginx处理一下CDN服务器发来的xff的内容就行了了。

首先，取消Varnish处理XFF，把CDN传输的XFF直接交给Nginx处理，也就是注释掉以下内容：

#     if (req.restarts == 0) {
#       if (req.http.x-forwarded-for) {
#           set req.http.X-Forwarded-For =
#               req.http.X-Forwarded-For + ", " + client.ip;
#       } else {
#           set req.http.X-Forwarded-For = client.ip;
#       }
#     }

# if (req.restarts == 0) {

# if (req.http.x-forwarded-for) {

# set req.http.X-Forwarded-For =

# req.http.X-Forwarded-For + ", " + client.ip;

# } else {

# set req.http.X-Forwarded-For = client.ip;

# }

然后在nginx的对应域名的setver层的location /层加进一行代码：

proxy_set_header    X-Forwarded-For $http_x_forwarded_for;

1	proxy_set_header X-Forwarded-For $http_x_forwarded_for;

重启Nginx，打开探针看了看，终于正常了……

Tags: cache, CDN, IP, nginx, proxy, Varnish, 真实, 获取

3 Comments

Comments are closed.

You might also like:

Unix Like, 操作系统, 网络

Linux IPv4 forward自动丢弃源IP为系统已绑定的IP的问题

A是路由，其上做了策略，一部分符合特定条件的流量，是要转发到B进行封装处理，A和B之间做了数个VLAN，B根据VLAN应用不同的策略。不过这里的问题是，B的默认网关也是A（环路问题是不存在的，已经有对应规则处理），所以B自身发出的流量也会由A应用策略，转发回给B自己。而B收到src IP是local IP（系统已绑定的IP）的包时，kernel会直接丢弃数据包，所以除了B自己的数据包，B都能正常封装。解决这个问题的一个方法，是让A在把数据包转发给B前，做一次SNAT，这样B收到的数据包，src IP就是A的IP了。其实SNAT并没有什么影响，A对NAT也有hardware offload， […]

运营维护

使用Varnish Cache时，让Nginx获取访客真实IP

之前发表过一篇文章：Varnish(前)+Nginx(中)时,让Apache(后)获取用户真实IP(多重代理) 该方法能成功解决使用或者不使用CDN时，在Varnish前端，Nginx中端，Apache解析PHP文件的情况下让Apache获取访客真实IP。因为当时主要是利用Nginx进行缓存，没使用其他功能，旧没让Nginx也获取访客真实的IP。其中Varnish处理XFF的关键代码：

     if (req.restarts == 0) {
        if (req.http.x-forwarded-for) {
#           set req.http.X-Forwarded-For =
#               req.http.X-Forwarded-For + ", " + client.ip;
        } else {
            set req.http.X-Forwarded-For = client.ip;
        }
     }

if (req.restarts == 0) {

if (req.http.x-forwarded-for) {

# set req.http.X-Forwarded-For =

# req.http.X-Forwarded-For + ", " + client.ip;

} else {

set req.http.X-Forwarded-For = client.ip;

}

也就是把客户的IP赋值给XFF。那样后端处理就方便多了。昨天在为一台Varnish+Nginx+Apache的服务器添加并测试防轻量级CC的 […]

一个高频率的HTTP服务监控Shell Script

Nginx/Apache之类的长期运行，无法保证在遇到各种突发情况进程不会死掉。如果这时候又出门在外，一时间无法操作，那网站岂不是要宕机数个小时？明显我无法接受这事情。于是一个简简单单的监控HTTP服务的Shell Script就出来了。

#!/bin/bash
#函数restart
restart() {
#重启Nginx
service nginx restart
#重启Apache
service httpd restart
}
#循环的开始
while [ "$loop" = "" ]
do
#延迟五秒
sleep 5
#是否能下载，是则进入下一步循环，否则执行restart
wget -O /dev/null http://你的网站地址 -t 1 || restart
done

#!/bin/bash

#函数restart

restart() {

#重启Nginx

service nginx restart

#重启Apache

service httpd restart

}

#循环的开始

while [ "$loop" = "" ]

#延迟五秒

sleep 5

#是否能下载，是则进入下一步循环，否则执行restart

wget -O /dev/null http://你的网站地址 -t 1 || restart

done

真的简简单单。可见我并没有采用cron功能，毕竟这东西正常情况最低频率只能一分钟了。 restart那个function是http服务不正常后执行的，可以自行增添，删减，替换。sleep后面跟着的是秒数，在这里简单理解成监控频率吧。wget处，-t参数指的是尝试次数，这里我写了一次。执行 […]

Nginx ssl_preread传递客户端IP

ssl_preread是基于L4的反代方案，TLS SNI握手时客户端会提供域名，所以可以让Nginx在无需完成TLS握手的情况下，就根据域名进行后端服务器的选择。简单来讲，你只需要给后端服务器配置一个SSL证书，而提供反代功能的Nginx则无需配置。文档见此：http://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html 因为这是L4反代，所以通过“proxy_set_header”传递客户端IP的方法是行不通的。其实传递客户端IP的解决办法跟上一篇文章类似：L4(传输层)IP透明反向代理的实现(传递客户端真实IP)，ng […]