反向代理

可视化演示

交互对比四层(L4)与七层(L7)反向代理的请求转发过程，展示负载均衡、SSL卸载、健康检查与后端服务器选择策略。

前台角色定位

想象你入住一家五星级酒店。你不会拎着行李冲进后厨找主厨，也不会跑去洗衣房催床单。你只会站在大堂前台，报上姓名，递出身份证。前台小姐接过需求，转身安排一切。这家酒店所有对外服务的门面只有一个——前台。而在网站架构里，反向代理就是这个前台。它站在所有用户请求与后端服务器之间，成为唯一的“入口接待”。

反向代理（Reverse Proxy）接收客户端的请求，再转发给内部服务器，并把服务器的响应原路送回。之所以叫“反向”，是因为它与正向代理的立场完全相反。正向代理代表客户端，替用户访问外部世界，比如你在浏览器里配置的VPN代理；反向代理代表服务器端，替后端接待外部访客。用户能感知到自己在用正向代理，却感知不到背后有一个反向代理——它把多台服务器包装成一个“虚拟前台”。

一个典型的请求转发路径是：客户端 → 反向代理 → 后端服务器 → 反向代理 → 客户端。代理层承担了统一入口、请求分发和响应回传。站在这个位置，它能看到所有流量，因此可以做限流、鉴权、安全过滤；它挡在后端前面，因此可以隐藏后端真实IP，起到隔离保护作用。

请求总延迟由三段构成：

前台小姐每接待一位客人，也要先听清需求、确认房态、联系对应部门。客人等待的时间等于走进大堂的时间、前台沟通的时间、内部响应的时间之和。一个好前台会压缩自己那一部分，并让内部响应更快。反向代理做的正是这两件事：压缩代理自身的开销，并让后端服务器更快、更稳地响应。

四层七层差异

同样是前台，有两种接待风格。一种只看一眼你的房卡号就指个方向让你自己过去，速度快但不知道你要干什么；另一种会认真听你说完诉求，再帮你联系具体部门，服务到位但稍慢。这两种风格，对应着网络世界里四层代理与七层代理的分野。

网络协议从上到下分七层。四层代理工作在传输层，只解析源IP、目标IP、源端口、目标端口，完全不关心包里的内容；七层代理工作在应用层，能读懂URL、请求头、Cookie和正文。Nginx是典型的七层代理，而LVS、HAProxy则常作为四层代理使用。选四层还是七层，本质上是在“转发速度”与“理解深度”之间做权衡。

四层代理的数据转发基于四元组。它像一个快递中转站，只看信封上的地址、不拆信，因此吞吐高、延迟低；但它无法根据请求内容做出智能路由，比如把图片请求发给图片服务器、把API请求发给应用服务器。七层代理则能拆开信封读内容，按路径、域名甚至Header分流，还能做更细粒度的限流和改写，代价是每一层协议解析都消耗CPU。

想象酒店同时设了两道前台：快速通道只看房卡号就放行，VIP接待室则详细记录需求再分配管家。着急的客人走快速通道，不赶时间的走VIP通道——聪明的酒店让两种前台共存，正如成熟的架构会让四层和七层代理各司其职。

Nginx核心功能

前台小姐桌上有一本“排班手册”，上面记录着每位服务员的忙闲程度和擅长领域。新客人进门，她快速瞄一眼手册，把客人分配给此刻最合适的人。Nginx的请求路由和负载均衡，就是这本排班手册的数字化版本。

Nginx作为最流行的七层反向代理，核心能力是“把请求分发给多个后端服务器”。它通过upstream块定义一组后端，再通过负载均衡策略决定下一个请求交给谁。最简单的策略是加权轮询：每台服务器有一个权重数字，权重越高被选中的次数越多。这就像排班手册里标注“老员工每小时能接待3位客人，新员工只能接待1位”。

除了加权轮询，Nginx还支持最少连接数策略，把请求分给当前活跃连接最少的服务器，避免某台机器被压垮；还支持ip_hash策略，让同一IP固定访问同一后端。生产环境通常按机器配置设定权重：CPU强、内存大的机器权重设高一些，让资源利用率最大化。请求路由则可以根据URL前缀、域名、Header将流量导向不同的后端组，实现“图片走图床、接口走应用服务”的拆分。

排班手册的核心智慧在于“按能力排班”而不是“轮流排班”。加权轮询让3倍资源的服务器承担3倍流量，这是一种朴素的资源匹配思想。Nginx把前台的经验固化成算法，任何时刻都能快速决策，而且永远不知疲倦。

SSL卸载安全

入住酒店时，行李员会主动帮你接过沉重的箱子，你只需要轻装走进房间。SSL/TLS加密就是那个沉重箱子——加解密运算非常消耗CPU。反向代理的SSL卸载功能，就是前台帮你接过箱子，把最沉重的加密解密工作承担下来，让后端服务器专注于业务逻辑。

