https://segmentfault.com/q/1010000003491873
A和B直接溝通，這就等於沒有代理
然后中間夾一個傳話的C,C就是代理了，A通過C把信息傳遞給B,然后再把B的反饋轉達給A.
在這個過程中，A知道溝通的直接目標是B,只不過由於各種原因無法直接和B面對面，需要中間人C，這就是所謂“正向代理”，其實i我們很少說正向代理，一般直接說代理
舉個例子：
我下訪問www.google.com，然而大家都知道它被搶了，我沒法直接訪問它，於是我連接了一個VPN
服務並設定其為本地HTTP訪問的代理，然后我再訪問www.google.com,此時我的請求被該VPN服務代理了，它幫我訪問了www.google.com然后把返回結果給我（叫做代理，不是叫做反向代理）
- 這個例子是代理的一種應用場景，但並非代表代理只能用於這個
- 最重要的特征是我知道www.google.com的存在，而且我訪問的網址也的確是www.google.com，只不過我的訪問請求由VPN代理來轉交，同樣相應也是如此
- 在本例中，代理是透明的，用戶有可能不知道他的存在（通常是知道的，只不過代理的設置及可能不是他自己來做）
另一種情況是：
A並不知道B的存在，它只知道找C就可以得到想要的回復，對於A來說有沒有B,B!,C,C!......D,F都不重要，只要有C就夠了。而C則根據情況去獲取反饋然后相應給A。
這種就叫反向代理了
舉個例子：
我有一個Nginx服務部署再www.mysite.com的80端口，用戶訪問它就可以看見我做的網站；在我的網站中有一些Ajax請求獲取JSON數據，然而提供這些數據的API Service部署在服務器上的8000端口,該端口由於防火牆的阻撓使得用戶無法直接訪問到。
於是我重新配置了Nginx,讓它把所有經由：80/api/的訪問請求都代理給localhost:8000，然后把響應返回給原始請求方，這就是反向代理
- 這是反向代理的一種應用場景，但並非代表它只能這樣用
- 最重要的特征是我的用戶壓根不知道localhost:8000這個服務的存在，並且即使知道也訪問不到-----開VPN也訪問不到，這是兩碼事
- 對於用戶來講，唯一的“對話”方只有www.mysite.com(80端口)，他們不知道也不比要知道后面發生了什么
參考 https://blog.csdn.net/qq_32963841/article/details/100552329
嗯，就醬~~