共计 4764 个字符，预计需要花费 12 分钟才能阅读完成。
本节索引
- 场景分析
- 正向代理
- 反向代理
- ProxyPass 与 ProxyPassServer
- 搭建实验环境
- 测试分析
- 本篇小结
场景分析
通常的代理服务器，只用于代理内部网络对 Internet 的连接请求，客户机必须指定代理服务器, 并将本来要直接发送到 Web 服务器上的 http 请求发送到代理服务器中。由于外部网络上的主机并不会配置并使用这个代理服务器，普通代理服务器也被设计为在 Internet 上搜寻多个不确定的服务器, 而不是针对 Internet 上多个客户机的请求访问某一个固定的服务器，因此 普通的 Web 代理服务器不支持外部对内部网络的访问请求 。 当一个代理服务器能够代理外部网络上的主机，访问内部网络时，这种代理服务的方式称为反向代理服务 。此时代理服务器对外就表现为一个 Web 服务器，外部网络就可以简单把它当作一个标准的 Web 服务器而不需要特定的配置。不同之处在于， 这个服务器没有保存任何网页的真实数据，所有的静态网页或者 CGI 程序，都保存在内部的 Web 服务器上 。 因此对反向代理服务器的攻击并不会使得网页信息遭到破坏，这样就增强了 Web 服务器的安全性。
反向代理方式和包过滤方式或普通代理方式并无冲突，因此可以在防火墙设备中同时使用这两种方式，其中反向代理用于外部网络访问内部网络时使用，正向代理或包过滤方式用于拒绝其他外部访问方式并提供内部网络对外部网络的访问能力。因此可以 结合这些方式提供最佳的安全访问方式。
正向代理
正向代理主要是将内网的访问请求通过代理服务器转发访问并返回结果。通常客户端无法直接访问外部的 web, 需要在客户端所在的网络内架设一台代理服务器, 客户端通过代理服务器访问外部的 web，需要在客户端的浏览器中设置代理服务器。一般由两个使用场景；
场景 1 ：局域网的代理服务器；
场景 2 ：访问某个受限网络的代理服务器，如访问某些国外网站。正向代理的原理图如下：
反向代理
客户端能访问外部的 web, 但是不能访问某些局域网中的 web 站点，此时我们需要目标网络中的一台主机做反向代理服务器来充当我们的访问目标，将局域网内部的 web 等站点资源缓存到代理服务器上，, 客户端直接访问代理就像访问目标 web 一样 (此代理对客户端透明, 即客户端不用做如何设置, 并不知道实际访问的只是代理而已, 以为就是访问的目标) 一般使用场景是：
场景1：idc 的某台目标机器只对内开放 web, 外部的客户端要访问, 就让另一台机器做 proxy, 外部直接访问 proxy 即相当于访问目标；
场景 2 ：idc 的目标机器的某个特殊的 web 服务工作在非正常端口如 8080, 而防火墙上只对外开放了 80, 此时可在 80 上做 proxy 映射到 8080, 外部访问 80 即相当于 8080。方向代理的原理图如下：
ProxyPass 与 ProxyPassServer
apache 中的 mod_proxy 模块主要作用就是进行 url 的转发，即具有代理的功能。应用此功能，可以很方便的实现同 tomcat 等应用服务器的整合，甚者可以很方便的实现 web 集群的功能。
1 ProxyPass
语法：ProxyPass [path] !|url
说明：它主要是用作 URL 前缀匹配，不能有正则表达式，它里面配置的 Path 实际上是一个虚拟的路径，在反向代理到后端的 url 后，path 是不会带过去的，使用示例：
1）ProxyPass / images/ ! 这个示例表示，/images/ 的请求不被转发。
2）ProxyPass /mirror/foo/ http://backend.example.com/ 我们假设当前的服务地址是 http://example.com/，如果我们做下面这样的请求：http://example.com/mirror/foo/bar 那将被转成内部请求：http://backend.example.com/bar
注意：配置的时候，不需要被转发的请求，要配置在需要被转发的请求前面。
2 ProxyPassMatch
语法：ProxyPassMatch [regex] !|url
说明：这个实际上是url 正则匹配，而不是简单的前缀匹配，匹配上的 regex 部分是会带到后端的 url 的，这个是与 ProxyPass 不同的。使用示例：
1）ProxyPassMatch ^/images ! 这个示例表示对 /images 的请求，都不会被转发。
2）ProxyPassMatch ^(/.*.gif) http://www.linuxidc.com 这个示例表示对所有 gif 图片的请求，都被会转到后端，如此时请求 http://example.com/foo/bar.gif，那内部将会转换为这样的请求 http://http://www.linuxidc.com/admin/bar.gif。
3 ProxyPassReverse
语法：ProxyPassReverse [路径] url
说明：它一般和ProxyPass 指令配合使用，此指令使 Apache 调整 HTTP 重定向应答中 Location, Content-Location, URI 头里的 URL，这样可以避免在 Apache 作为反向代理使用时。后端服务器的 HTTP 重定向造成的绕过反向代理的问题。参看下面的例子：
ProxyPass /Hadoop http://www.linuxidc.com/
ProxyPassReverse /hadoop http://www.linuxidc.com/
实验环境搭建
上面介绍了 ProxyPass 与 ProxyPassServer 以及 ProxyPassMatch 的基础用法，下面详解向大家解释他们的工作原理。
ProxyPass 很好理解，就是把所有来自 客户端对 http://www.linuxidc.com 的请求转发给 http://172.18.234.54 上进行处理。ProxyPassReverse 的配置总是和 ProxyPass 一致，但用途很让人费解。似乎去掉它很能很好的工作，事实真的是这样么，其实不然，如果响应中有重定向，ProxyPassReverse 就派上用场。
ProxyPassReverse 工作原理 ：假设用户访问http://www.linuxidc.com/index.html.txt，通过转发交给 http://172.18.234.54 /index.html.txt 处理，假定 index.html.txt 处理的结果是实现 redirect 到 inde2.txt(使用相对路径, 即省略了域名信息)，如果没有配置反向代理，客户端收到的请求响应是重定向操作，并且重定向目的 url 为 http://172.18.234.54/inde2.txt，而这个地址只是代理服务器能访问到的，可想而知，客户端肯定是打不开的，反之如果配置了反向代理，则会在 转交 HTTP 重定向应答到客户端之前调整它为 http://www.linuxidc.com/inde2.txt，即是在原请求之后追加上了 redirect 的路径。当客户端再次请求 http: //www.linuxidc.com/inde2.txt，代理服务器再次工作把其转发到 http://172.18.234.54/inde2.txt。客户端到服务器称之为正向代理，那服务器到客户端就叫反向代理。
1）实验前准备
准备三台虚拟机，一台主机充当代理服务器，一台主机当web 服务器，一台主机作为客户端使用。为了实验的方便，我们关闭三台主机的防火墙与 SELINUX，并安装 http 服务包。
[root@linuxidc ~]# iptables -F # 关闭防火墙 [root@linuxidc ~]# setenforce 0 # 临时关闭 selinux [root@linuxidc ~]# sed -i 's/^SELINUX=.*$/SELINUX=disabled/' /etc/selinux/config #永久关闭 [root@linuxidc ~]#2）配置代理服务器
代理服务器主要是实现对客户端的访问进行转发，去web 服务器上替客户端访问资源。
3）配置 web 服务器
在web 服务器上配置虚拟主机并设置 redirect 参数，由于 ProxyPassServer 只有在出现 302 转发是才能体现出它与 ProxyPass 不同。为了模拟局域网环境，我们使用防火墙策略禁用客户端的访问。
结果分析
上面搭建好了代理服务器，接下来配合是 elinks 与 tcpdump 以及 wireshark 我们来做实验分析（这里主要是验证 ProxyPassServer 的作用，ProxyPass 原理简单，这里不做实验证明）。
测试 1 ：我们不开启 ProxyPassServer 选项，只使用ProxyPass 选项。如下图
[root@linuxidc ~]#cat /etc/httpd/conf.d/test.conf <VirtualHost *:80> ProxyPass "/" "http://172.18.254.54/" #ProxyPassReverse "/" " # 注释掉 </VirtualHost>在客户端上使用 elinks 访问代理服务器。
[root@linuxidc ~]#elinks http://172.18.250.234/index.html.txt由于没有 ProxyPassServer 选项，所以我们访问资源失败，出现下图提示。
测试 2 ：开启 ProxyPassServer 选项，我么先在 Agent 上开启 tcpdump 进行抓包
[root@linuxidc ~]# tcpdump tcp -i ens33 -w ./target.cap # -w 表示将结果存储起来，方便 wireshark 进行分析在客户端上使用 elinks 进行访问，为了验证 ProxyPassServer 的功能我们访问两次。由于使用了 ProxyPassServer 功能，所以我们能看到重定向的文件内容。
然后我们分析一下抓到的数据包。
从上面的数据包信息可知当我们第一次访问 index.html.txt 时，由于 index.html.txt 重定向到了 inde2.html，所以代理服务器在返回结果是，不是返回给客户端一个重定向后的资源(http://172.18.254.54/inde2.html)，这个资源对客户端是不能访问的，此时 ProxyPassServer 的作用就起作用了，代理服务器在返回该资源时，直接又去访问了重定向之后的资源，然后在返回给客户端数据。也验证了上文中提到的 ProxyPassServer 的工作原理。
本篇总结
记得第一次看到这个两个参数的时候，也是一脸茫然，经过简单的实验发现，有没有 ProxyPassServer 参数都能访问成功，后来查找了许多资料，发现如果出现重定向（301、302）资源的情况下（目前我只发现这种时候会有区别，是不是唯一，我不敢说），客户端在去访问资源便不可以。于是亲手实验，发现果然如此，当添加 ProxyPassServer 参数后，访问重定向资源也能顺利访问了。由于实验需要很多的测试，一会儿在这台机器，一会儿在另外一台主机上，文章中为了能让大家能够很好的理解，有些小细节就省略了。实验步骤太多，所以绞尽脑汁也没有完美的描述出实验过程，望读者见谅。
本文永久更新链接地址：http://www.linuxidc.com/Linux/2017-10/147378.htm
