我们上网的时候，有时需要配置一个代理服务器（比如被墙），这个代理服务器是正向代理；开发服务器系统的时候，将客户端/浏览器发过来的请求代理分发到后台多个真正的业务服务器，这个代理是反向代理。

可以认为正向代理是客户端的，反向代理是服务端的。

最高票 nightire 的回答已经很好了，但如果还是想从向 正向 ， 反向 这方面来理解的话。

• 正向代理

场景：

你想从内网环境（比如某个墙，或者不需要）访问目标机器，但是你不能或不想直接连接它，此时通过一个（正向）代理服务器做传信人。

此时这个过程就是正向代理。\(^_^)/

• 反向代理

场景：

你想从外网（相对）来访问一个内网环境，此时因为防火墙等等，你不能直接连接它，或者你不知道目标数据是在哪一台服务器上面，只知道有个看门人（反向代理服务器），只要问它我就可以根据我的得到的授权帮我取到正确的东西。

此时这个过程就是反向代理。

区别就是这么样~

正向代理：你去吃 KFC 吃汉堡鸡翅，这个汉堡鸡翅经过各层“代理”分中心从总部拿到，再分发到你手上。
反向代理：KFC 总部在给你汉堡鸡翅时，可能先分配不同地区的分中心然后再到门店，最后再到配送给你，但对于你来说，是透明的，无需知道是华东还是华北的分中心给你配送。

正向代理： 你需要主动设置代理服务器ip或者域名进行访问。由设置的服务器ip或者域名去获取访问内容并返回。

反向代理： 你不需要任何设置，直接访问服务器真实ip或者域名，但是服务器内部会自动根据访问内容进行跳转及内容返回，你不知道它最终访问的是哪些机器。

对于ABC例子，正向代理可以理解为:C作为A的代理人去找B，而反向代理中的C更像是B的代理人，去向A做反馈。

电脑访问服务器，服务器不知电脑真实IP，则两者间有一个正向代理。

电脑访问服务器，电脑不知服务器真实IP，则两者间有一个反向代理。

当然，现在很多正向代理也可以通过http head 传递电脑的真实IP

• 正向代理

举个例子，你在IE上配置了代理服务器，这就是正向代理。在这片土地，你需要访问google，但是得ｆｑ，那就得配置个代理服务器，然后你访问ｇｏｏｇｌｅ，就会去连接这个代理服务器，代理服务器会去连接ｇｏｏｇｌｅ，然后再返回给你

• 反向代理

不需要配置代理服务器，假如你要访问ｇｏｏｇｌｅ，有一台服务器可以访问ｇｏｏｇｌｅ，你可以连接这个代理服务器，那么这个代理服务器可以配置一个地址让你访问。那么，你访问这个地址，代理服务器就会转向ｇｏｏｇｌｅ，然后将数据返回给你

我最开始去区分正反向的时候，是通过是否配置客户端（配置代理服务器）来区分的，当时还不太懂，所以用这种有漏洞的方法。

其实还有种代理，叫做　 透明代理 　，就是你在不用配置代理服务器的情况下，起到正向代理的功能，你根本不需要知道是否有代理服务器的存在。

最简单来说看你代理谁。客户端的代理就是正向代理，服务端的代理就是反向代理

这个确实让人太难理解

查看 http://segmentfault.com/q/1010000003698318?_ea=331448

反向代理意味着它背后的目标是固定的
用户访问到你的nginx等价于访问后面代理的web服务

正向代理是指它代理的目标是不固定的
用户通过代理服务器可以访问任意web服务

主要区别在于，到底是客户端还是服务器做的代理。
如果是客户端发送请求时使用的代理，就是正向代理；
而服务器端接收到客户端的请求时使用代理转移到其他服务器则是反向代理；

A 找 B 直接沟通，这就等于没有什么代理；

然而中间夹一个传话的 C，C 就是代理了，A 通过 C 把信息传递给 B，然后 C 再把 B 的反馈转达给 A。

在这个过程中，A 知道沟通的直接目标是 B，只不过由于各种原因无法直接和 B 面对面，需要中间人 C，这就是所谓“正向代理”，其实我们很少说正向代理，在英文原文里，这个叫 Forward Proxy，一般就直接叫代理，你翻译成“转交代理”或“传达代理”都比“正向代理”强，然而没必要，因为代理这个词的本意就是如此。

另外一种情况则是：A 并不知道 B 的存在，它只知道找 C 就可以得到想要的回复，对于 A 来说有没有 B 或者有多少个 B、D、E、F……都不重要，只要有 C 就够了。而 C 则根据情况去获取反馈然后响应给 A。

这种就叫反向代理了。理解其中的区别不要从“正反”两个反义方向词上做文章，英文里的 Forward 和 Reverse 并不是一对反义词，Forward 和 Backward 才是，然而 Reverse 和 Backward 并不是一个意思……所以说技术书籍资料还就是得看原文的啊。

－－－－－－

刚才有小伙伴问了我一个问题，因为他还是对此有困惑，我给他举个例子他明白了。我不知道我上面的答案是否能让大家明白，所以我把这个例子也写出来：

Forward Proxy（代理）

我想访问 www.google.com，然而大家都知道它被墙了，我没法直接访问它。于... VPN 服务并设定其为本地 HTTP 访问的代理（比如说在 Mac 下勾选“通过 VPN 连接发送所有流量），然后我再访问 www.google.com，此时我的请求被该 VPN 服务代理了，它帮我访问了 www.google.com 然后把结果返回给我。

1. 这个例子是代理的一种应用场景，但并非代表代理只能用于这个

2. 最重要的特征是我知道 www.google.com 的存在，而且我访问的网址也的确是 www.google.com，只不过我的访问请求经由了 VPN 代理来转交，同样响应也是如此

3. 在本例中，代理是透明的，用户有可能不知道它的存在（通常是知道的，只不过代理的设置可能不是他自己来做）

Reverse Proxy（反向代理）

我有一个 Nginx 服务部署在 www.mysite.com 的 80 端口，用户访问它就可以看见我做的网站；在我的网站中有一些 Ajax 请求去获取 JSON 数据，然而提供这些数据的 API Service 部署在服务器上的 8000 端口，该端口由于防火墙的阻挠使得用户无法直接访问到。

于是我重新配置了 Nginx，让它把所有经由 :80/api/ 的访问请求都代理给 localhost:8000，然后把响应返回给原始的请求方（即：Origin Host），这就是反向代理。现在我的用户可以正常访问 www.mysite.com 啦。

1. 同上，这是反向代理的一种应用场景，但并非代表它只能这样用

2. 最重要的特征是我的用户压根不知道 localhost:8000 这个服务的存在，并且即使知道也访问不到——开 VPN 也访问不到，这是俩码事！

3. 对于用户来讲，唯一的“对话”方只有 www.mysite.com（80 端口），他们不知道也不必知道后面发生了什么