Nginx反向代理配置详解：多站点代理与负载均衡实战

发布时间：2026-09-09 08:58 更新时间：2026-09-09 08:58 阅读量：0

在实际建站与运维中，一台服务器往往需要同时承载多个网站或应用，同时还要应对访问量增长带来的压力。Nginx作为高性能的反向代理服务器，通过灵活的配置可以很自然地解决这两个问题。本文将从多站点代理、负载均衡和参数优化三个层面展开，给出可直接参考的配置片段，并解释每一步的作用，方便你在自己的环境中调整使用。文中涉及的命令和配置均基于常见的Nginx稳定版本，具体路径和参数细节请以你的实际环境及官方文档为准。

多站点反向代理：用server_name区分不同网站

当你需要在同一台Nginx服务器上代理多个不同的后端服务时，最核心的思路是借助server_name将来自不同域名的请求区分开，再分别转发到对应的后端地址。例如，站点A对应后端127.0.0.1:8081，站点B对应127.0.0.1:8082，可以写成下面这样：

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

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

server {
    listen 80;
    server_name www.another-example.com;

    location / {
        proxy_pass http://127.0.0.1:8082;
        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_pass地址可以是IP加端口，也可以是内网域名或Unix Socket，具体取决于后端应用监听方式。配置完成后，需要先测试配置再重载：

nginx -t
nginx -s reload

如果不执行测试直接重载，一旦出现语法错误，可能造成Nginx服务中断。另外一个常见的坑是proxy_set_header中的Host参数：若后端服务基于虚拟主机或域名路由，就必须手动传递原始Host，否则后端会收到默认值，从而返回错误的内容。

如果不同站点有部分路径需要转发到不同的后端，可以通过location块做更细粒度的控制，例如把“/api”转到API服务，把“/”转到前端页面服务。location匹配优先级有精确、前缀、正则等规则，建议在实际改动前先阅读Nginx官方documentation中关于location的部分，避免出现“以为匹配上了，实际没生效”的情况。

负载均衡：用upstream组实现流量分发

当后端应用需要横向扩展时，前端Nginx扮演负载均衡器的角色。通过定义一个upstream组，把多个后端服务器放入其中，Nginx会按照所选的策略将请求分发到不同节点。一个基础的HTTP负载均衡配置如下：

upstream backend_pool {
    server 192.0.2.10:8080 weight=3;
    server 192.0.2.11:8080 weight=1;
    server 192.0.2.12:8080 backup;
}

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

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

这里的weight参数表示权重，默认为1，数值越大，被分配到的请求比例越高。backup节点只在主节点全部不可用时才参与服务，适合做热备。除了默认的轮询，upstream还支持ip_hash、least_conn等策略。ip_hash可以让同一客户端的请求固定分发到同一后端，适合有session本地存储的旧系统；least_conn则会把请求交给当前连接数最少的后端，适合后端处理耗时差异较大的场景。选择哪种策略，取决于应用是否依赖会话保持、后端性能是否均匀等因素。

配置负载均衡时还需要关注故障转移。Nginx默认对后端健康状态并非主动探测，而是通过请求是否成功来判断。如果某个后端进程崩溃但端口仍可连接，请求仍可能被分过去。生产中推荐配合max_fails与fail_timeout使用，例如：

upstream backend_pool {
    server 192.0.2.10:8080 max_fails=3 fail_timeout=30s;
    server 192.0.2.11:8080 max_fails=3 fail_timeout=30s;
}

这里表示在30秒内失败3次，就把该节点暂时标记为不可用，30秒后重新尝试。需要说明的是，这些参数控制的是Nginx自身的故障处理行为，并不等同于健康检查。若后端服务彻底无响应，Nginx会返回502或504给客户端，此时应检查后端进程、网络与防火墙。正式上线的负载均衡方案，建议结合监控或Nginx Plus的商业功能做更精细的健康检查，具体以官方文档为准。

代理参数优化：调整超时与缓冲，兼顾体验和资源

反向代理场景下，Nginx的性能和稳定性往往取决于几个核心参数的设置。首先是proxy_connect_timeout，它与后端建立TCP连接的超时时间，默认60秒通常偏长，可适当调小到5至10秒，以便快速发现后端不可达。其次是proxy_read_timeout和proxy_send_timeout，分别控制两次读取/写入操作之间的间隔超时，默认都是60秒，如果后端处理上传或下载请求较慢，可以按接口特性放宽，但要注意不能盲目设得过大，否则容易堆积大量等待连接。

另一个容易忽略的是proxy_buffering。默认开启时，Nginx会先把后端返回的内容读入缓冲区，再发给客户端，这可以减轻部分网络抖动的影响；但对需要首字节尽快到达的流式接口或大文件下载场景，可以关闭缓冲区以支持边收边发。配置示例：

location /stream/ {
    proxy_pass http://backend_pool;
    proxy_buffering off;
    proxy_connect_timeout 5s;
    proxy_read_timeout 30s;
    proxy_send_timeout 30s;
    proxy_set_header Connection "";
}

其中proxy_set_header Connection ""在HTTP/1.1转发中很有用，特别是后端需要keepalive长连接时。同时，Nginx对后端发起连接默认使用HTTP/1.0，如果你希望复用与后端的连接，可以在upstream或server块中启用keepalive，例如：

upstream backend_pool {
    server 192.0.2.10:8080;
    server 192.0.2.11:8080;
    keepalive 32;
}

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

这里keepalive 32指定每个worker进程与后端保持的空闲长连接数量上限。启用后可以有效降低频繁建立TCP连接带来的开销，尤其适合短平快的API请求。需要注意的是，Nginx的keepalive参数要配合proxy_http_version 1.1和置空的Connection头才能生效，否则可能退化为逐个短连接。

最后建议结合自身业务做压力测试，观察Nginx的worker连接数、后端响应时间等指标，再针对性地调整参数。Nginx的配置项很多，每一项都有默认值，在没有充分理解之前，不必刻意追求“优化”，先保证配置清晰、逻辑正确，再逐步调整。本文给出的示例均为基础且通用的场景，实际部署中还需考虑日志格式、静态文件缓存、SSL终结等细节，欢迎根据具体需求查阅Nginx官方文档做进一步扩展。

继续阅读