正向代理                                                

A同学在大众创业、万众创新的大时代背景下开启他的创业之路，目前他遇到的最大的一个问题就是启动资金，于是他决定去找马云爸爸借钱，可想而知，最后碰一鼻子灰回来了，情急之下，他想到一个办法，找关系开后门，经过一番消息打探，原来A同学的大学老师王老师是马云的同学，于是A同学找到王老师，托王老师帮忙去马云那借500万过来，当然最后事成了。不过马云并不知道这钱是A同学借的，马云是借给王老师的，最后由王老师转交给A同学。这里的王老师在这个过程中扮演了一个非常关键的角色，就是代理，也可以说是正向代理，王老师代替A同学办这件事，这个过程中，真正借钱的人是谁，马云是不知道的，这点非常关键。

我们常说的代理也就是只正向代理，正向代理的过程，它隐藏了真实的请求客户端，服务端不知道真实的客户端是谁，客户端请求的服务都被代理服务器代替来请求，某些科学上网工具扮演的就是典型的正向代理角色。用浏览器访问 http://www.google.com 时，被残忍的block，于是你可以在国外搭建一台代理服务器，让代理帮我去请求google.com，代理把请求返回的相应结构再返回给我。

                                               

反向代理                                                

大家都有过这样的经历，拨打10086客服电话，可能一个地区的10086客服有几个或者几十个，你永远都不需要关心在电话那头的是哪一个，叫什么，男的，还是女的，漂亮的还是帅气的，你都不关心，你关心的是你的问题能不能得到专业的解答，你只需要拨通了10086的总机号码，电话那头总会有人会回答你，只是有时慢有时快而已。那么这里的10086总机号码就是我们说的反向代理。客户不知道真正提供服务人的是谁。

反向代理隐藏了真实的服务端，当我们请求 www.baidu.com 的时候，就像拨打10086一样，背后可能有成千上万台服务器为我们服务，但具体是哪一台，你不知道，也不需要知道，你只需要知道反向代理服务器是谁就好了，www.baidu.com 就是我们的反向代理服务器，反向代理服务器会帮我们把请求转发到真实的服务器那里去。Nginx就是性能非常好的反向代理服务器，用来做负载均衡。

                                               

两者的区别在于代理的对象不一样：正向代理代理的对象是客户端，反向代理代理的对象是服务端

不妨也关注一下公众号 Python之禅

很久以前，老王去饭店吃饭，需要先到饭店，七荤八素点好菜，坐等饭菜上桌，然后大快朵颐，不亦乐乎。

有了第三方订餐外卖平台（代理），老王懒得动身前往饭店，老王打个电话或用APP，先选好某个饭店，再点好菜，外卖小哥会送上门来。

由于某个品牌的饭店口碑特别好，食客络绎不绝涌入，第三方订餐电话也不绝于耳，但是限于饭店接待能力有限，无法提供及时服务，很多食客等得不耐烦了，纷纷铩羽而归，饭店老总看着煮熟的鸭子飞走了，心疼不已。

痛定思痛，老总又成立了几个连锁饭店，形成一个集群，对外提供统一标准的菜品服务，电话订餐电话400-xxx-7777，当食客涌入饭店总台，总台将食客用大巴运到各个连锁店，这样食客既不需要排队，各连锁店都能高速运转起来，一举两得，老总乐开了花，并为此种运作模式起名为“反向代理”（Reverse Proxy)。                                                

反向代理
在计算机世界里，由于单个服务器的处理客户端（用户）请求能力有一个极限，当用户的接入请求蜂拥而入时，会造成服务器忙不过来的局面，可以使用多个服务器来共同分担成千上万的用户请求，这些服务器提供相同的服务，对于用户来说，根本感觉不到任何差别。

                                               

反向代理的实现
1）需要有一个负载均衡设备来分发用户请求，将用户请求分发到空闲的服务器上

2）服务器返回自己的服务到负载均衡设备

3）负载均衡将服务器的服务返回用户

以上的潜台词是：用户和负载均衡设备直接通信，也意味着用户做服务器域名解析时，解析得到的IP其实是负载均衡的IP，而不是服务器的IP，这样有一个好处是，当新加入/移走服务器时，仅仅需要修改负载均衡的服务器列表，而不会影响现有的服务。

谈完反向代理服务，再来谈谈终端用户常用的代理服务。

代理
1）用户希望代理服务器帮助自己，和要访问服务器通信，为了实现此目标，需要以下工作：

a) 用户IP报文的目的IP = 代理服务器IP
b) 用户报文端口号 = 代理服务器监听端口号
c) HTTP 消息里的URL要提供服务器的链接

