在现代Web架构中，Nginx的反向代理与负载均衡是支撑高可用、高并发服务的核心能力。无论是将静态资源请求转发给CDN，还是将动态请求分发到多台后端服务器，这两个功能都能帮你解决"单点故障"和"性能瓶颈"问题。本文将从反向代理基础配置、参数优化、负载均衡策略三个维度，结合真实业务场景（如API服务、静态资源代理），用通俗的语言和可落地的示例，带初学者快速掌握Nginx这两大核心技能。

一、先搞懂：什么是反向代理？为什么需要它？

在讲配置之前，我们先理清一个关键概念：反向代理（Reverse Proxy）。

1.1 反向代理 vs 正向代理：一张图看懂区别

很多初学者会混淆"反向代理"和"正向代理"，其实两者的核心区别在于"代理的对象不同"：

  • 正向代理：代理客户端（比如你用VPN访问国外网站，VPN就是正向代理，替你向目标服务器发起请求）；
  • 反向代理：代理服务器（比如用户访问www.xxx.com，Nginx先接收请求，再转发给后端的Tomcat服务器，用户看不到后端服务器的真实地址）。

用一张图对比更直观：

反向代理
正向代理
通过VPN
反向代理服务器/Nginx
用户
后端服务器1/Tomcat
后端服务器2/Tomcat
正向代理服务器
用户
目标网站服务器

1.2 为什么需要反向代理？3个真实业务场景

反向代理不是"花架子"，而是解决实际问题的工具，以下是3个最常见的应用场景：

场景1：隐藏后端服务器地址，提高安全性

如果直接暴露后端服务器的IP和端口（比如192.168.1.100:8080），容易遭受恶意攻击（如端口扫描、DDoS）。通过Nginx反向代理，用户只需要访问Nginx的地址（如www.xxx.com），后端服务器的真实地址对用户完全不可见。

场景2：实现动静分离，提升性能

静态资源（HTML、CSS、JS、图片）和动态资源（Java、Python接口）的处理方式不同：

  • 静态资源适合用Nginx直接返回（Nginx处理静态资源的性能比Tomcat高10倍以上）；
  • 动态资源需要转发给后端应用服务器（如Tomcat、Django）处理。

通过反向代理，可以轻松实现"动静分离"：

  • 请求www.xxx.com/static/（静态资源）：Nginx直接返回本地文件；
  • 请求www.xxx.com/api/（动态接口）：Nginx转发给后端Tomcat服务器。
场景3：解决跨域问题

前端项目（如Vue、React）在开发阶段调用后端API时，经常会遇到"跨域错误"（浏览器的同源策略限制）。此时可以用Nginx反向代理，将前端的请求转发给后端，因为服务器之间的通信不存在跨域限制。

二、反向代理配置实战：从基础到优化

理解了反向代理的作用后，我们开始实战配置。Nginx的反向代理主要通过proxy_pass指令实现，核心是"匹配指定请求路径，转发到目标地址"。

2.1 基础配置：3行代码实现API反向代理

假设我们有一个后端API服务，地址是http://192.168.1.100:8080，现在需要通过Nginx将www.xxx.com/api/路径的请求转发到这个API服务。

步骤1：编写反向代理配置

打开Nginx的虚拟主机配置文件（包管理安装默认在/etc/nginx/conf.d/default.conf），添加以下配置：

server {
    listen 80;                  # Nginx监听80端口
    server_name www.xxx.com;    # 你的域名（本地测试可修改/etc/hosts映射）

    # 反向代理配置：匹配/api/开头的请求
    location /api/ {
        proxy_pass http://192.168.1.100:8080/;  # 转发到后端API服务
        # 注意：proxy_pass末尾的"/"有特殊含义，下文会讲
    }
}
步骤2：关键参数说明
  • location /api/：匹配所有以/api/开头的请求（如/api/user、/api/order）；
  • proxy_pass http://192.168.1.100:8080/：将匹配的请求转发到后端API服务，这里有个关键细节：
    • 如果proxy_pass末尾加了/，表示将location匹配的路径（/api/）去掉后转发。例如：
      • 用户请求www.xxx.com/api/user → 转发到http://192.168.1.100:8080/user；
    • 如果proxy_pass末尾不加/，表示将完整的请求路径转发。例如：
      • 用户请求www.xxx.com/api/user → 转发到http://192.168.1.100:8080/api/user。
