Nginx 反向代理完整配置:负载均衡 + HTTPS + 缓存优化

在上一篇 《Nginx 开启 Gzip 与浏览器缓存》 里,我们解决了网站”加载快一倍”的问题。但当你要部署多个服务(前端、后端 API、微服务)时,单台 Nginx 就不够了——你需要反向代理来统一入口、做负载均衡、并强制 HTTPS。

本文是 Nginx 反向代理的实战指南,覆盖负载均衡策略、HTTPS 强制跳转、缓存优化三大核心场景,所有配置均可在生产环境直接使用。如果你还没配 SSL 证书,建议先看 《Let’s Encrypt 免费 SSL 证书自动续期》

一、什么是反向代理?

正向代理是客户端的中介(如科学上网),反向代理是服务端的中介:客户端只访问 Nginx 这一个入口,Nginx 再把请求转发给后端的多台真实服务器,并把响应返回给客户端。

  • 统一入口:对外只暴露 80/443 端口,隐藏后端真实 IP 和端口
  • 负载均衡:把流量分摊到多台后端,提升并发与可用性
  • SSL 终结:在 Nginx 层统一处理 HTTPS,后端可用 HTTP 降低开销
  • 缓存加速:对静态资源和 API 响应做缓存,减少后端压力

二、基础反向代理配置

最基础的转发,把 /api 路径代理到后端 Node.js 服务:

server {
    listen 80;
    server_name api.fsdata.site;

    location /api/ {
        proxy_pass http://127.0.0.1:3001/;
        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;
    }
}

⚠️ 坑点proxy_pass 末尾的 / 决定是否剥离匹配路径。写 http://127.0.0.1:3001/(带斜杠)会把 /api/user 转发为 /user;写 http://127.0.0.1:3001(不带斜杠)则转发为 /api/user。绝大多数场景要带斜杠。

三、负载均衡:upstream 模块

当后端有多台服务器时,用 upstream 定义服务器池并选择调度算法:

upstream backend_api {
    # 默认 round-robin 轮询
    server 10.0.0.11:3001 weight=3;   # weight 权重,处理 3 倍流量
    server 10.0.0.12:3001 weight=2;
    server 10.0.0.13:3001 backup;     # backup 仅当其他全挂才启用
    keepalive 32;                     # 复用后端连接,降低延迟
}

server {
    location /api/ {
        proxy_pass http://backend_api/;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

3.1 四种调度算法

算法配置适用场景
轮询(默认)不写后端性能均衡
加权轮询server x weight=n机器配置不均
IP 哈希ip_hash;需会话保持(如登录态)
最少连接least_conn;请求耗时差异大

⚠️ ip_hashleast_conn 不能和 backup 混用,且改算法需平滑 reload(nginx -s reload)而非重启。

四、强制 HTTPS(SSL 终结)

生产环境必须全站 HTTPS。Nginx 在 443 端口做 SSL 终结,后端用 HTTP 通信:

# HTTP 80 → 强制跳转 HTTPS
server {
    listen 80;
    server_name api.fsdata.site;
    return 301 https://$host$request_uri;
}

# HTTPS 443
server {
    listen 443 ssl http2;
    server_name api.fsdata.site;

    ssl_certificate     /etc/letsencrypt/live/api.fsdata.site/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.fsdata.site/privkey.pem;

    # 代理到后端(此时后端是 HTTP,开销更低)
    location /api/ {
        proxy_pass http://backend_api/;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
    }
}

这样后端服务无需各自配证书,证书只在 Nginx 层统一管理(配合 certbot 自动续期 即可零运维)。

五、缓存优化:proxy_cache

对不常变的内容(静态资源、API 只读响应)启用反向代理缓存,可让命中请求直接由 Nginx 返回,后端 QPS 下降 50%+:

proxy_cache_path /var/cache/nginx/api levels=1:2 keys_zone=api_cache:10m max_size=1g inactive=60m use_temp_path=off;

server {
    location /api/ {
        proxy_pass http://backend_api/;
        proxy_cache api_cache;
        proxy_cache_valid 200 10m;       # 200 响应缓存 10 分钟
        proxy_cache_valid 404 1m;
        proxy_cache_key $scheme$proxy_host$request_uri;
        add_header X-Cache-Status $upstream_cache_status;  # 调试用
    }
}

X-Cache-Status 返回 HIT(命中)、MISS(未命中)、BYPASS(绕过),是排查缓存是否生效的关键指标。

六、常见问题排查

现象原因解决
502 Bad Gateway后端未启动 / 端口错检查 upstream 服务存活
上传大文件 413默认 body 限制 1MBclient_max_body_size 50m;
WebSocket 断连缺 Upgrade 头proxy_set_header Upgrade $http_upgrade;
负载不均用了 ip_hash + backup改用 least_conn
缓存不生效Set-Cookie 响应proxy_ignore_headers Set-Cookie;

总结

一套完整的 Nginx 反向代理架构应该是:80 端口强制跳转 443 → 443 做 SSL 终结 → upstream 负载均衡 → proxy_cache 缓存加速。配合 Gzip 压缩(见 前文)和自动续期证书(见 证书教程),你的服务就具备了生产级的可用性与性能。

下一篇我们聊 Prometheus + Grafana 监控,把这套架构的运行状态可视化出来。有问题欢迎评论区交流 👇

上一篇 2026 年搭建私有 AI 知识库:Dify + Ollama 本地部署完整教程
下一篇 PostgreSQL 慢查询优化:执行计划解读与索引调优实战