2）代理服务器可以根据c)里的链接与服务器直接通信

3）服务器返回网页

4）代理服务器打包3）中的网页，返回用户。

代理服务器应用场景
场景一
如果不采用代理，用户的IP、端口号直接暴露在Internet（尽管地址转换NAT），外部主机依然可以根据IP、端口号来开采主机安全漏洞，所以在企业网，一般都是采用代理服务器访问互联网。

那有同学会有疑问，那代理服务器就没有安全漏洞吗？
相比千千万万的用户主机，代理服务器数量有限，修补安全漏洞更方便快捷。

场景二
在一个家庭局域网，家长觉得外部的世界是洪水猛兽，为了不让小盆友们学坏，决定不让小盆友们访问一些网站，可小盆友们有强烈的逆反心理，侬越是不让我看，我越是想看，于是小盆友们使用了代理服务器，这些代理服务器将禁止访问的网页打包好，然后再转交给小盆友，仅此而已。

当然关键的关键是代理服务器不在禁止名单当中！


2018.08.17文章更新于公众号，欢迎阅读：

知乎更新系列二：反向代理为何叫反向代理？mp.weixin.qq.com

先说正向代理，比如要访问youtube,但是不能直接访问，只能先找个翻墙软件，通过翻墙软件才能访问youtube.   翻墙软件就叫做正向代理 。

所谓的反向代理，指的是用户要访问youtube,但是youtube悄悄地把这个请求交给x-art来做，那么x-art就是反向代理了。

上面的答案都说的很好，我画了张图能更直观地解释为何反向代理叫“反向“代理
                                               

                                               

所谓反向代理基本上就是一个服务端的负载均衡器。很好奇java界总喜欢弄一些新名词。。莫名其妙。语言是用来交流的，不是用来装逼的。有兴趣的可以追根溯源一下这个名词的出处。我理解就是写apache文档那个人造出来的。然后一帮人不理解这个反人类的名词。然后理解了的自以为得意经常面试考，看到这个名词的人以为逼格很高然后不知怎么的这个名词就”流行“起来。我对这个名词的想法是跟UML一样，属于反人类的范畴，如果你不理解，完全可以。碰到别人说到这个名词，你不理解就问他是什么就行了。

看完这么多人的，来说下我的想法，用访问百度来比喻一下。
如果想用正向代理的方式访问百度的话，那我们得这样做：
1、自己搭一个或者找一个代理服务器
2、将上一步得到的代理服务器，在系统中设置好，windows中是这样设置的
                                               

                                               

                                               

                                               

更新回答来一波————————————————————————

要说清楚什么是反向代理，我们就需要先从最简单的C/S架构说起，C/S架构，也即是Client-Server的架构。而最简单的C/S架构，也即是以单个节点作为后端Server的C/S架构。

C/S架构中的单点Server

在普通的开发当中，单点Server的服务方式非常常见，比如使用Django框架做后台服务的时候，就可以通过简单的run server命令运行起一个临时的服务，接着通过地址就可以访问到这个服务了。当然了，对于Django而言，run server命令只是提供开发周期的调试使用的便捷工具，更一般的情况是通过uWSGI把这个Django服务跑起来，以获取并比run server更好的服务性能。

此时部署整一个架构图如下：

                                               

对于请求量非常少的服务，这样的部署不会有什么问题，但如果这个服务请求量上来的时候，这样部署的架构就很有问题了。

首先一个很客观的问题就是，如果单从服务器的物理特性来看，这个服务器就不能支持这么高的请求量。这种情况下，就迫使开发者去把服务迁移到一个CPU更强、内存更高，综合性能更好的服务器。通过更换服务器当然可以解决这个问题，在不考虑成本的条件下，总可以找到性能更好的服务器来替换原来的服务器以支撑服务，但这种理想的条件不在本文考虑范围之内。

第二个问题就是，如果服务Server单节点发生了故障，就必然会影响整个服务，因为对于众多的Client客户端都是连接的一个Server服务端，如果这个节点不可用了，势必会影响所有使用了客户端的用户。

为了解决这两个显而易见的问题，就必须提出一种可以横向拓展的部署架构，使得服务可以支撑的请求量可以随着服务的横向拓展而增加。因而就催生了如下的部署架构：

                                               

基于代理的可横向拓展的C/S架构

在这个部署的架构当中，除了Server节点，还多出了一个叫“Proxy”的节点，那么这个节点是干嘛的呢？                                                

“Proxy”的这个节点，它把他接收的所有的请求都转发到他后面的Server节点当中，然后等待Server节点处理请求，再从Server节点取回执行结果返回到Client。所以“Proxy”的这个节点，他实际上不处理任何的请求。

