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
嗯，就酱~~