步骤3：验证配置
  1. 检查配置语法是否正确：
    nginx -t  # 输出"test is successful"表示正确
  2. 重载Nginx配置（无需重启，不中断服务）：
    nginx -s reload
  3. 测试反向代理是否生效：
    # 用curl访问Nginx的/api路径，查看是否转发到后端
curl http://www.xxx.com/api/user
# 如果返回后端API的响应结果，说明配置成功

2.2 进阶优化：避免踩坑的5个核心参数

基础配置只能实现"转发功能"，但在生产环境中，还需要优化超时、请求头、缓存等参数，否则会出现"后端服务超时导致Nginx报错"、"后端无法获取真实用户IP"等问题。

2.2.1 超时设置：防止后端卡死后Nginx一直等待

如果后端服务处理请求耗时过长（比如查询大数据），Nginx会一直等待响应，导致连接占用，影响其他请求。通过以下参数设置超时时间：

location /api/ {
    proxy_pass http://192.168.1.100:8080/;
    
    # 1. 与后端服务器建立连接的超时时间（默认60秒，建议30秒）
    proxy_connect_timeout 30s;
    
    # 2. 等待后端服务器返回响应的超时时间（默认60秒，根据业务调整）
    proxy_read_timeout 60s;
    
    # 3. 向后端服务器发送请求的超时时间（默认60秒）
    proxy_send_timeout 60s;
}

实战场景：如果你的后端API有批量数据导出功能（耗时可能超过60秒），需要将proxy_read_timeout调大（如180s），避免Nginx提前断开连接。

2.2.2 请求头转发：让后端获取真实用户信息

默认情况下，Nginx转发请求时，会修改部分HTTP请求头，导致后端服务无法获取用户的真实IP、原始域名等信息。例如：

  • 后端通过request.getRemoteAddr()获取到的IP是Nginx的IP，不是用户的真实IP；
  • 后端通过request.getServerName()获取到的域名是192.168.1.100，不是用户访问的www.xxx.com。

通过proxy_set_header指令转发关键请求头，解决这个问题：

location /api/ {
    proxy_pass http://192.168.1.100:8080/;
    
    # 1. 转发用户真实IP（后端通过X-Real-IP获取）
    proxy_set_header X-Real-IP $remote_addr;
    
    # 2. 转发用户IP链（如果有多层代理，后端通过X-Forwarded-For获取）
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    
    # 3. 转发用户访问的原始域名（后端通过Host获取）
    proxy_set_header Host $host;
    
    # 4. 转发用户使用的协议（HTTP/HTTPS，后端通过X-Forwarded-Proto获取）
    proxy_set_header X-Forwarded-Proto $scheme;
}

后端获取真实IP示例（Java）：

// 通过X-Real-IP获取用户真实IP
String realIp = request.getHeader("X-Real-IP");
if (realIp == null || realIp.isEmpty()) {
    realIp = request.getRemoteAddr(); //  fallback
}
2.2.3 缓存配置：减轻后端压力，提升响应速度

对于不经常变化的请求（如商品详情页、接口静态数据），可以通过Nginx缓存后端响应结果，后续相同请求直接从Nginx返回，无需转发到后端，减轻后端压力。

配置示例：

