本節索引
場景分析
正向代理
反向代理
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.vinsent.cn 這個示例表示對所有gif圖片的請求，都被會轉到後端，如此時請求 http://example.com/foo/bar.gif，那內部將會轉換爲這樣的請求http://http://www.vinsent.cn/admin/bar.gif。
3 ProxyPa***everse
語法：ProxyPa***everse [路徑] url
說明：它一般和ProxyPass指令配合使用，此指令使Apache調整HTTP重定向應答中Location, Content-Location, URI頭裏的URL，這樣可以避免在Apache作爲反向代理使用時。後端服務器的HTTP重定向造成的繞過反向代理的問題。參看下面的例子：
ProxyPass /hadoop http://www.vinsent.cn/
ProxyPa***everse /hadoop http://www.vinsent.cn/
實驗環境搭建
上面介紹了ProxyPass與ProxyPassServer以及ProxyPassMatch的基礎用法，下面詳解向大家解釋他們的工作原理。
ProxyPass 很好理解，就是把所有來自客戶端對http://www.vinsent.cn的請求轉發給http://172.18.234.54上進行處理。ProxyPa***everse 的配置總是和ProxyPass 一致，但用途很讓人費解。似乎去掉它很能很好的工作，事實真的是這樣麼，其實不然，如果響應中有重定向，ProxyPa***everse就派上用場。
ProxyPa***everse 工作原理：假設用戶訪問http://www.vinsent.cn/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.vinsent.cn/inde2.txt，即是在原請求之後追加上了redirect的路徑。當客戶端再次請求http: //www.vinsent.cn/inde2.txt，代理服務器再次工作把其轉發到http://172.18.234.54/inde2.txt。客戶端到服務器稱之爲正向代理，那服務器到客戶端就叫反向代理。
1）實驗前準備
準備三臺虛擬機，一臺主機充當代理服務器，一臺主機當web服務器，一臺主機作爲客戶端使用。爲了實驗的方便，我們關閉三臺主機的防火牆與SELINUX，並安裝http服務包。
[root@vinsent ~]# iptables -F # 關閉防火牆 [root@vinsent ~]# setenforce 0 # 臨時關閉selinux [root@vinsent ~]# sed -i 's/^SELINUX=.*$/SELINUX=disabled/' /etc/selinux/config #永久關閉 [root@vinsent ~]#
2）配置代理服務器
代理服務器主要是實現對客戶端的訪問進行轉發，去web服務器上替客戶端訪問資源。
3）配置web服務器
在web服務器上配置虛擬主機並設置redirect參數，由於ProxyPassServer只有在出現302轉發是才能體現出它與ProxyPass不同。爲了模擬局域網環境，我們使用防火牆策略禁用客戶端的訪問。
結果分析
上面搭建好了代理服務器，接下來配合是elinks與tcpdump以及wireshark我們來做實驗分析（這裏主要是驗證ProxyPassServer的作用，ProxyPass原理簡單，這裏不做實驗證明）。
測試1：我們不開啓ProxyPassServer選項，只使用ProxyPass選項。如下圖
[root@vinsent ~]#cat /etc/httpd/conf.d/test.conf <VirtualHost *:80> ProxyPass "/" "http://172.18.254.54/" #ProxyPa***everse "/" " # 註釋掉 </VirtualHost>
在客戶端上使用elinks訪問代理服務器。
[root@vinsent ~]#elinks http://172.18.250.234/index.html.txt
由於沒有ProxyPassServer選項，所以我們訪問資源失敗，出現下圖提示。
測試2：開啓ProxyPassServer選項，我麼先在Agent上開啓tcpdump進行抓包
[root@vinsent ~]# 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參數後，訪問重定向資源也能順利訪問了。由於實驗需要很多的測試，一會兒在這臺機器，一會兒在另外一臺主機上，文章中爲了能讓大家能夠很好的理解，有些小細節就省略了。實驗步驟太多，所以絞盡腦汁也沒有完美的描述出實驗過程，望讀者見諒。。