正向代理與反向代理
1、正向代理(forward)是一個位於客戶端和原始服務器(origin server)之間的服務器，爲了從原始服務器取得內容，客戶端向代理髮送一個請求並指定目標(原始服務器)，然後代理向原始服務器轉交請求並將獲得的內容返回給客戶端。客戶端必須要進行一些特別的設置才能使用正向代理。
2、反向代理(reverse proxy)正好相反，對於客戶端而言它就像是原始服務器，並且客戶端不需要進行任何特別的設置。客戶端向反向代理的命名空間(name-space)中的內容發送普通請求，接着反向代理將判斷向何處(原始服務器)轉交請求，並將獲得的內容返回給客戶端，就像這些內容原本就是它自己的一樣。正向代理與反向代理
3、兩者區別
從用途上來講：
正向代理的典型用途是爲在防火牆內的局域網客戶端提供訪問Internet的途徑，正向代理還可以使用緩衝特性減少網絡使用率。
反向代理的典型用途是將防火牆後面的服務器提供給Internet用戶訪問，反向代理還可以爲後端的多臺服務器提供負載平衡，或爲後端較慢的服務器提供緩衝服務。另外，反向代理還可以啓用高級URL策略和管理技術，從而使處於不同web服務器系統的web頁面同時存在於同一個URL空間下。
從安全性來講：
正向代理允許客戶端通過它訪問任意網站並且隱藏客戶端自身，因此你必須採取安全措施以確保僅爲經過授權的客戶端提供服務。
反向代理對外都是透明的，訪問者並不知道自己訪問的是一個代理。
而squid是一個forword/reverse proxy，兩個功能兼備，一般可以作爲局域網的上網緩存，此時作爲正向代理。一般服務器會讓squid作爲前端，那就是充當反向代理，反向代理有很多軟件都可以，比如nginx、lighttpd，但他們兩個一般做不了正向代理。
4、透明代理（簡單代理）：透明代理的意思是客戶端根本不需要知道有代理服務器的存在，它改編你的request fields（報文），並會傳送真實IP。注意，加密的透明代理則是屬於匿名代理，意思是不用設置使用代理了，例如Garden 2程序。
如何使用透明代理
透明代理技術中的透明是指客戶端感覺不到代理的存在，不需要在瀏覽器中設置任何代理，客戶只需要設置缺省網關，客戶的訪問外部網絡的數據包被髮送到缺省網關，而這時缺省網關運行有一個代理服務器，數據實際上被被重定向到代理服務器的代理端口（如8080），即由本地代理服務器向外請求所需數據然後拷貝給客戶端。理論上透明代理可以對任何協議通用。
但是在這種情況下客戶端必須正確設置DNS服務器。因爲現在瀏覽器不設置任何代理。則DNS查詢必須由browser來解析，也就是要由客戶端必須在TCP/IP中設置的正確的DNS服務器，其完成dns解析。
私有網地址爲192.168.1.*, 其中客戶機是192.168.1.100，防火牆機器網卡是192.168.1.1。透明web代理被安裝在防火牆機器上並配置端口爲8080。內核使用iptables把與防火牆端口80的連接重定向到代理服務。
5、透明模式的防火牆就好象是一臺網橋(非透明的防火牆好象一臺路由器)，網絡設備(包括主機、路由器、工作站等)和所有計算機的設置(包括IP地址和網關)無須改變，同時解析所有通過它的數據包，既增加了網絡的安全性，又降低了用戶管理的複雜程度。
防火牆使用透明代理技術，這些代理服務對用戶也是透明的，用戶意識不到防火牆的存在，便可完成內外網絡的通訊。當內部用戶需要使用透明代理訪問外部資源時，用戶不需要進行設置，代理服務器會建立透明的通道，讓用戶直接與外界通信，這樣極大地方便了用戶的使用。 一般使用代理服務器時，每個用戶需要在客戶端程序中指明要使用代理，自行設置Proxy參數(如在瀏覽器中有專門的設置來指明HTTP或FTP等的代理)。而透明代理服務，用戶不需要任何設置就可以使用代理服務器，簡化了網絡的設置過程。
透明代理的原理如下：假設A爲內部網絡客戶機，B爲外部網絡服務器，C爲防火牆。當A對B有連接請求時，TCP連接請求被防火牆截取並加以監控。截取後當發現連接需要使用代理服務器時，A和C之間首先建立連接，然後防火牆建立相應的代理服務通道與目標B建立連接，由此通過代理服務器建立A 和目標地址B的數據傳輸途徑。從用戶的角度看，A和B的連接是直接的，而實際上A 是通過代理服務器C和B建立連接的。反之，當B對A有連接請求時原理相同。由於這些連接過程是自動的，不需要客戶端手工配置代理服務器，甚至用戶根本不知道代理服務器的存在，因而對用戶來說是透明的。
透明代理與透明模式都可以簡化防火牆的設置，提高系統安全性。但兩者之間也有本質的區別：工作於透明模式的防火牆使用了透明代理的技術，但透明代理並不是透明模式的全部，防火牆在非透明模式中也可以使用透明代理。
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/iinel/archive/2009/10/17/4687760.aspx