我们先来看这样子的架构怎么解决了以上的问题，再来思考“Proxy”的这个角色。

首先是第一个问题，服务器性能不足的问题，这个架构如何解决性能不足的问题呢？在这个架构里面，假设Server节点S1性能到达瓶颈了，不能处理更多的请求了。如果采用上面的这个架构，那么我们可以添加Server节点S2，同时告诉“Proxy”节点，让他把部分原来转发到S1节点的请求转发到我这里来。这样子通过服务分流减少压力的方法就可以解决原来S1节点性能不足的问题了。

                                               

接着是第二个问题，单点服务器挂掉了怎么办。还是考虑Server节点S1和S2，两者所能够提供的服务是一样的，假设某一个时候S1挂掉了，这时如果有“Proxy”节点的存在，并且“Proxy”节点能够察觉到S1挂掉了的话，那么让“Proxy”节点把原来要转发给S1节点的请求转发到S2进行处理就可以了，这样子通过服务冗余的方法就可以解决原来S1突然挂掉影响服务的问题。

                                               

解决了这两个问题，接下来我们再从这两个问题里面“Proxy”的角色来理解，什么叫做代理。                                                

在第一个问题里面，“Proxy”节点通过服务分流的方法来减少S1的压力，对于原来应该被S1服务的，却由于被“Proxy”节点转发而被S2服务的Client而言，Client他并不知道实际上是由S1处理的还是S2处理的，Client拿到的是一个从“Proxy”节点返回的结果，换言之，Client并不知道自己的请求实际上是被哪个处理的，他只需要往“Proxy”节点发送请求就好了，剩下的工作就由“Proxy”节点去解决。

也就是，“Proxy”节点相当于一个中介，或者说是一个代理，代理Client去寻找实际的Server节点去完成服务。这样子的模式在现实生活也非常常见，在买房子的时候，通常由房产中介帮助你完成和卖者之间的手续，而不需要你亲自去处理这些事情，你只需要协调好自己与中介之间的手续就好了，这里的中介，就和我们的“Proxy”节点所做的工作非常类似。

同样的，在第二个问题里面，也是相似的理解方式，Client并不需要感知S1是否还能正常工作，Client只需要把请求发送给“Proxy”节点，由它去帮忙处理就可以了。

因此，这里面的“Proxy”节点，也就是我们的代理节点。

正向代理与反向代理

理解了什么是“代理”，离我们理解什么是“反向代理”就只差“反向”两个字了，与“反向”相对的，就是“正向”，本质上来讲，代理都是存在于Client和Server之间，但是由于性质不同，所以也分为这两种。在这一个部分，我们将会学习，什么是反向代理，什么是正向代理。

直观的以两个例子去理解什么是正向代理和反向代理。假设由A、B和C三人，他们之间存在借钱的关系。                                                

对于正向代理，理解起来就是：                                                

1. A需要钱，A知道C由很多钱，想向C借钱

2. 但是A和C有矛盾，于是A想到通过B去借C借钱

3. B向C借到钱了，C不知道是A的存在

4. 这样B就帮助A借到了Z的钱

在这个过程，B就充当了代理借钱的角色，并且是代替A去借钱的，这样就是正向代理。

                                               

接着是反向代理：                                                

1. A需要钱，C有很多钱，A不知道C很多钱

2. A找B借钱

3. B知道C有很多钱

4. B向C借钱，并把借到的钱给A，而没有使用自己的钱借给A

5. A拿到钱以后，以为钱是B的，A不知道C的存在
   在这个过程当中，B也充当了代理借钱的角色，不过这次不是代替A去借的，而是用C的钱借给A的，换言之即是代替C将钱借给了A，这就是反向代理。

                                               

1. 在例子里面，把A换成Client，把C换成Server，就是计算机的例子了。

两者区别

1. 服务对象不同

• 正向代理，代理的是客户端，也就是例子中的A，服务端不知道实际发起请求的客户端

• 反向代理，代理的是服务端，也就是例子中的C，客户端不知道实际提供服务的服务端

正向代理                                                

                                               

反向代理                                                

                                               

2. 安全模型不同

• 正向代理允许客户端通过它访问任意网站并且隐藏客户端自身，因此必须采取安全措施以确保仅为授权的客户端提供服务

• 反向代理都对外都是透明的，访问者并不知道自己访问的是代理，访问者不知道服务节点的存在，认为处理请求的就是代理节点

