简介

• 区分正向代理和反向代理的文章有很多，但实际应用中还是容易混淆，让人误把代理的特征当做识别代理的充分条件
• 正反向代理基础知识
  知乎总结
  较为透彻的总结

案例

在我的小程序demo中，使用一个中间服务器作代理服务器B，豆瓣公开接口提供方为服务器C，客户端A请求C通过B转发，请问：B是正向代理还是反向代理

• 认为B是反向代理的论据为：B实际上就是C，B是C的代理，B提供和C功能一致的服务
• 乍看上去，似乎视为反向代理基本合理，实际上，B是正向代理，因为B的目标是代替客户端A请求C，作用是完成客户端无法实现（豆瓣根据http refer限制小程序发起请求）的请求

正反向代理特征

简记

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

• 如果直接通过这句号来识别代理，会产生一定混乱，因为代理B既可以看做A的代理也可以看做C的代理
• 但这句话没错，这是正反向代理的重要特征

特征一：是否处于同一局域网

• 有人认为，B和A在一起是正向代理，B和C在一起是反向代理
• 这是一个特征，实际上网络物理位置都能抽象成ABC各自独立位置，是否处于同一个局域网只是正反向代理常见的拓扑布局，不能作为判断B代理的根本依据

特征二：是否代理服务器B和C是同一个域名

• 有人认为，B服务器域名是api.b.com,C服务器是api.c.com，域名不同，故B是反向代理
• 是否同一个域名也是代理具体实现可能的常见特征，不能判断代理正反向。猜测产生错误认识的原因是经常配置各种反向服务器对该特征印象深刻

特征三：一对多还是多对一多对多关系

• 有一张典型的正反向代理的图片（Tom朱的回答）体现了正反向代理的本重要特征，仅仅凭映射无法佐证。
• 值得说明的是，这张图是根据你能判断出正反向代理之后画出的，据图判断是结果推原因，显然也不正确。

特征四：透明性

• 实际上产生反向代理的认识根本在于透明性，理由是从客户端A角度看，A对C无感知，A只知道B的存在，故B是反向代理
• 这样说来，从C角度看，C对A也无感知，B可称为正向代理

判断代理的根本

历史原因

• 代理的产生是替A完成某种功能，对外隐藏A，对客户端来说代理是透明的，客户端并不知道代理存在。
• 反向代理后来出现，主要应用在入口服务器分发请求给子服务器，实际上相当于代理的功能是服务器的一部分，而非客户端的替身（当然诡辩地讲，可以硬说是通过了客户端请求信息也是客户端的一部分，显然这就种抬杠追究就没意义了）
• 反向代理可以做负载均衡，反向代理还应用于公司堡垒机，为所有客户端请求提供一层安全的壳并记录过滤一些请求。可以看到，这两种反向代理大概率在同一局域网，满足一对多映射，对内透明，可能只有入口服务器一个域名，符合特征，但特征反推正反向代理则不正确。

判断根本

• 判断正反向代理的根本在于：
  代理设置的目的和作用，为谁服务（具体AC谁来设置无关紧要）

案例中，设置代理的目的是伪装成客户端访问豆瓣，作用是实现客户端不能访问豆瓣的功能。我用B并不是要给豆瓣服务器C完成某种任务，而是要代理客户端。

结尾

个人理解，如有错误，诚请斧正