一概述

反向代理（Reverse Proxy）方式是指以代理服务器来接受Internet上的连接请求，然后将请求转发给内部网络上的服务器；并将从服务器上得到的结果返回给Internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。

通常的代理服务器，只用于代理内部网络对Internet的连接请求，客户机必须指定代理服务器,并将本来要直接发送到Web服务器上的http请求发送到代理服务器中。当一个代理服务器能够代理外部网络上的主机，访问内部网络时，这种代理服务的方式称为反向代理服务。

图1 反向代理服务器的基本原理

二反向代理服务器的工作原理

反向代理服务器通常有两种模型，它可以作为内容服务器的替身，也可以作为内容服务器集群的负载均衡器。

1，作内容服务器的替身

如果您的内容服务器具有必须保持安全的敏感信息，如信用卡号数据库，可在防火墙外部设置一个代理服务器作为内容服务器的替身。当外部客户机尝试访问内容服务器时，会将其送到代理服务器。实际内容位于内容服务器上，在防火墙内部受到安全保护。代理服务器位于防火墙外部，在客户机看来就像是内容服务器。

当客户机向站点提出请求时，请求将转到代理服务器。然后，代理服务器通过防火墙中的特定通路，将客户机的请求发送到内容服务器。内容服务器再通过该通道将结果回传给代理服务器。代理服务器将检索到的信息发送给客户机，好像代理服务器就是实际的内容服务器（参见图 2）。如果内容服务器返回错误消息，代理服务器会先行截取该消息并更改标头中列出的任何 URL，然后再将消息发送给客户机。如此可防止外部客户机获取内部内容服务器的重定向 URL。

这样，代理服务器就在安全数据库和可能的恶意攻击之间提供了又一道屏障。与有权访问整个数据库的情况相对比，就算是侥幸攻击成功，作恶者充其量也仅限于访问单个事务中所涉及的信息。未经授权的用户无法访问到真正的内容服务器，因为防火墙通路只允许代理服务器有权进行访问。

图2 反向代理服务器作为内容服务器的替身

可以配置防火墙路由器，使其只允许特定端口上的特定服务器（在本例中为其所分配端口上的代理服务器）有权通过防火墙进行访问，而不允许其他任何机器进出。

2，作为内容服务器的负载均衡器

可以在一个组织内使用多个代理服务器来平衡各 Web 服务器间的网络负载。在此模型中，可以利用代理服务器的高速缓存特性，创建一个用于负载平衡的服务器池。此时，代理服务器可以位于防火墙的任意一侧。如果 Web 服务器每天都会接收大量的请求，则可以使用代理服务器分担 Web 服务器的负载并提高网络访问效率。

对于客户机发往真正服务器的请求，代理服务器起着中间调停者的作用。代理服务器会将所请求的文档存入高速缓存。如果有不止一个代理服务器，DNS 可以采用“循环复用法”选择其 IP 地址，随机地为请求选择路由。客户机每次都使用同一个 URL，但请求所采取的路由每次都可能经过不同的代理服务器。

可以使用多个代理服务器来处理对一个高用量内容服务器的请求，这样做的好处是内容服务器可以处理更高的负载，并且比其独自工作时更有效率。在初始启动期间，代理服务器首次从内容服务器检索文档，此后，对内容服务器的请求数会大大下降。

图3 反向代理服务器作为负载均衡器

适用于windows主机首先说一下，IIS6略古老，想做反向代理也基本没戏，所以我就用IIS7.5和IIS8.5说事吧！windows server2008 iis7 利用ApplicationRequest Routing实现二级目录反向代理。

先介绍下什么是反向代理？指以代理服务器来接受Internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给Internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。我们可以通过反向代理实现负载平衡、突破防火墙限制等一些非常实用的Web服务器功能，目前反向代理不管在私有云还是公有云的虚拟机上用的很多很多。

第一步：下载安装ARR（Application Request Routing）， http://www.iis.net/downloads/microsoft/application-request-routing：下载、安装过程很简单!

第二步，简要设置ARR，配置应用程序请求路由缓存，安装完成后，IIS里会多出两个图标，分别是Application Request Routing和URL重写。2.0版本（也就是2008或者Win7系统）需要双击ApplicationRequest Routing以后，在右侧Server Proxy Settings里，将代理功能开启，而Win8以后的版本自己默认就开启了：

iis二级目录泛解析反向代理(包含泛目录)

1、设置proxy

iis二级目录泛解析反向代理(包含泛目录)

2、启动proxy

iis二级目录泛解析反向代理(包含泛目录)

应用即可

第三步，设置反向代理：

ARR基本设置好了以后，需要进入一个IIS上搭建好的网站进行URL重写配置，

第2页 /(共5页)