# 1. 先定义缓存目录和规则（在http块中配置，全局生效）
http {
    # 缓存目录：/var/cache/nginx/api_cache，内存缓存100MB，磁盘缓存1GB，缓存有效期10分钟
    proxy_cache_path /var/cache/nginx/api_cache 
                    levels=1:2  # 目录层级（1级目录+2级子目录，避免单目录文件过多）
                    keys_zone=api_cache:100m  # 内存缓存区名称和大小
                    max_size=1g  # 磁盘缓存最大容量
                    inactive=10m;  # 缓存10分钟内未被访问则清理

    server {
        listen 80;
        server_name www.xxx.com;

        # 2. 在location中启用缓存
        location /api/ {
            proxy_pass http://192.168.1.100:8080/;
            
            # 启用缓存，使用上面定义的api_cache缓存区
            proxy_cache api_cache;
            
            # 缓存的key：用请求方法+URI+参数作为key（确保不同请求不冲突）
            proxy_cache_key "$request_method$request_uri$args";
            
            # 哪些状态码的响应需要缓存（200成功、304未修改）
            proxy_cache_valid 200 304 10m;
            
            # 缓存命中时，在响应头添加X-Proxy-Cache标识（便于调试）
            add_header X-Proxy-Cache $upstream_cache_status;
        }
    }
}

测试缓存是否生效：

  1. 第一次访问http://www.xxx.com/api/goods/123，查看响应头：
    • X-Proxy-Cache: MISS（未命中缓存，转发到后端）；
  2. 第二次访问相同地址，响应头变为：
    • X-Proxy-Cache: HIT（命中缓存，直接从Nginx返回）。
2.2.4 缓冲区配置：优化大请求处理

当后端返回的响应体较大（如大文件、批量数据）时，Nginx会先将响应存到缓冲区，再逐步返回给用户，避免直接转发导致的网络阻塞。通过以下参数优化缓冲区：

location /api/ {
    proxy_pass http://192.168.1.100:8080/;
    
    # 1. 单个缓冲区大小（建议设为4KB或8KB，与系统页大小一致）
    proxy_buffer_size 4k;
    
    # 2. 缓冲区总大小（默认是proxy_buffer_size的8倍，可根据需求调整）
    proxy_buffers 8 4k;
    
    # 3. 大响应时的临时文件大小（超过缓冲区的内容存到临时文件）
    proxy_temp_file_write_size 16k;
}
2.2.5 错误页面跳转：提升用户体验

如果后端服务故障（如502 Bad Gateway、504 Gateway Timeout），Nginx会返回默认的错误页面，体验较差。可以通过error_page指令自定义错误页面：

location /api/ {
    proxy_pass http://192.168.1.100:8080/;
    
    # 1. 当后端返回502/504错误时，跳转到自定义的50x.html页面
    error_page 502 504 /50x.html;
    
    # 2. 配置50x.html页面的路径（Nginx本地静态文件）
    location = /50x.html {
        root /usr/share/nginx/html;  # 页面存放目录
        internal;  # 只允许内部跳转，不允许用户直接访问
    }
}

自定义50x.html示例：