总而言之，正向代理是从客户端的角度出发，服务于局域网用户，以访问非特定的服务，其中最典型的例子就是翻墙；反向代理正好与此相反，从服务端的角度出发，服务于所有用户，隐藏实际的服务节点，服务节点的架构对用户透明，以代理节点统一对外服务。                                                

作者：咚咚呛

来源：慕课网

本文原创发布于慕课网 ，转载请注明出处，谢谢合作

服务的目标不同。

从前，有两个人，他们分别叫A和B，A稍微笨了点儿，他什么问题都喜欢问别人，自己从来不思考，但是他有个很厉害的技能就是能把别人说的任何话都用手语表达出来；B呢，是个聋子，他听不到，但是他特别聪明，特别喜欢思考问题。

有一天，一个瞎子过来问了A一个数学问题，A一听，好难啊，我不想算了，但是又想着必须得在这个瞎子面前显摆一番。于是，他跑去B的家里，用手语给他描述了这个问题，B分分钟给他算了出来。A拿着答案手舞足蹈的跑去瞎子那里去炫耀，并告诉他这是他自己算出来的。

这个时候，瞎子是不知道A的答案从哪里得到的。

也就是说，瞎子问了A一个问题，A把问题甩给了B去想，然后B解答了，A再告诉瞎子。这中间A其实就是在做一个反向代理的事情。对于瞎子来讲，这个问题具体是B想出来的还是C想出来的，他根本不会知道，因为他看不见。

如果故事你也看不明白的话， 死神小学生中。 凶手-》毛利-》柯南。他们的关系也是这样。

普通的代理，是代表着用户、客户端，去向服务器发请求，要求提供某种服务

反向代理，是代表着服务器，为客户端为用户提供服务

这不就反了嘛

我们常说的代理是正向代理。使用正向代理的过程如下：

1，客户端连接代理。

2，代理连接服务器。

3，服务器将结果发给代理。

4，代理将结果发给客户端。

反向代理的过程如下：

1，客户端连接服务器，其实连接的是反向代理服务器，但是客户端不知道。

2，反向代理将请求转发给相应的服务器。

3，服务器将结果发给反向代理。

4，方向代理将结果发给客户端。

流程基本一样，主要是反向代理是和服务器部署在一起，如nginx，haproxy，但客户端不知道反向代理的存在。反向代理知道服务器集群的情况，知道怎么转发请求给具体的服务器。而正向代理只能转发给相应的域名对应的服务器。反向代理因为和服务器部署在一起，所以可以用来做负载均衡，对客户端请求进行各种处理（如统计连接数，拒绝连接等）等等。

主要记住，反向代理是和服务器集群在一起的，并且知道集群的内部情况。

正向代理即是客户端代理, 代理客户端, 服务端不知道实际发起请求的客户端.

反向代理即是服务端代理, 代理服务端, 客户端不知道实际提供服务的服务端.

使用Nginx实现反向代理

一、 代理服务器 

1、什么是代理服务器 代理服务器，客户机在发送请求时，不会直接发送给目的主机，而是先发送给代理服务器，代理服务接受客户机请求之后，再向主机发出，并接收目的主机返回的数据，存放在代理服务器的硬盘中，再发送给客户机。 

2、为什么要使用代理服务器 

1）提高访问速度 由于目标主机返回的数据会存放在代理服务器的硬盘中，因此下一次客户再访问相同的站点数据时，会直接从代理服务器的硬盘中读取，起到了缓存的作用，尤其对于热门站点能明显提高请求速度。 

2）防火墙作用 由于所有的客户机请求都必须通过代理服务器访问远程站点，因此可在代理服务器上设限，过滤某些不安全信息。 

3）通过代理服务器访问不能访问的目标站点 互联网上有许多开发的代理服务器，客户机在访问受限时，可通过不受限的代理服务器访问目标站点，通俗说，我们使用的翻墙浏览器就是利用了代理服务器，虽然不能出国，但也可直接访问外网。 二、反向代理 VS 正向代理 

1、什么是正向代理？什么是反向代理？ 正向代理，架设在客户机与目标主机之间，只用于代理内部网络对Internet的连接请求，客户机必须指定代理服务器,并将本来要直接发送到Web服务器上的http请求发送到代理服务器中。 反向代理服务器架设在服务器端，通过缓冲经常被请求的页面来缓解服务器的工作量，将客户机请求转发给内部网络上的目标服务器；并将从服务器上得到的结果返回给Internet上请求连接的客户端，此时代理服务器与目标主机一起对外表现为一个服务器。 

2、反向代理有哪些主要应用？ 现在许多大型web网站都用到反向代理。除了可以防止外网对内网服务器的恶性攻击、缓存以减少服务器的压力和访问安全控制之外，还可以进行负载均衡，将用户请求分配给多个服务器。 三、方向代理服务器Nginx 

