最近工作中遇到了 nginx 的代理相关问题，于是就了解了一下正向代理 / 反向代理相关内容，简单记一下
概括
在用户使用浏览器访问某网页的情景下
正向代理由客户端配置，对服务器透明，常用于游戏加速等场景
反向代理由服务器配置，对客户端透明，常用于负载均衡、镜像站等场景
正向代理
如果客户端 C 想访问服务器 S，但是由于某种原因——例如过高的延迟等——导致访问不正常，就可以采取这种方法。
其过程为，以本地设置某软件代理给代理服务器 P 为例
- C 希望访问 S 上的资源，比如 <www.game.com>
- 通过在本机的配置，不把请求直接给 S，而是把请求发送给了 P
- P 解析请求，并转发给 S
- S 返回给 P，此时 S 并不知道真正的发送者是 C，只是按照常规把数据返回给给发送者 P （对服务器透明）
- P 收到后返回给 C
所以 C-S 之间能够流畅通讯，因为 P 在中间起到了桥梁的作用，但是这个过程 S 是不知道的。
所以会面临一个问题：如果同时有上百个客户端 C 试图访问服务器 S，正常来说 S 会收到来自不同的上百个 IP 的请求。河里。
但是由于使用了代理服务器 P，服务器只知道由上百个相同 IP 的请求，所以会采取一定的防御机制，比如验证码或者直接拒绝访问。
反向代理
nginx 就是一个流行的反向代理软件，常见于负载均衡的场景。客户端不需要任何配置，就可以通过反向代理访问服务器，也就是说，反向代理对于客户端而言是透明的。
梳理一下客户端通过反向代理访问服务器的流程：
- 客户端 C 希望访问服务器 S 上的资源，于是直接向 <www.baidu.com> 发送了请求
- C 以为他访问的 IP 是 <www.baidu.com> 的 IP，实际上这个 IP 配给了这个网站的反向代理服务器 P（对客户端透明）
- P 收到了请求，后端可能配置了大量相同的服务器来应对高并发的情况，由他来决定这个请求该转发给哪个真正的服务器（负载均衡）
- 服务器返回给 P，P 返回给 S
其作用除了负载均衡之外，还可以作为一道安全屏障。
