如何在Linux上配置高可用的反向代理如Nginx

在Linux服务器上搭建对外服务的Web架构时，反向代理是承上启下的关键层。Nginx凭借事件驱动模型和高并发能力，成为最主流的反向代理选型。但默认部署的Nginx是单点运行，一旦进程崩溃或主机离线，所有经它转发的请求都会失败。要让代理层具备高可用能力，必须引入冗余机制，使一台机器出问题时另一台能无缝顶上。

一、准备工作与基础环境

高可用反向代理通常由两台及以上Linux主机组成，一台作为主节点（MASTER），另一台作为备节点（BACKUP）。它们对外暴露同一个虚拟IP（VIP），内网真实IP不同。客户端只访问VIP，实际流量由keepalived根据节点健康状态决定交给哪台Nginx处理。

建议选用相同版本的Linux发行版（如Ubuntu 22.04或CentOS 7），关闭SELinux或配置合适策略，确保防火墙放行VIP的ARP广播及Nginx监听端口。两台机器的时间应通过NTP同步，避免日志与选举异常。以下以CentOS风格命令为例，Ubuntu可将yum换成apt。

1.1 安装依赖与编译Nginx

若使用官方预编译包，可直接安装nginx；但高可用场景常需要定制模块，这里给出源码编译方式。先安装编译工具与依赖库：

# 安装基础依赖
yum install -y gcc pcre pcre-devel zlib zlib-devel openssl openssl-devel
# 下载并编译Nginx
cd /usr/local/src
wget http://nginx.org/download/nginx-1.24.0.tar.gz
tar zxvf nginx-1.24.0.tar.gz
cd nginx-1.24.0
./configure --prefix=/usr/local/nginx --with-http_ssl_module --with-http_realip_module
make && make install

编译完成后，Nginx可执行文件位于/usr/local/nginx/sbin/nginx。将其注册为系统服务便于管理。注意编译参数中的with_http_realip_module用于后续从代理头获取真实客户端IP，对业务审计很重要。

主备两台机器都需完成上述Nginx安装，且反向代理的后端配置（如upstream块）应保持一致，否则切换后路由规则会出现差异。可以用配置管理工具或手动同步配置文件。

二、配置Nginx反向代理

Nginx作为反向代理，核心是使用upstream定义后端服务池，并在server块中通过proxy_pass转发请求。下面给出一个基础示例，将流量分发到两个后端应用节点。

http {
    upstream backend_pool {
        server 192.168.0.10:8080 weight=1;
        server 192.168.0.11:8080 weight=1;
    }

    server {
        listen 80;
        server_name example.ipipp.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;
        }
    }
}

上述配置中，upstream内的weight表示权重，相等时近似轮询。proxy_set_header指令把客户端信息传递给后端，否则后端看到的所有请求都来自Nginx本机IP。若后端需要HTTPS，可将listen改为443并配置ssl证书。

配置写好后，用/usr/local/nginx/sbin/nginx -t检测语法，确认无误后启动。此时单台Nginx已能正常工作，但仍是单点。接下来引入keepalived解决单点问题。

2.1 健康检查脚本

keepalived本身只保障VIP在节点间漂移，它默认靠检测自身进程判断存活。但Nginx可能静默卡死，因此需编写脚本定期检查Nginx是否可服务，不可用时主动降低本节点优先级，触发切换。

#!/bin/bash
# /usr/local/bin/check_nginx.sh
curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1/health > /tmp/nginx_status
if [ "$(cat /tmp/nginx_status)" != "200" ]; then
    # 尝试重启一次
    /usr/local/nginx/sbin/nginx -s reload
    sleep 2
    curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1/health > /tmp/nginx_status
    if [ "$(cat /tmp/nginx_status)" != "200" ]; then
        exit 1
    fi
fi
exit 0

脚本逻辑是先请求本地健康接口，若非200则重载Nginx再测一次，仍失败则返回1。keepalived会据此判定节点失效。记得给脚本加执行权限chmod +x /usr/local/bin/check_nginx.sh，并在Nginx中配置对应的/health路由返回200。

三、使用keepalived实现VIP漂移

keepalived基于VRRP协议工作，同一组节点选举出MASTER持有VIP。当MASTER健康检查失败，BACKUP接管VIP，客户端无感知。下面给出主节点配置样例。

# /etc/keepalived/keepalived.conf 主节点
global_defs {
    router_id nginx_ha_1
}

vrrp_script chk_nginx {
    script "/usr/local/bin/check_nginx.sh"
    interval 2
    weight -20
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.0.100
    }
    track_script {
        chk_nginx
    }
}

其中vrrp_script定义了刚才的健康检查，weight -20表示脚本失败时间隔期内优先级减20，低于BACKUP的优先级就会丢VIP。virtual_ipaddress即对外VIP，客户端将DNS解析到该地址。interface需按实际网卡名修改，可用ip addr查看。

备节点配置只需改router_id、state为BACKUP、priority改为90（低于主节点减权后的值）、virtual_router_id保持一致。启动keepalived服务后，ip addr show可看到VIP绑定在MASTER的网卡上。手动停掉主节点Nginx，数秒后VIP会出现在备机，代理服务不中断。

3.1 切换验证与注意事项

验证高可用不能只靠理论。可在一台客户端持续ping VIP并用curl请求业务接口，同时杀掉主节点Nginx进程，观察请求是否出现短暂超时后恢复。通常切换在1到3秒内完成，取决于advert_int与健康检查间隔。

生产环境还要注意：VIP所在的网络段需允许ARP免费包；云厂商某些网络不支持自行宣告VIP，此时需用云负载均衡配合多可用区而非keepalived；后端upstream建议开启健康检查，避免代理到已挂应用。此外，Nginx日志应集中收集，方便切换后排查哪台机器处理了请求。

四、总结与扩展思路

通过Nginx加keepalived，在普通Linux服务器上就能以较低成本实现反向代理高可用。核心要点是双机同配置、VIP统一入口、健康脚本联动优先级。该方案适合自建机房或支持VRRP的私有云。

若规模扩大，可引入多级代理或用LVS做四层负载再加Nginx七层，也可以使用容器编排平台的Service与Ingress替代手工部署。但无论哪种架构，消除单点、自动化健康检查、无缝切换这三点原则不变。掌握本文的Linux配置方法，是理解上层方案的基础。

Nginxkeepalivedreverse_proxy修改时间：2026-08-06 03:18:35