方法一、修改或者创建网站根目录Web.config有则修改无则创建，内容如下栏目和域名为参数根据自己的需求修改即可

<?XML version="1.0" encoding="UTF-8"?>

<system.webServer>

<files>

</files>

</defaultDocument>

<rules>

</conditions>

</rule>

</rules>

</rewrite>

</system.webServer>

</configuration>

本次测试配置的情况,简单起见,只在iis中测试,配置3个网站,第一个”LevenWeb”,使用80端口提供服务,第二个”levenblog”,下面运行着levenblog2.0.9,使用8080端口,第三个”phpweb”,下面有一个”test.php”的phpinfo页面(iis7 php配置本文不再详述),本机ip:192.168.1.8,为了测试,我们先进行域名绑定,也就是在leven.com.cn下新增3个子域名,域名绑定如下图所示:

我们的目标如下:

http://phpweb.leven.com.cn/ 访问phpweb站点,也就是http://localhost:8081/

http://levenblog.leven.com.cn/ 访问levenblog站点,也就是http://localhost:8080/

http://realblog.leven.com.cn/ 访问公网上的levenblog站点,也就是http://leven.com.cn/

http://localhost/leven 访问levenblog站点,也就是http://leven.com.cn/

首先前往http://www.iis.net/extensions/ApplicationRequestRouting下载Application Request Routing,然后安装,本次实践使用的是V2版.

安装完毕之后,新建3个站点:

然后找到ARR配置菜单:

开启Proxy项:

然后在levenweb站点下配置反向代理路由,配置可以使用UI界面或者直接修改web.config的模式,本次配置给出ui和config文件两种方式,个人更喜欢config配置文件模式.

进入该项,先配置第一项, http://phpweb.leven.com.cn/ 访问phpweb站点,也就是http://localhost:8081/,选择”Add Rules...”:

然后选择”Blank Rule”

然后填写如下:

该参数设置表面ARR将拦截所有请求

继续在”Conditions”中选择”Add”:

该设置表面只有HTTP_HOST为phpweb.leven.com.cn的URL才能通过该规则,如果您绑定了多个域名,可以根据多次增加或者通过正则表达式的|来间隔

最后在下面的Action中配置代理路径:

在这儿,{R:1}代表了MatchUrl中的第一个匹配括号

同样配置的web.config文件如下:

测试访问http://phpweb.leven.com.cn/test.php,结果如下:

下面同样可以配置levenblog.leven.com.cn和realblog.leven.com.cn

Ui界面配置不再说明,配置完成的web.config如下:

访问结果分别为:

和

我们再添加最后一项,将http://localhost/leven 代理到 http://leven.com.cn/

但是此时访问会出现问题,如下图:

显然,出现了CSS丢失等情况,通过查看源码:

可以看到css的路径有误,不仅如此,所有的img,a标签路径全部出现了错误,代理之后的地址是/leven/xxx的,但是源地址仍然是/xxx,因此我们还需要增加一个Outbound Rule

配置好的config文件如下:

然后刷新:

可见路径正确.

在使用了反向代理之后,编程上也有些地方需要注意了,在取客户端IP的时候,由于多了一层代理,直接是无法获取的,因此,我们需要开启

然后通过获取Header中的X-Forworded-For字段来取得客户端IP

从测试来看,ARR是个非常有用的代理模块,能完全满足我们反向代理的需求,不仅如此,ARR还提供了UrlRewrite,ServerFarms,Cache等很多功能,很是值得我们挖掘.

Nginx配置二级目录/路径映射不同的反向代理和规避IP+端口访问

当配置Nginx来映射不同的服务器可以通过二级路径来反向代理来解决一个外网端口实现多个服务访问。

配置如下：