正常HTTPS通信需要经过完整的TLS握手：协商加密套件、交换证书、生成会话密钥。这个过程涉及非对称加密和证书链校验，开销很大。如果每台后端服务器都独立做一遍，性能会大打折扣。反向代理可以在代理层统一终止SSL——解密后再把普通HTTP请求转发给内网后端。后端之间走内网明文传输，既省掉了加解密成本，又因为流量不出内网而相对安全。

SSL卸载的另一个好处是证书统一管理。多个域名、多台服务器不必各自配置证书，只需在代理处统一部署。结合自动化证书工具，甚至可以做到证书自动续期。代价是：代理与后端之间的链路若被攻破，明文流量会暴露。因此成熟方案会在代理到后端之间再加一层网络隔离或隧道加密。

行李员的存在让客人入住体验大幅提升，客人甚至感觉不到自己省了多少力气。SSL卸载也是如此——用户感知不到加密细节，后端服务器却实实在在减轻了负担。前台扛下了最重的箱子，后面的人才能跑得更快。

健康检查机制

前台小姐有一本“房间状态簿”，每隔几分钟就给客房部打电话确认：“301退房了吗？502需要清洁吗？”一旦某间房连续多次无人接听，她就果断在状态簿上标注“暂不可用”，绝不把新客人安排进去。健康检查，正是代理对后端服务器的这套“电话确认”。

后端服务器可能因为过载、崩溃、网络抖动而暂时无法服务。如果代理还把请求转发过去，用户就会得到一连串错误。健康检查机制让代理动态感知后端的“生死”。Nginx中常见的做法有两种：主动检查和被动检查。主动检查是代理定期向后端发送探测请求，比如请求一个健康检查路径；被动检查是代理不主动探测，而是根据真实请求的失败次数判定——比如某台服务器连续3次返回5xx错误，就把它标记为失败。

被标记为“不可用”的后端会从转发池中摘除，同时保留恢复探测：经过一段时间或连续成功M次后，重新将其加入转发列表。这种“摘除—恢复”的闭环，让整个系统具备了自愈能力。主动检查能尽早发现问题但会占用少量带宽，被动检查零额外流量但发现问题时已积累了几个失败请求，两者常配合使用。

前台绝不让客人住进一间坏掉的房间，哪怕其他房间因此多等几分钟。这份“宁可错杀，不可错住”的谨慎，正是健康检查的精髓。它让前台不断更新对酒店内部状态的认知，永远把客人安排在最靠谱的房间。

会话保持策略

第一次入住的客人跟前台聊了很久，交代了枕头偏好、叫醒时间、忌口清单。前台会记在心里，并尽量让同一位管家全程服务。如果下次客人回来换了管家，又得重新交代一遍，双方都累。会话保持，就是让“同一个客人”始终找到“同一位管家”。

很多Web应用需要用户在多次请求间保持登录状态。虽然可以用共享Session或Token实现，但最省事的办法是让同一用户的请求始终落到同一台后端服务器。这样即使后端本地保存了Session状态，也不会因为跳到别的机器而丢失。这在有状态服务中尤其重要。

两种最常见的实现方式：IP哈希和Cookie粘滞。IP哈希对客户端IP做哈希后取模，算出固定后端编号——同一个IP永远分到同一台服务器，实现简单但存在负载不均风险。Cookie粘滞则由代理在响应中植入一个带后端标识的Cookie，后续请求带着这个Cookie，代理直接引导到对应后端。更高级的一致性哈希能在后端数量变化时只迁移少量会话，适合缓存型架构。

前台记不住三千位客人的喜好，但通过“房卡颜色”这类小技巧就能快速识别常客、找到对应管家。IP哈希和Cookie粘滞都是这个思路——用一个简单的标识符，换取一段稳定的对应关系。虽然牺牲了一点均衡性，却换来了用户体验的稳定。

缓存加速原理

客人最常问的问题前三名永远是“WiFi密码多少”“早餐几点开始”“健身房在哪”。前台把这些答案写在速查卡上，两秒就能回答，完全不用每次跑去问客房部。缓存加速，就是给高频问题准备速查卡。

后端服务器处理一个动态请求往往要查询数据库、执行业务逻辑，耗时可能几十到几百毫秒。但很多内容其实是相对固定的：图片、CSS、JS文件、热门文章的HTML页面。反向代理可以在这一层把内容缓存下来，当相同请求再次到达时，直接返回缓存结果，完全不打扰后端。

Nginx的缓存基于URI和请求头生成缓存键，配合Cache-Control、Expires等响应头判断内容可缓存性。缓存命中率是衡量缓存效果的核心指标：命中率越高，说明被“拦截”的重复请求越多。同时还要考虑失效策略：缓存不能永久有效，必须配合过期时间、版本号主动失效，否则用户会看到陈旧内容。

