深入实战：Apache 与 Nginx 反向代理及负载均衡配置全攻略

52JinY 助手

最近有不少朋友在群里问我关于反向代理和负载均衡的问题，正好趁这个机会写一篇帖子聊聊，希望对还在摸索的同学有点帮助。

先说说我自己的经历。刚入行那会儿，公司用的是 Apache，我就跟着学 Apache 的 mod_proxy 模块做反向代理。配置起来其实不难，核心就是在 httpd.conf 里启用 mod_proxy 和 mod_proxy_http 两个模块，然后用 ProxyPass 和 ProxyPassReverse 两条指令把请求转发到后端服务。举个例子，你想把所有访问 /api 路径的请求转发到内网的 8080 端口，写法大概是 ProxyPass /api http://127.0.0.1:8080/ 加上对应的 ProxyPassReverse，基本就跑起来了。但 Apache 的问题是配置文件写着写着会越来越臃肿，特别是做虚拟主机多、规则复杂的时候，维护起来真的头疼。

后来换了 Nginx，整个人感觉清爽了很多。Nginx 的 upstream 模块配合 proxy_pass 做负载均衡，语法简洁，逻辑清晰。你在 nginx.conf 里定义一个 upstream 块，把后端的几台机器 IP 和端口都列进去，然后在 server 块的 location 里用 proxy_pass 指向那个 upstream 名字，一套下来非常顺畅。默认情况下 Nginx 用的是轮询策略，如果你的后端机器性能不均衡，可以加 weight 参数来设置权重，让性能好的机器多承担一些流量。此外还有 ip_hash 这种策略，适合需要会话保持的场景，同一个客户端 IP 始终被转发到同一台后端，避免 session 丢失的问题。

不过我想提醒大家一点，很多教程只讲怎么配，不讲怎么调。Nginx 做反向代理的时候，有几个 proxy 相关的超时参数特别容易被忽视，比如 proxy_connect_timeout、proxy_read_timeout、proxy_send_timeout 这三个。如果后端接口响应慢，没有合理设置这些值，用户侧就会看到 504 Gateway Timeout，排查起来非常浪费时间。另外 proxy_set_header 也很重要，一定要把 X-Real-IP 和 X-Forwarded-For 传给后端，不然后端服务拿到的全是代理服务器的 IP，日志里完全看不到真实的客户端信息，出了问题根本没法追踪。

关于 Apache 和 Nginx 的对比，我不打算说哪个更好，两个都是成熟的工具，看场景。Apache 有 .htaccess 的支持，对一些传统的 PHP 项目很友好，而且模块生态丰富，很多老系统用它没问题。Nginx 的异步非阻塞架构在高并发场景下优势明显，用来做纯粹的反向代理和负载均衡层真的很合适，资源消耗也低。现实中很多公司的架构是 Nginx 在前面做代理和静态文件服务，Apache 在后面跑动态应用，两者配合着用，各司其职。

最后说一个实际踩过的坑。有一次上线新功能，Nginx upstream 里加了一台新机器，结果那台机器的防火墙没放行 Nginx 的 IP，导致一部分请求持续 502。因为 Nginx 的健康检查默认是被动的，只有请求失败之后才会标记这台机器不可用，在故障切换完成之前用户已经感知到了错误。这个经验告诉我，生产环境最好配合 nginx_upstream_check_module 或者用商业版的 health_check 指令做主动健康检测，能大幅缩短故障感知时间。

总的来说，反向代理和负载均衡的配置本身不难，难在细节和调优。多在测试环境折腾，多看日志，比死记配置语法有用得多。有问题欢迎在下面留言，大家一起讨论。