反向代理和正向代理

公司内网有台测试服务器，代理我在家想访问它。和正直接连？向代IP 是 192.168 开头的，公网根本路由不到。代理解决办法是和正在公司出口装个代理服务，我先把请求发给它，向代它再转给内网那台机器。代理这就是和正正向代理——代理站在客户端这边，替客户端去访问外部资源。向代

反过来，代理我搭了个博客放在家里的和正树莓派上，想让外网的向代人也能看。树莓派没有公网 IP，代理运营商也不给。和正于是向代我在一台云服务器上跑 Nginx，把公网请求转发到家里树莓派。访客以为云服务器就是网站本身，根本不知道背后是台树莓派。这是反向代理——代理站在服务端这边，替服务器接收请求。

两者的核心差异不在技术实现，而在谁被隐藏了。正向代理隐藏客户端，服务器只知道代理的 IP，不知道真实用户是谁。反向代理隐藏服务端，客户端只知道代理的地址，不知道背后有几台机器、分别是什么角色。

翻墙工具是正向代理的典型。浏览器配置 SOCKS5 代理，所有流量先到代理服务器，由它代为请求 Google。Google 看到的是代理服务器的 IP。公司网关做内容过滤也是同理，员工访问外部网站，请求先经过网关，网关决定放行还是拦截。

Nginx 做负载均衡则是反向代理的经典场景。用户请求打到 Nginx，Nginx 根据策略分发给后端三台 Tomcat。用户不关心也感知不到后端有几台。CDN 也是反向代理——你在北京访问某个网站，实际连的是北京节点上的缓存服务器，源站在美国。

有个容易混淆的地方：代理方向是相对于请求的流向而言的。正向代理是“客户端→代理→服务器”，代理跟着客户端走。反向代理是“客户端→代理→服务器”，但代理跟着服务器走。光看箭头方向一样，区别在于代理部署在谁的信任域里。正向代理通常由客户端自己配置或客户端所在网络部署，反向代理由服务提供方部署。

实际工作中两者经常同时出现。比如你用公司 VPN 回家加班，VPN 对你来说是正向代理（你通过它进入公司网络），对公司的内部 Wiki 来说可能又经过了反向代理层。再比如微服务架构里，API Gateway 对外是反向代理，但如果它需要调用第三方支付接口，它自己又成了正向代理的客户端。

配置上的直觉也不一样。正向代理要处理客户端的认证和权限，因为得知道谁在用。反向代理要处理后端的健康检查和负载均衡，因为得知道哪台机器还活着。正向代理的日志里记录的是用户访问了哪些站点，反向代理的日志里记录的是哪些请求被分发到了哪台后端。

我自己的习惯是：需要“替我去访问”的场景想正向代理，需要“替我接待”的场景想反向代理。去和来，方向不同，职责就不同。