Nginx作为近年来较火的反向代理服务器，安装在目的主机端，主要用于转发客户机请求，后台有多个http服务器提供服务，nginx的功能就是把请求转发给后面的服务器，决定哪台目标主机来处理当前请求。下面演示如何进行配置使Nginx发挥作用。 

1、模拟n个http服务器作为目标主机 用作测试，简单的使用2个tomcat实例模拟两台http服务器，分别将tomcat的端口改为8081和8082 

2、配置IP域名 

192.168.72.49 http://8081.max.com 

192.168.72.49 http://8082.max.com 

3、配置nginx.conf

upstream tomcatserver1 {

server
192.168.72.49:8081;

}

upstream tomcatserver2 {

server
192.168.72.49:8082;

}

server {

listen 80;

server_name 8081.max.com;

#charset koi8-r;

#access_log logs/host.access.log main;

location / {

proxy_pass http://tomcatserver1;

index index.html index.htm;

}

}

server {

listen 80;

server_name 8082.max.com;

#charset koi8-r;

#access_log logs/host.access.log main;

location / {

proxy_pass http://tomcatserver2;

index index.html index.htm;

}

}

流程：

1）浏览器访问http://8081.max.com，通过本地host文件域名解析，找到192.168.72.49服务器（安装nginx）

2）nginx反向代理接受客户机请求，找到server_name为http://8081.max.com的server节点，根据proxy_pass对应的http路径，将请求转发到upstream tomcatserver1上，即端口号为8081的tomcat服务器。

4、效果展示

请求http://8081.max.com，tomcat1接收返回首页

                                               

请求http://8082.max.com，tomcat2接收返回首页 四、总结 通过分析我们不难得出，以百度为例，如果客户机的IP和百度服务器（目标主机）的IP在同一个网段，那就形同局域网内部发送请求，速度极快。 但如果满足不了这种需求还想到达到一个较好的请求响应时，百度服务器就可以对外提供一个与目标服务器在一个网段的公网IP,也就是反向代理服务的IP，通过代理服务器转发客户机请求，决定幕后的N台服务器谁来处理这个请求，并且由于反向代理服务器与目标主机在一个网段，访问速度也会很快。 

Nginx用作反向代理服务器时，它就是众多反向代理服务器中的一种，通过简单的配置，指定到服务器IP或域名地址便可将客户机请求转发给指定服务器处理请求。

正向代理: 买票的黄牛

反向代理: 租房的代理

LAN不LAN不本质，我有完全使用公网的正代和反代。关键在于，正向代理的客户端知道他在使用代理而服务器不知道，而反代正相反，服务器知道他有个反代而客户端并不知道。                                                 

为什么感觉大家都没回答到点子上。

诚然 大家解释什么是正向代理，什么是反向代理解释的非常好。

但问题其实是反向代理为何叫反向代理。为啥就不能直接叫代理呢？

为什么没人说这个浅显、无聊以及轻浮的问题呢？

其实就是因为 (客户端)代理是先出现的。后来（服务端）代理出现之后。发现虽然也是代理但是跟（客户端）代理的方向是不太一致的。不行，必须起个独一无二举世无双的名字，于是就只能以先出生的（正向）代理作为基准，叫做反向代理了。

就是这样，喵！

我想说 反向代理 这个名字取的太XX

就叫 服务代理 不就OK了吗

局域网通过代理服务访问Internet网叫正向代理，Internet通过代理服务访问局域网叫反向代理

                                               

                                               

来自《Nginx高性能的Web服务器》一书的第七章

书上的说法应该更正规一些

这个主要取决于客户端怎么想～

客户端知道代理是代理，那就是正向代理。

客户端以为代理是real server，那就是反向代理。

正向代理：前端代表。                                                

反向代理：后端代表。                                                

在日常生活中，如果你很忙，你就花钱顾个代理，替你办事儿；

那么，

替客户端办事儿的是正向代理，比如vpn

替服务端办事儿的是反向代理，比如nginx

                                               

The proxy server acting on your behalf will forward your request to the intended endpoint/website.

It also denies serving the request if the resource does not meet the organization policy.

                                               

You would need to know what the proxy server is that will act on behalf of the website/endpoint that serves your request. Partly, this is sufficient to know. However, let’s take an example:

