Nginx反向代理配置实战：负载均衡算法与SSL终端配置方案

Nginx反向代理在DevOps实践中的核心角色

网站运维中，Nginx反向代理是最常用的流量入口组件。它承担负载均衡、SSL终端、请求路由、缓存加速等多重职责。在Kubernetes容器编排和Docker自动化部署环境中，Nginx常作为Ingress Controller或边缘网关使用。正确配置反向代理规则直接影响SRE稳定性工程中的可用性指标和响应延迟。

本文覆盖Nginx反向代理的三个核心配置场景：多后端负载均衡、SSL终端卸载、以及基于请求特征的智能路由。

负载均衡算法选择与配置

Nginx支持多种负载均衡算法，选择哪种取决于后端服务特性：

upstream backend_api {
    # 轮询（默认）：请求均匀分配
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

upstream backend_weighted {
    # 加权轮询：按服务器性能分配权重
    server 10.0.1.10:8080 weight=3;
    server 10.0.1.11:8080 weight=2;
    server 10.0.1.12:8080 weight=1;
}

upstream backend_ip_hash {
    # IP哈希：同一客户端固定访问同一后端
    ip_hash;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
}

upstream backend_least_conn {
    # 最少连接数：优先分配给当前连接数最少的后端
    least_conn;
    server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.12:8080 max_fails=3 fail_timeout=30s;
}

upstream backend_random {
    # 随机算法：随机选择后端，减少锁竞争
    random two least_conn;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

各算法的适用场景：轮询适合后端性能一致的纯无状态服务；加权轮询适合异构服务器集群；IP哈希适合需要会话保持的场景，但在后端节点变化时会导致大量会话迁移；最少连接数适合请求处理时间差异较大的场景。random two least_conn是Nginx 1.15引入的算法，随机选两个节点再从中选连接数最少的，在高并发下比纯least_conn性能更好。

健康检查与故障转移配置

开源版Nginx没有主动健康检查功能，但可以通过被动健康检查实现故障转移：

upstream backend_api {
    server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.12:8080 max_fails=3 fail_timeout=30s;
    # 备用服务器：所有主服务器宕机后启用
    server 10.0.1.20:8080 backup;
}

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://backend_api;
        proxy_connect_timeout 3s;
        proxy_read_timeout 30s;
        proxy_send_timeout 30s;
        # 代理失败时重试下一台后端
        proxy_next_upstream error timeout http_502 http_503 http_504;
        proxy_next_upstream_tries 3;
        proxy_next_upstream_timeout 10s;
    }
}

max_fails和fail_timeout组合实现被动健康检查：在fail_timeout时间内失败max_fails次，该节点被标记为不可用，fail_timeout时间后重新尝试。proxy_next_upstream配置定义哪些错误触发重试，注意不要将http_500加入重试条件，因为500错误通常是业务逻辑问题而非服务器故障。

SSL终端卸载与HTTP/2配置

SSL终端卸载将加密解密操作从后端应用服务器转移到Nginx，减轻后端CPU负担：

server {
    listen 443 ssl http2;
    server_name api.example.com;

    ssl_certificate /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_session_tickets off;
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 valid 300s;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Frame-Options DENY always;
    add_header X-Content-Type-Options nosniff always;

    location / {
        proxy_pass http://backend_api;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# HTTP重定向到HTTPS
server {
    listen 80;
    server_name api.example.com;
    return 301 https://$host$request_uri;
}

proxy_set_header中的X-Forwarded-Proto和X-Forwarded-For是后端应用获取客户端真实IP和原始协议的关键。后端框架需要正确解析这些头部，否则会导致重定向循环或日志记录错误。

基于请求特征的智能路由

在微服务架构中，Nginx可以根据请求路径、Header、参数等特征将流量路由到不同后端：

server {
    listen 443 ssl http2;
    server_name api.example.com;

    # API v1路由
    location /api/v1/ {
        proxy_pass http://backend_v1;
    }

    # API v2路由（灰度发布）
    location /api/v2/ {
        proxy_pass http://backend_v2;
    }

    # 按客户端版本Header路由
    location /api/ {
        set $upstream backend_v1;
        if ($http_x_app_version ~* "^2\.") {
            set $upstream backend_v2;
        }
        proxy_pass http://$upstream;
    }

    # 静态资源缓存
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2?)$ {
        proxy_pass http://backend_static;
        proxy_cache static_cache;
        proxy_cache_valid 200 24h;
        expires 24h;
    }

    # WebSocket支持
    location /ws/ {
        proxy_pass http://backend_ws;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 3600s;
    }
}

灰度发布场景中，通过Header或Cookie判断客户端版本并路由到不同后端是常用方案。WebSocket代理需要单独配置Upgrade头部，否则连接握手会失败。故障应急响应时，可以通过修改upstream配置快速摘除故障节点，配合nginx -s reload实现零停机切换。在CI/CD流水线中，Nginx配置变更应纳入版本控制，通过自动化部署工具推送，避免人工修改导致配置漂移。监控告警体系应覆盖Nginx的关键指标：活跃连接数、请求队列深度、后端响应时间、SSL握手失败率，配合Prometheus和Grafana构建实时可视化面板。