我的 Nginx 负载均衡踩坑记：如何优雅配置多个反向代理

大家好，我是 33blog 的运维小哥。上周公司业务扩张，需要同时对接三个后端服务集群，这让我在 Nginx 配置上折腾了好几天。今天就把这次配置多个反向代理的实战经验分享给大家，特别是那些容易踩坑的细节。

业务场景与需求分析

我们有个电商平台需要同时对接：商品服务（3个节点）、用户服务（2个节点）、支付服务（特殊节点）。最要命的是这三个服务的 API 路径前缀都是 /api/，但需要根据不同的业务路由到不同的后端集群。

刚开始我天真地想用简单的 proxy_pass 搞定，结果发现请求像无头苍蝇一样乱窜。经过多次测试，终于摸索出一套可行的方案。

核心配置方案

关键点在于使用 map 指令 + 请求头标记的方式实现智能路由。下面是核心配置：

# 定义后端服务器组
upstream product_servers {
    server 192.168.1.10:8000;
    server 192.168.1.11:8000;
    server 192.168.1.12:8000;
}

upstream user_servers {
    server 192.168.2.10:8001;
    server 192.168.2.11:8001;
}

# 特殊支付服务
upstream payment_server {
    server 10.0.0.10:8443;
}

# 智能路由映射
map $http_x_service_type $backend {
    default        product_servers;
    "user"         user_servers;
    "payment"      payment_server;
}

server {
    listen 80;
    
    location /api/ {
        proxy_pass http://$backend;
        # 必须加上这个才能正确传递Host头
        proxy_set_header Host $host;
    }
}

那些年我踩过的坑

1. 502 Bad Gateway 连环案：最初忘记设置 proxy_set_header Host，导致后端服务无法识别请求来源。这个错误花了我两小时排查。

2. 神秘的负载不均衡：默认的轮询策略在某个服务节点宕机时会出现请求堆积。后来加上了 max_fails=2 fail_timeout=30s 参数才解决。

3. 路径重写噩梦：支付服务需要特殊的 /v3/ 前缀，最终用 rewrite 规则在 location 块内搞定：

location /api/payment/ {
    rewrite ^/api/payment/(.*) /v3/$1 break;
    proxy_pass http://payment_server;
}

监控与调优建议

配置完成后，我通过三个工具进行监控：

• Nginx 的 stub_status 模块看基础指标
• Prometheus + Grafana 监控各后端响应时间
• 自定义日志格式记录 $upstream_addr 分析路由情况

有个实用技巧：在测试环境用 echo 模块输出调试信息，比看日志高效多了：

location /debug {
    echo "当前路由到: $backend";
    echo "实际后端: $upstream_addr";
}

最终效果

经过这番折腾，现在系统可以：

1. 根据 X-Service-Type 请求头自动路由
2. 支付服务有独立的重写规则
3. 节点故障时自动剔除（30秒后重试）
4. QPS 从单机 800 提升到 2300+

这次经历让我明白，Nginx 的灵活配置需要结合具体业务场景。下次如果再遇到类似需求，我可能会考虑直接上 Kubernetes Ingress 了（笑）。如果大家有更好的方案，欢迎在评论区交流！