You (or) your program wants to access an endpoint (Example: http://qwerty.com)

In this case, you know that the website has a domain name called http://qwerty.com and can be accessed via http protocol. However, that is totally abstracted from the end user.

正向代理和反向代理，就是在客户端和终端服务器之间，加一个代理服务器。

客户端必须知道终端服务器地址，就是正向代理，例如vpn，加速器等。

客户端不需要知道终端服务器，只需要访问代理服务器就能访问到需要的资源，就是反向服务器。主要应用在网站的服务端，做路径分发的网络服务器。

正向代理中proxy代理client来向一个server发起请求. 
主要用途: 
防火墙的作用, 让所有对一个服务器发起的请求中间加一个中间层, 方便做一些拦截, 屏蔽什么的.

而反向代理中proxy代理一个或者多个server接收clients的请求, server对于client来说是不可见的 
用途: 
1. 内容分发网络CDN, 通过反向代理把请求分发到世界各地的服务器去, 提升访问速度.
2. 大公司不想暴露自己主服务器的位置.

                                               

正向代理(客户)：重点在于体现代理商代理1个商户(产品)为N个客户服务，代理商侧重为多个客户服务(eg.HTTP代理为多个人提供翻墙服务)；

反向代理(商户)：重点在于体现代理商代理N个商户(产品)为某1客户服务，代理商侧重为多个商户服务(eg.百度外卖为多个商户提供平台给某个用户提供外卖服务)。                                                

站的角度同一样，称呼可能就不一样.

用代理，是为了找到在外网内的服务器；

用反向代理，是为了让别人找到在内网里的你的服务器。

我们看到的术语都翻译自英文，理解反向代理从英文入手也是一个好思路。

理解反向代理（Reverse Proxy）之前首先要明白什么是正向代理（Proxy）

代理 Proxy 翻译：a person（代理） authorized to act for another （代理的对象）                                                

一般的代理（正向）的代理对象是：请求方，让你做什么你就代它做什么。                                                

反向代理即代理服务方，替服务端做事。服务端的服务它全代理了。                                                

Proxy 正向代理： act as a client

Reverse Proxy 反向代理： act as a server

总结一下：

正向代理：代理客户端，将客户端的请求 等价 转发请求到服务端，代理机不了解服务端任何情况

反向代理：代理服务端，代替服务端接收服务，代理机需要与服务端建立映射关系（配置）

有X,Y,Z三台，X想访问Z，Y是代理服务。

正向代理：X知道Z，可能也知道Y，X的request被Y截获，然后以Y的名义去访问Z，把结果返回，这个过程Y是代理X的。

反向代理：X不知道Z，X知道Y的存在，request到Y之后，实际Y回去访问Z，把结果返回，这个过程Y是代理Z的。

很多时候都是正向代理，反向代理的服务一般就是load balancer，web 加速等。

正或反就是看代理的是client还是server。

给客户端代理叫(正向)代理
例如用vpn，本来客户端直接访问一些网页，现在像google等访问不了，vpn代理客户端请求，访问google。

个人理解，正向反向都是针对用户而言，正向代理就是代理服务器代理用户自己，反向代理就是代理服务器代理的不是用户，反而是目标服务器，所以叫反向代理

主要区别在于，到底是客户端还是服务器做的代理。

如果是客户端发送请求时使用的代理，就是正向代理；

而服务器端接收到客户端的请求时使用代理转移到其他服务器则是反向代理

正向代理客户端，反向代理服务端。

说几句简单粗暴的：

你的电脑对一台服务器说：你帮我把这条访问请求给IP为192.168.1.1的服务器；

这句话突出几个字：帮我把请求给服务器192.168.1.1；这是正向代理。

你的电脑对百度的一台服务器说，我请求摸摸服务。

这句话没有提到，帮我把请求给谁。而是直接与服务器对话。所以不存在前向代理。

但是，想百度这样的网站，你对话的这台服务器他不会去处理你的请求。他会将你的请求转发给内部的其他服务器处理，当内网的服务器处理有结果，内网服务器不会将结果直接给你的电脑；内网电脑会对对话服务器说帮我把请求结果给刚刚发请求的那台电脑；

注意：这里就出现了这几个字：你好，对话服务器，帮我把请求结果给发请求的那台电脑。反向代理

总结：

如果你的电脑说，帮我把请求发给默默服务器------>前向代理

如果你的电脑对某台服务器说，请求摸摸服务------>不存在代理

如果内网服务器，对公网服务器说，将结果返回给某某客户------>反向代理。

更简单点说，有负载均衡的服务器，就会存在反向代理。

确实名字起的很失败！

反向代理： 代理multiple-servers---做负载均衡; 效果: 在client角度看，Nginx就是一个负载均衡器；

正向代理： 代理 multiple- clients--没有任何负载均衡； 效果：在client角度看，Nginx就像一个client-cluster；

正向代理，代理的是客户端，代理为客户端打工；

反向代理，代理的是服务端，代理为服务端打工。

正向代理和反向代理的不同，关键在于“代理”这个家伙的所有权。假设我要去小明那里拿文件，这时可以有两种情况。正向代理：我委托自己的秘书（代理）去找小明拿文件。反向代理：我去找小明拿文件，小明委托他的秘书（代理）把文件交给我。

同样的，在网络世界中，正向代理就是自己的秘书，自己是隐藏的，不需要亲自出马，秘书帮助自己发送请求获取数据，你要给他开工资（买VPN，做一些设置等）。

反向代理就是服务器的秘书，服务器委托自己的秘书接收请求。秘书拿到请求后交给服务器处理，服务器处理完成后再交给秘书。秘书把拿到的结果返回给用户，并且很得意地告诉用户：我就是服务器。

很多情况下，多个服务器会共用一个秘书（反向代理Nginx），这个秘书同时冒充着很多服务器，一会说我是Tomcat服务器，一会说我是PHP服务器，一会又说我是Django服务器。这个秘书还很机智，有的请求多个Tomcat服务器都能处理，他会送到空闲的那个来处理（负载均衡）。

正向代理

1.客户端设置代理服务器地址等信息

2.客户端决定代理服务器最终访问的目标地址

3.客户端显式将访问最终目标地址的包重定向到代理服务器

反向代理

1.客户端直接访问代理服务器IP最为最终访问地址(通常是某个集群的虚IP或者均衡器IP)

2.服务器端决定最终访问的目标地址

3.代理服务器隐式将访问最代理服务器IP的包重定向到最终访问地址

如下图所示：代理1代表客户去请求访问服务器，代理2代表服务器来接收客户请求访问。整个流程是从左到右，代理1在客户的下游，所以称之为正向代理，代理2分发请求给各个真实服务器，处于真实服务器上游，所以称之为反向代理。（开个玩笑） 没必要纠结这个名次，就像spring的依赖注入和控制反转一样 ，理解含义就好。

                                               

写个答案大概记录下自己的认识吧。

proxy很像小区的模型，reverse proxy很像商场连锁店互相调货的模型。

一言以蔽：正向是客户端向服务器，反向服务器向客户端

有一个中介A，负责接收多个客户端的请求，客户端把这个中介A叫做正向代理；

有一个中介B，负责把请求分发给多个服务端，服务端把这个中介B叫做反向代理。

我来说代理的两个例子，自己搭建服务器翻墙上网叫做正向代理，访问http://www.baidu.com是反向代理。

正向代理是客户端搭的代理,用于隐藏自己的真实客户端,起到的作用是信使,负责向服务端送信的;

反向代理是服务端搭的,用于隐藏真实的服务提供端 或者说 搭了一个肉坦当前排,挨揍用的;

靠近用户端的代理是正向代理，靠近服务器端的是反向代理。

用户发起请求到代理服务器的方向为“正”，代理服务器收到用户请求并发给到服务器的方向为“反”

看了上面各位大神解释。我理解的是：正向代理的是请求者，反向代理的是响应者。

正向代理：代理的客户端去访问服务器

反向代理：代理的服务器去返回客户端

很有用，容易理解

正向代理：客户端发起的请求，通过代理服务器，转发给服务器，然后再把服务器返回的内容，转交给客户端。这种服务器只响应代理服务器请求的模式，就是正向代理模式。

反向代理：客户端发起的请求，被一台总代理服务器分发给不同的服务器，交由不同的服务器响应。这种客户端不知道是由哪一台服务器响应它的请求的模式，即使反向代理模式。

got it

正向代理就是你挂代理上网站

反向代理就是网站挂代理上你

不知道，对于有没有人对这种情况有疑问的，如：一个墙外的nginx服务器是个一个反向代理，想要去访问该服务器，却需要一个正向代理。这种情况会不会出现，如果出现的话，需要注意什么呢？

什么时候需要用到反向代理呢

可以诙谐地说：就是我骗服务器（正向）和服务器骗我的区别，才有反向代理的概念

来来回回骗什么？ip地址，不想让你知道，找人转手

正向代理:控制资源的访问。                                                

举个例子，A通过翻墙软件访问youtobe服务（youtobe服务就是资源），B也通过相同的翻墙软件访问youtobe服务，但是B没充钱，翻墙软件不给B代理，也就是说正向代理控制clien端对服务的访问，它不会管你要访问的服务是什么。但是会管你这个client是谁。也就是说对服务端透明的叫正向代理。

反向代理:控制服务的提供。                                                

反向代理服务器不关心哪个client访问，无论是谁，都可以进来，it do not care。但是它会控制谁提供服务，为什么要控制谁提供服务呢，比如服务A,服务A已经达到阀值了，这时反向代理服务器就不忍心再把请求丢给它了，会转而丢给B。也就是说对客户端透明的叫反向代理。

代理 说的是 代理客户端

反向代理 指的是 代理服务端的服务

这些名词起的很没有必要

1、正向代理是代理了身后的客户端A，在客户端A发起请求后，请求首先是发送到代理服务器B（这个请求中包含了客户端真正想访问服务器的地址，客户端告知代理服务器去哪里拿数据），代理服务器替换掉请求的源IP为自身IP，并发往后台服务器C。这种情况下，客户端知道代理服务器的存在，因为自己主动把请求发往代理B，并把自己真正要访问的服务器IP告知代理服务器B。让代理服务器B代替其请求数据。但后台服务器C却不知道客户端A的IP，只知道代理服务器B的IP。

举例：一个富豪家里四个人abcd，他们家还有一个保姆proxy，小区周边有四个商场FGHI。

家里四个人买东西都叫proxy去买，a叫proxy去F买东西，b叫proxy去H买东西，c叫proxy去F买东西。此时真正去买东西的是proxy，并且商场F永远不知道abcd的存在，只知道proxy的存在，但是abcd知道商场的存在，也知道proxy的存在。

2、反向代理服务器

客户端A访问一个地址服务器B，服务器B把源IP替换为自己的IP，并更改目的IP为服务器为C的IP，同时在请求头中加入X-Real-IP，再把请求发往C，这个过程对A来说是透明的，A完全不知道B服务器做了这些操作，A认为自己访问的就是B，但是后台服务器C知道客户端A的存在，因为反向代理服务器B在请求中加入了客户端A的信息（X-Real-IP)。

