Nginx 配一行 proxy_pass，代理流量就拐了个弯。软件这是代理很多人对反向代理的第一印象——简单、直接、软件像个路标。代理但真正在生产环境里跑起来，软件你会发现这个"路标"背后藏着不少门道。代理

反向代理的软件核心逻辑其实不复杂：客户端以为自己在跟一台服务器说话，实际上中间隔了个"中间人"，代理这个中间人替客户端去跟真正的软件后端服务器打交道。关键点在于，代理客户端对此毫不知情。软件正向代理是代理替客户端出面，反向代理是软件替服务器出面。方向不同，代理玩法完全不同。

为什么不用正向代理？

有人会问，既然都是代理，为什么不用正向的？因为场景不一样。正向代理的典型用例是翻墙、缓存、匿名访问，客户端知道自己在用代理。反向代理的目标是隐藏后端架构、负载均衡、SSL 终止、缓存静态资源。你访问淘宝的时候，不会知道请求最终落到了哪台服务器上，这就是反向代理在干活。

我最早接触反向代理是在一个小项目上。当时后端有三台机器，前端只有一个域名。最笨的办法是用 DNS 轮询，但问题是某台机器挂了，DNS 不会自动剔除。换成 Nginx 做反向代理之后，健康检查一开，挂掉的节点自动下线，流量打到剩下的机器上。整个过程前端无感知。那一刻我才真正理解反向代理的价值——它不只是转发，还在做决策。

Nginx 和 HAProxy 的取舍

说到反向代理软件，Nginx 和 HAProxy 是两个绕不开的名字。Nginx 更像一把瑞士军刀，静态文件服务、反向代理、SSL 终止、URL 重写，什么都能干。HAProxy 则专注在负载均衡这一件事上，TCP 层和 HTTP 层的转发效率极高，配置也更贴近"代理"这个本质。

我个人的判断是：如果你的场景里还需要处理静态资源、做缓存、搞 URL 规则，Nginx 更顺手。如果纯粹是做四层或七层的负载均衡，后端服务已经很干净，HAProxy 的性能和稳定性更让人放心。当然，现在 Envoy 也在快速崛起，尤其在服务网格的场景下，Sidecar 模式让反向代理变成了每个 Pod 的标配。这是另一个话题了。

配置里容易踩的坑

拿 Nginx 举例，proxy_pass 后面加不加斜杠，行为完全不同。proxy_pass http://backend; 和 proxy_pass http://backend/; 在路径拼接上的差异，坑过不少人。还有 proxy_set_header 这一组指令，如果不把 Host、X-Real-IP、X-Forwarded-For 传下去，后端拿到的客户端 IP 全是代理机的地址，日志分析直接废掉。

超时设置也是重灾区。proxy_read_timeout 默认 60 秒，遇到大文件上传或者长轮询接口，分分钟给你断掉。我见过一个团队排查了半天，最后发现是反向代理的超时比后端服务的超时短，请求还没处理完就被代理掐了。这种问题不复杂，但隐蔽。

WebSocket 和长连接

HTTP/1.1 的 Connection: upgrade 头在反向代理里需要额外配置。Nginx 要显式设置 proxy_http_version 1.1 和 proxy_set_header Upgrade $http_upgrade，否则 WebSocket 握手直接失败。这个细节在文档里写得清楚，但第一次配的时候很容易漏掉。

反向代理软件说到底是个基础设施组件，平时不出问题的时候你感觉不到它的存在，一旦出问题就是全站级别的。选型、配置、监控，每一步都得认真对待。别等到线上 502 了才去翻文档。