图 1：本文封面，客户端只认那道门，看不见门后的真实服务。
先说明属性：这是一篇经典题解析，题目出自本地历史面试资料（原题问「使用反向代理服务器的优点是什么」），与任何公司的当前招聘无关。它看起来是名词解释，实际上考的是你能不能画清一个系统的流量入口——说不清代理层职责的人，架构图里入口永远是一团云。
想象面试现场：「反向代理和正向代理有什么区别？为什么大家都用 Nginx 做反向代理？」
核心结论一句话
正向代理站在客户端一侧，替客户端访问外面，服务端不知道真实客户端是谁；反向代理站在服务端一侧，替服务端接客，客户端不知道真实服务端是谁。记忆锚点是箭头方向相反。反向代理层通常扛着五项职责：转发与路由、负载均衡、SSL 卸载、静态缓存、限流与防护。Nginx 流行的原因不是某一项最强，而是五项职责在一个进程里都够用、配置统一、资源占用低。
先分清正反，再展开职责。
正向代理的典型场景是内网用户通过代理访问外网：目标是隐藏或放行客户端。反向代理的典型场景是用户访问一个域名，代理把请求分发给门后的一群服务器：目标是隐藏并组织服务端。一句话区分：代理替谁站着，就姓什么。
职责一：转发与路由。 按域名和路径把请求分发到不同后端，proxy_pass 指向哪里，流量就去哪里；同时用 proxy_set_header 把客户端真实 IP 以 X-Real-IP、X-Forwarded-For 的形式带给后端——代理替客户端发了请求，后端日志里不补这个头就全是代理的地址。
职责二：负载均衡。 用 upstream 声明一组后端，默认按轮询分摊；加 least_conn 改成把新请求发给当前连接最少的机器，适合请求耗时不均的场景；加 ip_hash 让同一客户端固定落到同一台，适合需要会话粘性的老系统；还可以给 server 配 weight，权重 3 的机器大约扛走五分之三的新请求。后端挂了怎么办？被动健康检查内置在代理里：连续失败达到 max_fails 次（默认 1 次），这台机器在 fail_timeout 窗口内被标记为不可用，流量自动绕开。
职责三：SSL 卸载。 证书和私钥集中配在代理层：listen 443 ssl 加上证书文件，TLS 握手与加解密全部在 Nginx 完成，后端走内网明文。官方文档明确提醒握手是 SSL 里最耗 CPU 的操作，应对办法是开 keepalive 复用连接、开共享会话缓存复用握手结果——一兆字节的会话缓存大约能存四千个会话。后端集群因此不用每台都配证书、烧 CPU 做加解密。
职责四：静态缓存。 图片和静态资源直接由代理应答或缓存，后端只处理动态请求。职责五：限流与防护。 在入口按 IP、按路径限制速率，异常流量在到达应用前就被拦下。五项合起来，反向代理成了系统的总前台。
图 2：正反代理的分工与代理层的五项职责。
可能的追问与易错点。
「负载均衡策略怎么选？」无状态服务默认轮询，耗时差异大用 least_conn，临时需要会话粘性用 ip_hash 但要知道它会把压力钉在固定机器上。「反向代理和网关在面试里怎么区分？」代理层管流量转发与防护，网关在此之上还管鉴权、编排、协议转换等业务语义，职责有重叠但抽象层级不同。易错点有三：一是把反向代理等同于负载均衡，均衡只是五项职责之一；二是忘记透传真实 IP，后端拿到的全是代理地址，风控与审计直接失真；三是 SSL 卸载后对内网明文毫无边界意识，卸载不等于放弃内网安全，敏感链路仍需二次加密或隔离。AI 应用里这套东西每天都在用：模型服务多实例的均衡、API 的 SSL 卸载与入口限流，全都落在这一层。
给你的练习：本机装一个 Nginx，起两个监听不同端口的 demo 服务，写一个 upstream 做一次轮询，再改成 least_conn 观察分发差异。十分钟，胜过背一小时名词。
你项目里的反向代理扛了几项职责？有没有踩过「后端拿不到真实 IP」的坑？欢迎分享。