举例：富豪家里四个人abcd，他们有一个共同联系人商场销售经理proxy，专门某一个品牌的产品，该品牌货源为FGHI。

富豪一家人abcd买该品牌的东西，他们都会打电话给proxy,proxy会根据具体货源情况下订单，订单上有客户的姓名（abcd某一个人），然后把订单发往货源FGHI其中的一家，货源拿到订单可以知道富豪一家的姓名，并把货物发往proxy，最后proxy把货物发给客户。这里富豪一家只知道proxy，并且以为他就是真正的货源，而完全不知道后面的货源的存在，但是货源可以知道富豪的存在，并且知道proxy的存在。

3、从以上角度可以知道，正向代理服务器是代理客户端A，客户端A同时知道代理服务器B和后台服务器C的存在，而后台服务器C只知道代理服务器B的存在并以为他就是自己的真实客户端。

反向代理服务器B是代理后台服务器C，客户端A只知道反向代理服务器B的存在，并且认为其为真正的服务器，反向代理服务器B和后台服务C都知道客户端A的存在。

正向代理就是：我明确知道我要访问谁（比如http://google.com），并且明确知道用谁作为代理服务器（比如一台境外的服务器），这个过程是主动设置的代理。

反向代理就是：我明确知道我要访问谁（比如http://zhihu.com），但是我不知道具体是谁来处理我的请求（我发起请求的时候没有设置代理，比如在入口搞了一台nginx，再分发到具体的web应用处理请求），这个过程是被动的代理。