<!DOCTYPE html>
<html>
<head>
    <title>服务暂时不可用</title>
    <style>
        h1 { color: #e74c3c; text-align: center; margin-top: 100px; }
        p { text-align: center; color: #34495e; }
    </style>
</head>
<body>
    <h1>502 Bad Gateway</h1>
    <p>服务正在维护，请稍后再试~</p>
</body>
</html>

2.3 实战案例：静态资源反向代理（对接CDN）

除了转发动态API，反向代理还常用于静态资源代理。例如，将www.xxx.com/static/路径的请求转发到CDN，减轻源站压力。

配置示例：

server {
    listen 80;
    server_name www.xxx.com;

    # 静态资源反向代理到CDN
    location /static/ {
        # CDN地址（替换为你的CDN域名）
        proxy_pass http://cdn.xxx.com/static/;
        
        # 超时设置（静态资源加载快，超时时间可短一些）
        proxy_connect_timeout 10s;
        proxy_read_timeout 15s;
        
        # 缓存配置（静态资源缓存有效期7天）
        proxy_cache static_cache;
        proxy_cache_key "$request_uri";
        proxy_cache_valid 200 304 7d;
        add_header X-Proxy-Cache $upstream_cache_status;
    }

    # 动态API转发到后端服务器
    location /api/ {
        proxy_pass http://192.168.1.100:8080/;
        # 其他参数（超时、请求头）省略...
    }
}

效果：用户访问www.xxx.com/static/img/logo.png时，Nginx会转发到cdn.xxx.com/static/img/logo.png，由CDN返回静态资源，源站只处理动态API请求，负载大幅降低。

三、负载均衡实战：解决单点故障，提升并发能力

当后端服务的并发量越来越高，单台服务器无法承载时，就需要部署多台后端服务器，通过Nginx的负载均衡（Load Balancing） 将请求分发到不同服务器，实现"分流减压"和"高可用"。

3.1 什么是负载均衡？用生活例子理解

举个生活例子：你去银行办理业务，只有1个窗口（单台服务器）时，所有人都要排队；如果开3个窗口（多台服务器），大家会分到不同窗口办理，效率提升，而且即使1个窗口关闭（服务器故障），其他窗口还能正常工作（高可用）。

Nginx的负载均衡就是这个原理，通过upstream模块定义后端服务器集群，再通过proxy_pass转发请求到集群，由Nginx决定将请求分发到哪台服务器。

3.2 基础配置：3步实现负载均衡

假设我们有3台后端API服务器，地址分别是：

  • 192.168.1.100:8080（服务器A）
  • 192.168.1.101:8080（服务器B）
  • 192.168.1.102:8080（服务器C，备用）

现在需要通过Nginx将请求分发到这3台服务器，配置步骤如下：

步骤1：定义后端服务器集群（upstream块）

在Nginx的http块中，用upstream指令定义后端集群（名称自定义，这里叫backend_api）：

http {
    # 1. 定义后端服务器集群
    upstream backend_api {
        server 192.168.1.100:8080;  # 服务器A：默认权重1
        server 192.168.1.101:8080 weight=2;  # 服务器B：权重2
        server 192.168.1.102:8080 backup;  # 服务器C：备用（主服务器都故障时启用）
    }

    server {
        listen 80;
        server_name www.xxx.com;

        # 2. 将/api/请求转发到后端集群
        location /api/ {
            proxy_pass http://backend_api/;  # 这里用集群名称替代单个服务器地址
            # 其他优化参数（超时、请求头）省略...
        }
    }
}
步骤2：关键参数说明
  • upstream backend_api：定义一个名为backend_api的服务器集群；
  • server 192.168.1.100:8080：集群中的一台后端服务器，默认权重为1；
  • weight=2：设置服务器的权重，权重越高，接收的请求越多（适合服务器性能不均的场景）；
  • backup：标记为备用服务器，只有当所有非备用服务器都故障时，才会转发请求到这台服务器。
步骤3：验证负载均衡效果
  1. 检查配置并重载Nginx：
    nginx -t && nginx -s reload
  2. 多次访问API接口，查看请求是否分发到不同服务器：
    # 连续访问5次，查看后端服务器的访问日志
for i in {1..5}; do curl http://www.xxx.com/api/user; done
  3. 查看后端服务器日志（以Tomcat为例，日志路径/usr/local/tomcat/logs/access.log）：
    • 服务器A（权重1）会收到1-2次请求；
    • 服务器B（权重2）会收到3-4次请求；
    • 服务器C（备用）不会收到请求（除非A和B都故障）。

3.3 4种负载均衡算法：按需选择

Nginx默认使用"轮询"算法分发请求，但在不同业务场景下，需要选择更合适的算法。以下是4种常用算法的对比和实战场景：

3.3.1 轮询（默认）：按顺序分发，适合服务器性能一致的场景
  • 原理：将请求按顺序依次分发到集群中的每台服务器（1→2→3→1→2→3…）；
  • 适用场景：所有后端服务器的配置（CPU、内存、带宽）相同，如用相同规格的云服务器部署同一服务；
  • 配置：无需额外参数，默认就是轮询：
    upstream backend_api {
    server 192.168.1.100:8080;  # 1
    server 192.168.1.101:8080;  # 2
    server 192.168.1.102:8080;  # 3
}
  • 注意：如果某台服务器故障，Nginx会自动跳过它，将请求分发到其他正常服务器（默认10秒后重试故障服务器）。
3.3.2 权重（weight）：按比例分发，适合服务器性能不均的场景
  • 原理：根据服务器的权重值，按比例分发请求，权重越高，接收的请求越多；
  • 适用场景：后端服务器性能不一致，比如用高配服务器（8核16G）和低配服务器（4核8G）混合部署；
  • 配置示例：
    upstream backend_api {
    server 192.168.1.100:8080 weight=1;  # 低配服务器：接收1/4请求
    server 192.168.1.101:8080 weight=2;  # 中配服务器：接收2/4请求
    server 192.168.1.102:8080 weight=1;  # 低配服务器：接收1/4请求
}
  • 效果：每4个请求中，1个到A，2个到B，1个到C，充分利用高配服务器的性能。
3.3.3 ip_hash：按客户端IP哈希，实现会话保持
  • 原理：根据客户端的IP地址进行哈希计算，将相同IP的请求始终分发到同一台服务器；
  • 适用场景：需要"会话保持"的业务，比如用户登录后，后续请求需要访问同一台服务器获取会话信息（如未使用Redis共享会话的场景）；
  • 配置示例：
    upstream backend_api {
    ip_hash;  # 启用ip_hash算法
    server 192.168.1.100:8080;
    server 192.168.1.101:8080;
    server 192.168.1.102:8080 down;  # down：标记为永久下线，不接收请求
}
  • 注意事项：
    • 如果某台服务器故障，需要手动标记为down，否则相同IP的请求会分发到故障服务器，导致报错；
    • 不适合动态增减服务器的场景（新增服务器后，哈希结果会变化，会话会丢失）。
3.3.4 least_conn：优先分发到连接数最少的服务器，适合请求处理时间不均的场景
  • 原理：实时统计每台服务器的当前连接数，将新请求分发到连接数最少的服务器；
  • 适用场景：后端服务器处理请求的时间差异较大（如有的请求耗时1秒，有的耗时10秒），比如电商平台的"商品详情"和"订单支付"接口混合部署；
  • 配置示例：
    upstream backend_api {
    least_conn;  # 启用least_conn算法
    server 192.168.1.100:8080;
    server 192.168.1.101:8080;
    server 192.168.1.102:8080 backup;
}
  • 优势：相比轮询，能更均匀地分配负载，避免某台服务器因处理慢请求导致连接堆积。

3.4 高级优化：健康检查与故障自动切换

默认情况下，Nginx只会在请求分发失败时，才会认为服务器故障，这种"被动检测"会导致部分用户遇到报错。通过主动健康检查，Nginx可以定期检测后端服务器的状态，提前剔除故障服务器，提升服务可用性。

3.4.1 基础健康检查（Nginx开源版）

Nginx开源版没有内置的主动健康检查模块，但可以通过proxy_next_upstream指令实现"失败重试"，减少报错概率：

upstream backend_api {
    server 192.168.1.100:8080;
    server 192.168.1.101:8080;
}

location /api/ {
    proxy_pass http://backend_api/;
    
    # 当后端返回以下状态码时，自动重试下一台服务器
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
    
    # 最多重试2次（避免无限重试）
    proxy_next_upstream_tries 2;
    
    # 重试间隔（避免短时间内频繁重试）
    proxy_next_upstream_timeout 3s;
}
  • proxy_next_upstream：定义哪些情况需要重试下一台服务器（如超时、502错误）；
  • proxy_next_upstream_tries：最多重试次数（建议2-3次，过多会增加延迟）。
3.4.2 高级健康检查（Nginx Plus/第三方模块）

如果需要更强大的健康检查功能（如定期发送GET/POST请求检测服务状态），可以使用：

  • Nginx Plus（商业版）：内置health_check模块，支持HTTP/HTTPS/TCP健康检查；
  • 第三方模块（如ngx_http_healthcheck_module）：开源免费，需源码编译安装。

Nginx Plus健康检查配置示例：

upstream backend_api {
    server 192.168.1.100:8080;
    server 192.168.1.101:8080;
    
    # 主动健康检查：每5秒发送一次GET /health请求，超时2秒，3次失败则标记为故障
    health_check interval=5s fails=3 passes=2 timeout=2s;
    # 检查的URL（后端需提供健康检查接口，返回200表示正常）
    health_check_uri /health;
}

后端健康检查接口示例（Java）：

// 健康检查接口，返回200表示服务正常
@RequestMapping("/health")
public ResponseEntity<String> healthCheck() {
    return ResponseEntity.ok("OK");
}

四、避坑指南：初学者常犯的5个错误

  1. proxy_pass末尾的/使用不当
    错误：将proxy_pass http://backend_api（无/）配置为proxy_pass http://backend_api/（有/），导致请求路径错误。
    解决：明确业务需求，确定是否需要去掉location匹配的路径，建议先在测试环境用curl验证。

  2. 未转发请求头，导致后端无法获取真实IP
    错误：后端获取到的IP是Nginx的IP，不是用户真实IP。
    解决：添加proxy_set_header X-Real-IP $remote_addr;和X-Forwarded-For。

  3. 权重配置不合理，导致高配服务器负载过低
    错误：给高配服务器和低配服务器设置相同权重，浪费资源。
    解决：根据服务器性能（CPU核数、内存）调整权重，如高配设为2，低配设为1。

  4. ip_hash算法下，服务器故障未标记down
    错误：某台服务器故障后，相同IP的请求仍会分发到故障服务器，导致报错。
    解决：及时将故障服务器标记为down，或使用least_conn算法。

  5. 未设置超时时间，导致连接堆积
    错误：后端服务卡死后，Nginx一直等待响应，连接占用过多。
    解决：设置proxy_connect_timeout、proxy_read_timeout，建议不超过60秒。

五、总结：反向代理与负载均衡的核心价值

  • 反向代理：隐藏后端地址、实现动静分离、解决跨域问题，是连接用户和后端服务的"中间层"；
  • 负载均衡：分发请求、避免单点故障、提升并发能力，是支撑高可用服务的"调度中心"。

掌握这两个功能后，你可以搭建更稳定、更高效的Web架构，比如：

  • 小型项目：Nginx + 1台后端服务器（反向代理+静态资源服务）；
  • 中型项目：Nginx + 3台后端服务器（负载均衡+健康检查）；
  • 大型项目：Nginx（反向代理）+ CDN（静态资源）+ 多区域后端集群（负载均衡）。

建议初学者先在本地虚拟机搭建测试环境，通过nginx -t检查配置，用curl和日志验证效果，逐步积累实战经验。

# nginx # 负载均衡
Logo
乐奇 Rokid 开放社区

更多推荐

cover

让界面替我“摇“一次：一个AR祈愿智能体的AIUI实践

avatar 乐奇 Rokid 开放社区
cover

AR 智能眼镜并不是简单地在眼前放一块屏幕，而是把**摄像头、传感器、计算机视觉、空间定位、语音交互和云端服务**连接起来

avatar 乐奇 Rokid 开放社区

智能眼镜市场全景解析：从技术演进到产业格局

本文系统梳理智能眼镜市场，涵盖产品形态、技术演进、市场规模、产业链结构及竞争格局。指出智能眼镜正从音频交互向AR显示与空间计算演进，受AI大模型、供应链成熟与生态延伸驱动，呈现分层发展态势。虽面临场景刚需不足、续航重量矛盾与隐私挑战，但B端应用先行、AI原生设计与标准完善将推动行业迈向规模化渗透，未来需关注核心技术突破与真实使用数据。

avatar 乐奇 Rokid 开放社区