Web 代理是一種存在於網絡中間的實體，提供各式各樣的功能。現代網絡系統中，Web 代理無處不在。
代理的作用
一、提高訪問速度。因爲客戶要求的數據存於代理服務器的硬盤中，因此下次這個客戶或其它客戶再要求相同目的站點的數據時，就會直接從代理服務器的硬盤中讀取，代理服務器起到了緩存的作用，對熱門站點有很多客戶訪問時，代理服務器的優勢更爲明顯。
二、Proxy可以起到防火牆的作用。因爲所有使用代理服務器的用戶都必須通過代理服務器訪問遠程站點，因此在代理服務器上就可以設置相應的限制，以過濾或屏蔽掉某些信息。這是局域網網管對局域網用戶訪問範圍限制最常用的辦法，也是局域網用戶爲什麼不能瀏覽某些網站的原因。撥號用戶如果使用代理服務器，同樣必須服從代理服務器的訪問限制，除非你不使用這個代理服務器。
三、通過代理服務器訪問一些不能直接訪問的網站。互聯網上有許多開放的代理服務器，客戶在訪問權限受到限制時，而這些代理服務器的訪問權限是不受限制的，剛好代理服務器在客戶的訪問範圍之內，那麼客戶通過代理服務器訪問目標網站就成爲可能。國內的高校多使用教育網，不能出國，但通過代理服務器，就能實現訪問因特網，這就是高校內代理服務器熱的原因所在。
四、安全性得到提高。無論是上聊天室還是瀏覽網站，目的網站只能知道你來自於代理服務器，而你的真實IP就無法測知，這就使得使用者的安全性得以提高。代理服務器工作流程
- 當客戶端A對web服務器請求時,此端提出請求時,此請求會首先發送到代理服務器.
- 代理服務器接收到客戶端請求後,會檢查緩存中是否存有客戶端所需要的數據.
- 如果代理服務器沒有客戶端A所請求的數據,它將會向WEB器提交請求.
- WEB服務器響應請求的數據.
- 代理服務器向客戶端A轉發Web服務器的數據.
- 客戶端B訪問web服務器,向代理服務器發出請求.
- 代理服務器查找緩存記錄,確認已經存在WEB服務器的相關數據.
- 代理服務器直接回應查詢的信息,而不需要再去服務器進行查詢,從而達到節約網絡流量和提高訪問的速度目的.
Http協議中的代理形式
HTTP 代理存在兩種形式，分別如下：
第一種是RFC 7230 - HTTP/1.1:Message Syntax and Routing（即修訂後的 RFC 2616，HTTP/1.1 協議的第一部分）描述的普通代理。這種代理扮演的是「中間人」角色，對於連接到它的客戶端來說，它是服務端；對於要連接的服務端來說，它是客戶端。它就負責在兩端之間來回傳送 HTTP 報文。
第二種是Tunneling TCP basedprotocols through Web proxy servers（通過Web代理服務器用隧道方式傳輸基於TCP的協議）描述的隧道代理。它通過HTTP協議正文部分（Body）完成通訊，以HTTP的方式實現任意基於TCP的應用層協議代理。這種代理使用 HTTP 的 CONNECT 方法建立連接，但 CONNECT 最開始並不是 RFC 2616 - HTTP/1.1 的一部分，直到 2014 年發佈的 HTTP/1.1 修訂版中，才增加了對 CONNECT 及隧道代理的描述，詳見 RFC 7231 - HTTP/1.1: Semantics andContent。實際上這種代理早就被廣泛實現。
事實上，第一種代理，對應《HTTP 權威指南》一書中第六章「代理」；第二種代理，對應第八章「集成點：網關、隧道及中繼」中的 8.5 小節「隧道」。普通代理
原理：HTTP 客戶端向代理服務器發送請求報文，代理服務器需要正確地處理請求和連接（例如正確處理 Connection:keep-alive），同時向目標服務器發送請求，並將收到的響應轉發給客戶端。
假如我通過代理訪問 A 網站，對於 A 來說，它會把代理當做客戶端，完全察覺不到真正客戶端的存在，這實現了隱藏客戶端 IP 的目的。當然代理也可以修改 HTTP 請求頭部，通過 X-Forwarded-IP 這樣的自定義頭部告訴服務端真正的客戶端 IP。但服務器無法驗證這個自定義頭部真的是由代理添加，還是客戶端修改了請求頭，所以從 HTTP 頭部字段獲取 IP 時，需要格外小心。
給瀏覽器顯式的指定代理，需要手動修改瀏覽器或操作系統相關設置，或者指定 PAC（Proxy Auto-Configuration，自動配置代理）文件自動設置，還有些瀏覽器支持 WPAD（Web ProxyAutodiscovery Protocol，Web 代理自動發現協議）。顯式指定瀏覽器代理這種方式一般稱之爲正向代理，瀏覽器啓用正向代理後，會對 HTTP 請求報文做一些修改，來規避老舊代理服務器的一些問題。
還有一種情況是訪問 A 網站時，實際上訪問的是代理，代理收到請求報文後，再向真正提供服務的服務器發起請求，並將響應轉發給瀏覽器。這種情況一般被稱之爲反向代理，它可以用來隱藏服務器 IP 及端口。一般使用反向代理後，需要通過修改 DNS 讓域名解析到代理服務器 IP，這時瀏覽器無法察覺到真正服務器的存在，當然也就不需要修改配置了。反向代理是 Web 系統最爲常見的一種部署方式。
隧道代理
CONNECT imququ.com:443 HTTP/1.1對於 CONNECT 請求來說，只是用來讓代理創建 TCP 連接，所以只需要提供服務器域名及端口即可，並不需要具體的資源路徑。代理收到這樣的請求後，需要與服務端建立 TCP 連接，並響應給瀏覽器這樣一個 HTTP 報文：
HTTP/1.1 200 Connection Established瀏覽器收到了這個響應報文，就可以認爲到服務端的 TCP 連接已經打通，後續直接往這個 TCP 連接寫協議數據即可。
然而，並非所有的http隧道支持connect方法，Http隧道分爲兩種：
1 不使用CONNECT的隧道
不使用CONNECT的隧道，實現了數據包的重組和轉發。在Proxy收到來自客戶端的Http請求之後，會重新創建Request請求，併發送到目標服務器。當目標服務器返回Response給Proxy之後，Proxy會對Response進行解析，然後重新組裝Response，發送給客戶端。所以，在不使用CONNECT方式建立的隧道，Proxy有機會對客戶端與目標服務器之間的通信數據進行窺探，而且有機會對數據進行串改。2 使用CONNECT的隧道
而對於使用CONNECT的隧道則不同。當客戶端向Proxy發起Http CONNECT Method的時候，就是告訴Proxy，先在Proxy和目標服務器之間先建立起連接，在這個連接建立起來之後，目標服務器會返回一個回覆給Proxy，Proxy將這個回覆轉發給客戶端，這個Response是Proxy跟目標服務器連接建立的狀態回覆，而不是請求數據的Response。在此之後，客戶端跟目標服務器的所有通信都將使用之前建立起來的建立。這種情況下的Http隧道，Proxy僅僅實現轉發，而不會關心轉發的數據。這也是爲什麼在使用Proxy的時候，Https請求必須首先使用Http CONNECT建立隧道。因爲Https的數據都是經過加密的，Proxy是無法對Https的數據進行解密的，所以只能使用CONNECT，僅僅對通信數據進行轉發。與proxy有關的字段
X-Forwarded-For（XFF）是用來識別通過HTTP代理或負載均衡方式連接到Web服務器的客戶端最原始的IP地址的HTTP請求頭字段; Squid 緩存代理服務器的開發人員最早引入了這一HTTP頭字段，如果沒有XFF或者另外一種相似的技術，所有通過代理服務器的連接只會顯示代理服務器的IP地址(而非連接發起的原始IP地址)，這樣的代理服務器實際上充當了匿名服務提供者的角色，如果連接的原始IP地址不可得，惡意訪問的檢測與預防的難度將大大增加。
X-Forwarded-Host和X-Forwarded-Proto分別記錄客戶端最原始的主機和協議。
Proxy-Authorization：連接到proxy的身份驗證信息
Proxy-connection：它不是標準協議的一部分,標準協議中已經存在一種機制可以完成此協議頭的功能,這就是Connection頭域,與Proxy-Connection頭相比，Connection協議頭幾乎提供了相同的功能，除了錯誤部分。而且，Connection協議頭可用於任意連接之間，包括HTTP服務器，代理，客戶端，而不是像Proxy-Connection一樣，只能用於代理服務器和客戶端之間。參考
《HTTP 代理原理及實現（一）》https://imququ.com/post/web-proxy.html
《HTTP 代理原理及實現（二）》http://www.tuicool.com/articles/iMBzAfj