个人觉得不要纠结“正”和“反”，而是理解代理的设置是主动的还是被动的。

相对于，正向代理而言。

代理是个傀儡，正反向取决于主人，客户端的傀儡称为正向代理，服务端的傀儡称为反向代理。

有一天代理不想做傀儡了想自己独立干大事，就变成了中间人（双向透明）。

所以细想一下，跳板访问绝不是正向代理的独有优点，因为反向代理同样可以实现，只是客户端更需要这种功能所以启用了傀儡；负载均衡也并不是反向代理的独有特色，因为正向代理一样可以做到，只是服务端更需要这种功能故而启用了傀儡。

不要用这个名字会好理解一些，我理解是代理和服务端的信息流向的决策者不同，反向代理是让代理去决定，正向代理是让客户去决定，而后续的分布式之类的只是利用了代理的特性来做，和这两个名词的概念本身没什么关系

In computer networks, a reverse proxy is a type of proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client as though they originated from the proxy server itself.

                                                   

While a forward proxy acts as an intermediary for its associated clients to contact any server, a reverse proxy acts as an intermediary for its associated servers to be contacted by any client.

                                                   

Quite often, popular web servers have also some reverse-proxying functionality, acting as shields for application frameworks with weaker HTTP capabilities.

来自Wikipeida的定义。简单明了。