前台不可能把客人的每个问题都做成速查卡，只挑最高频、最稳定的那几条。缓存也一样：只缓存重复出现、内容变化慢的资源，才能在命中率和数据新鲜度之间找到平衡。好的前台懂得什么该记、什么不该记。

工程应用价值

酒店翻新了顶楼套房，不敢直接开放给所有客人，先让几位VIP试住一晚，收集反馈后再全面开放。同时，所有访客进酒店前都要先经过大堂前台，不明身份的陌生人连电梯都摸不到。这两个场景，对应反向代理在灰度发布与安全隔离上的工程价值。

安全隔离方面：反向代理作为唯一入口，屏蔽了后端服务器的真实IP和端口。外部扫描只能看到代理，很难直接触达后端。代理还可以做IP黑名单、请求频率限制、SQL注入与XSS的基本过滤，相当于前台保安的角色。灰度发布方面：代理可以在新老两套后端之间按比例分配流量，比如先切5%真实流量到新版本，观察错误率和延迟，确认稳定后逐步扩大到10%、50%、100%。

这种渐进式发布显著降低了发布风险。如果没有代理层，要让1%的用户访问新版本只能靠修改DNS或让前端做随机分流，既笨拙又不可控。有了代理层，只需调整一个权重参数，还能配合监控系统在出错时一键切回旧版本。可以说，反向代理是现代微服务架构中“进可攻、退可守”的战略要地。

VIP试住、全面开放、随时叫停——灰度发布的每一步都透着工程谨慎。而那道只有前台才能打开的门，让酒店内部布局始终不被外人看清。反向代理把这两件事统一起来：它既是最灵活的流量开关，也是最坚固的安全屏障。

AI 应用场景

Python 演示

"""简易反向代理模拟器：加权轮询 + 健康检查 + 缓存加速"""import hashlibimport random  class Backend:    """模拟一台后端服务器"""     def __init__(self, name, weight=1):        self.name = name        self.weight = weight        self.alive = True        self.fail_count = 0     def handle(self, request):        if not self.alive:            raise ConnectionError(f"{self.name} 已下线")        return f"{self.name} 处理了请求 {request}"  class ReverseProxy:    """前台：反向代理核心逻辑"""     def __init__(self, backends):        self.backends = backends     def weighted_round_robin(self):        """加权轮询：按权重随机选择一个存活后端"""        total = sum(b.weight for b in self.backends if b.alive)        r = random.uniform(0, total)        upto = 0        for b in self.backends:            if not b.alive:                continue            upto += b.weight            if r <= upto:                return b        return None     def ip_hash(self, client_ip):        """IP 哈希：同一 IP 固定打到同一后端"""        idx = int(hashlib.md5(client_ip.encode()).hexdigest(), 16) % len(self.backends)        return self.backends[idx]     def health_check(self, failure_threshold=3):        """主动健康检查：模拟探测并摘除故障节点"""        for b in self.backends:            if random.random() < 0.15:                b.fail_count += 1                if b.fail_count >= failure_threshold:                    b.alive = False            else:                b.fail_count = 0                b.alive = True     def run(self, requests):        """主流程：处理一批请求"""        results = []        cache = {}        for req in requests:            if req in cache:                results.append(f"[缓存命中] {cache[req]}")                continue            self.health_check()            backend = self.weighted_round_robin()            if backend is None:                results.append("[错误] 无可用后端")                continue            try:                resp = backend.handle(req)                cache[req] = resp                results.append(resp)            except ConnectionError as e:                results.append(str(e))        return results  if __name__ == "__main__":    backends = [        Backend("服务器A", weight=3),        Backend("服务器B", weight=2),        Backend("服务器C", weight=1),    ]    proxy = ReverseProxy(backends)    for line in proxy.run([f"请求{i}" for i in range(10)]):        print(line)

1. total = sum(b.weight for b in self.backends if b.alive)计算所有存活后端的权重总和，作为随机区间的上界。
2. r = random.uniform(0, total)生成0到总权重之间的随机数，相当于掷一次“权重骰子”。
3. upto += b.weight不断累加权重形成区间，骰子落在哪个区间就去哪台后端。
4. if b.fail_count >= failure_threshold连续失败达到阈值，判定该后端下线。
5. b.alive = False把故障后端从候选池中摘除，新请求不再发给它。
6. if req in cache缓存命中判定，命中就直接返回，不穿透到后端。
7. self.health_check()每次处理请求前先做一轮健康探测，保证只把请求发给活着的后端。
8. Backend("服务器A", weight=3)用权重表示服务器性能差异，权重越大干活越多。

常见误区

面试题