server {
        listen 80;
        server_name demo.domain.com;
        #通过访问service二级目录来访问后台
    location /service/ {
            #DemoBackend1后面的斜杠是一个关键，没有斜杠的话就会传递service到后端节点导致404
            proxy_pass      http://backend1/;            proxy_redirect  off;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
        #其他路径默认访问前台网站
        location / {
            proxy_pass http://backend2;            proxy_redirect  off;
            proxy_set_header  Host  $host;
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }

#简单的负载均衡节点配置
upstream backend1 {
     server 192.168.1.1;
     server 192.168.1.2;
     ip_hash;
 }
upstream backend2 {
     server 192.168.2.1;
     server 192.168.2.2;
     ip_hash;
}

对于规避IP+端口访问，可能粗略一看，还没理解是个啥意思吧！

其实就是现在业界流行的一种防DNS污染的解决方案之一：手机APP里面除了通过域名来获取数据，还会额外嵌入一些备用的IP。APP在获取数据时，会先通过域名向服务器发起一个简单的校验请求，如果得到的不是预期数据，说明该网络环境下的DNS已被污染，比如被运营商劫持，请求A内容却给你展示B内容！这时候，APP将会启动备用预案，通过IP的方式来请求数据！很明显，这个做法可以有效避免恶心的DNS劫持了（看完这段是不是有所收获呢？）。

做法很简单，就是在APP中集成多个IP和端口作为备用的访问途径。

当开发GG找到我，提出的需求是：

需要实现公网IP+端口来访问，比如邮件API使用 http://192.168.1.10:125

Ps：公网服务器是多线的，那么就有多个IP，本文假设电信是192.168.1.10，联通是192.168.2.10，移动是192.168.3.10等

说白了就是要用端口来区分不同的API，此时如果我不深究，顺手可能会写出如下配置：

Shell

#API1
server {
        listen 125;
        server_name 192.168.1.10 192.168.2.10 192.168.3.10;
        location / {
            proxy_pass      http://DemoBackend;            proxy_redirect  off;
            proxy_set_header   Host  api1.domain.com;
            proxy_set_header   X-Real-IP   $remote_addr;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}
#API2
server {
        listen 126;
        server_name 192.168.1.1 192.168.2.1 192.168.3.1;
        location / {
            proxy_pass      http://DemoBackend;            proxy_redirect  off;
            proxy_set_header   Host  api2.domain.com;
            proxy_set_header   X-Real-IP   $remote_addr;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}
##API n等等....

粗略一看，确实是可以实现开发GG的要求啊！再仔细一想，你会发现如此做法会开放越来越多的端口！运维成本以及辨识度低还只是其次，咱说好的安全第一呢？

经过思考和测试，我写出的最终配置如下：

Shell

#新增的IP映射配置
server {
        listen 80;
        server_name 192.168.1.10 192.168.2.10 192.168.3.10;
        location /mail_api/ {
            proxy_pass      http://DemoBackend/; #后面的斜杠不能少，作用是不往后端传递/mail-api 这个路径            proxy_redirect  off;
            proxy_set_header  Host  mailapi.domain.com; #传递不同的host给后方节点，实现IP和域名均可以访问
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        }
        location /other_api1/ {
            proxy_pass      http://DemoBackend/;             proxy_redirect  off;
            proxy_set_header  Host  otherapi1.domain.com;
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        }
        #还可以添加更多映射，通过不同的路径来映射不同的API，最后对于直接访问IP则返回403，防网络上的扫码探测
    location / {
        return 403;
    }
}

#原有的域名映射
server {
     listen 80;
     server_name mailapi.domain.com;
     location / {
        proxy_pass      http://DemoBackend;            proxy_redirect  off;
            proxy_set_header  Host  $host;
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}
server {
     listen 80;
     server_name otherapi1.domain.com;
     location / {
        proxy_pass      http://DemoBackend;            proxy_redirect  off;
            proxy_set_header  Host  $host;
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}
#简单的节点配置（当这些API都用到同一个Backend时，上述代码中的proxy_set_header传递的host就起到了关键性作用！）
upstream DemoBackend {
     server 192.168.10.1;
     server 192.168.10.2;
     ip_hash;
 }

最终实现的效果就是：你要通过IP请求邮件API，只要请求 http://192.168.1.1/mail_api/ 即可，而不需要开放多余端口。而且，后续要新增更多API，只需要定义不同的二级路径即可，这些二级路径的辨识度可比端口要好得多！

Ps：正如代码中的注释，示例代码只用了一个 DemoBackend 节点配置，为的是分享另一个小技巧：当后端节点承载了多个站点而且都是监听80端口时（比如某些小公司同一个IIS服务器部署了N个站点），反向代理中的proxy_set_header参数，可以自定义传递一个host域名给后端节点，从而正确响应预期内容！

这段解释有点无力，还是拿实际例子举例吧！

我之前供职的公司节点用的是IIS服务器，前端用Nginx反向代理，IIS服务器上有多个站点，站点之间部分会通过 rewrite 规则联系起来。

打个比方：比如A网站有个专题内容（www.a.com/zt/）是通过IIS伪静态映射到了B网站(content.b.com)。也就是访问到http://www.a.com/zt/，其实最后是通过A网站映射到了B网站上面。

后来发现IIS有个伪静态BUG，会经常奔溃，就要我用前端的Nginx来实现直接映射，而不再走IIS的A网站中转。

那么这个需求就正好用到了 proxy_set_header 技巧，一看就懂：

Shell
server {
     listen 80;
     server_name www.a.com;
     location /zt/ {
        proxy_pass      http://ABackend; #都是相同的节点，此示例代码我就不写upstream了            proxy_redirect  off;
            proxy_set_header  Host www.b.com; #这里就是关键性作用，传递b域名给后端IIS
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

#upstream略..