香港服务器Linux双机热备怎么部署？Nginx与Keepalived配置及切换验证

发布人：Minchunlin 发布时间：2026-10-05 08:13 阅读量：2

在两台同一私有网络、同一子网的香港服务器上，可以使用 Nginx 提供 Web 服务，使用 Keepalived 通过 VRRP 管理一个虚拟 IP（VIP）。正常情况下由主节点持有 VIP；主节点的 Nginx、Keepalived 或整台服务器异常时，备用节点接管 VIP，客户端继续访问同一个地址。

开篇部署概述配图

下面以 Ubuntu 22.04 LTS、Nginx、Keepalived、systemd 为例部署主动/备用模式的双机热备。示例使用私网网卡 eth1 和以下地址，实际操作时请替换为服务器的真实私网信息：

对象	主机名	私网地址	初始角色	Keepalived优先级
主节点	`hk-ha01`	`10.10.0.11`	MASTER	110
备用节点	`hk-ha02`	`10.10.0.12`	BACKUP	100
虚拟IP	`ha-vip`	`10.10.0.100/24`	漂移地址	不适用

示例 VIP 位于私有子网，适合内网客户端或已由云平台做公网地址映射的场景。如果要让公网域名直接指向 VIP，必须先确认网络平台支持可在两台服务器之间漂移的公网 IP、辅助 IP 或浮动 IP。不能把已经固定分配给另一台服务器的公网 IP，直接写入 Keepalived 配置。

一、部署前提与架构边界

1. 操作系统和软件环境

两台服务器建议使用相同的操作系统版本和软件来源：

Ubuntu 22.04 LTS；
Nginx 使用 Ubuntu APT 仓库版本；
Keepalived 使用 Ubuntu APT 仓库版本；
使用 systemd 管理 Nginx 和 Keepalived；
两台服务器通过同一私有子网互通；
管理员拥有 sudo 权限；
客户端可以访问 VIP 所在的私有网络。

两台服务器至少要能够互相执行以下测试：

ping -c 3 10.10.0.12

在 hk-ha02 上，将目标地址替换为 10.10.0.11。如果 ICMP 被防火墙禁止，不能仅凭 ping 判断网络完全不通，还需要测试路由和端口。

确认私网网卡名称：

ip -br addr
ip route
ip route get 10.10.0.12

预期可以看到到对端私网地址的路由经过 eth1。如果实际网卡名是 ens160、ens5 或其他名称，后续 Keepalived 配置中的 interface、命令中的网卡名都必须同步替换。

2. Keepalived 能做什么，不能做什么

Keepalived 负责以下内容：

通过 VRRP 选出当前持有 VIP 的节点；
检测 Nginx 或本地健康检查脚本；
在主节点异常时让备用节点接管 VIP；
通过 GARP 通知局域网更新 VIP 对应的 MAC 地址。

Keepalived 不负责以下内容：

同步 Nginx 配置；
同步网站文件、上传文件和日志；
同步数据库；
复制 TCP 连接和用户会话；
自动修复应用自身故障。

因此，上线前必须把两台服务器的 Nginx 配置、站点文件、证书和运行依赖保持一致。需要持久化的数据、会话和上传内容，也不能只保存在当前主节点本地。

3. 网络侧必须放行 VRRP

本示例使用 Keepalived 的单播模式，避免部分云网络不转发组播报文。两台服务器之间仍然需要允许：

私网互通；
IP 协议号 112，即 VRRP；
客户端到 VIP 的 TCP 80；
如果部署 HTTPS，还需要 TCP 443；
管理端到两台服务器的 TCP 22。

如果云平台安全组不支持放行 IP 协议号 112，或者禁止服务器发送与自身主 IP 不一致的 ARP/GARP，Keepalived 可能显示状态切换正常，但客户端仍然无法访问 VIP。此时应使用平台提供的浮动 IP 或故障转移 IP 机制。

二、安装软件并备份现有配置

以下安装命令需要在两台服务器分别执行：

sudo apt update
sudo apt install -y nginx keepalived curl

检查软件版本：

nginx -v
keepalived --version
systemctl --version | head -n 1

不要求两台服务器的补丁版本完全相同，但建议保持相同的 Ubuntu 大版本、Nginx 主版本和 Keepalived 主版本。

在修改配置前建立备份目录。两台服务器都要执行：

BACKUP_DIR="/root/ha-backup-$(date +%F-%H%M%S)"

sudo install -d -m 700 "$BACKUP_DIR"
sudo cp -a /etc/nginx "$BACKUP_DIR/nginx"

if [ -d /etc/keepalived ]; then
    sudo cp -a /etc/keepalived "$BACKUP_DIR/keepalived"
fi

if [ -d /etc/ufw ]; then
    sudo cp -a /etc/ufw "$BACKUP_DIR/ufw"
fi

echo "$BACKUP_DIR"

记录命令输出的备份路径。后续回滚时需要使用实际生成的目录。

如果服务器当前已经承载业务，不要直接停止现有 Nginx 或覆盖全局配置。应先在备用节点完成配置测试，再安排维护窗口切换。

三、配置云防火墙和主机防火墙

1. 云平台安全组

先在云平台安全组中配置规则。规则范围应尽量限制在实际客户端网段和两台服务器私网地址之间：

方向	协议	来源	目标	用途
入站	TCP 22	管理网段	两台服务器	SSH
入站	TCP 80	业务客户端网段	VIP或服务器	HTTP
入站	TCP 443	业务客户端网段	VIP或服务器	HTTPS，可选
入站	IP协议112	对端私网IP	本节点	VRRP
出站	IP协议112	本节点	对端私网IP	VRRP

IP 协议号 112 不是 TCP 端口，也不是 UDP 端口，安全组中需要选择自定义 IP 协议或 VRRP 规则。

2. UFW 防火墙

先查看 UFW 当前状态：

sudo ufw status verbose

如果 UFW 已启用，先确认 SSH 管理网段已经放行。下面的 192.0.2.0/24 仅为文档示例，请替换为实际管理网段：

sudo ufw allow from 192.0.2.0/24 to any port 22 proto tcp
sudo ufw allow 80/tcp

在 hk-ha01 上允许来自 hk-ha02 的 VRRP 相关流量：

sudo ufw allow from 10.10.0.12
sudo ufw reload

在 hk-ha02 上执行：

sudo ufw allow from 10.10.0.11
sudo ufw reload

该规则允许对端私网地址访问本机所有协议，适合作为节点间的临时验证规则。如果生产环境有更严格的主机防火墙策略，应使用能够明确放行 IP 协议 112 的规则，并限制对端地址。

修改防火墙前，必须确认当前 SSH 会话不会因为规则错误被切断。不要在没有备用控制台或带外管理能力的情况下盲目执行 ufw enable。

四、在两台服务器上部署相同的 Nginx 配置

1. 创建测试站点

在两台服务器上执行：

sudo install -d -m 755 /var/www/ha-demo
printf 'node=%s\n' "$(hostname)" | sudo tee /var/www/ha-demo/index.html >/dev/null

生产环境中，两台服务器的站点文件应该相同。这里通过 hostname 生成不同的首页内容，只是为了在切换验证时判断请求实际落到了哪台服务器。

2. 创建 Nginx Server 配置

在两台服务器上创建 /etc/nginx/sites-available/ha-demo：

sudo tee /etc/nginx/sites-available/ha-demo >/dev/null <<'EOF'
server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name _;

    root /var/www/ha-demo;
    index index.html;

    location = /healthz {
        access_log off;
        default_type text/plain;
        return 200 "ok";
    }

    location / {
        try_files $uri $uri/ =404;
    }
}
EOF

/healthz 是给 Keepalived 使用的本机健康检查地址。它返回 HTTP 200，只能证明 Nginx 能够响应请求；生产环境可以进一步改为检查应用进程、关键依赖或只读业务接口，但检查脚本不能设计得过重，否则容易因为短暂抖动造成 VIP 频繁切换。

如果默认站点存在，需要先备份再停用，避免多个 default_server 产生冲突：

if [ -e /etc/nginx/sites-enabled/default ]; then
    sudo cp -a /etc/nginx/sites-enabled/default "$BACKUP_DIR/default"
    sudo rm -f /etc/nginx/sites-enabled/default
fi

sudo ln -sfn /etc/nginx/sites-available/ha-demo \
    /etc/nginx/sites-enabled/ha-demo

检查站点链接：

ls -l /etc/nginx/sites-enabled/

3. 验证本机 Nginx

两台服务器都执行：

sudo nginx -t
sudo systemctl enable nginx
sudo systemctl restart nginx
sudo systemctl is-active nginx

预期结果：

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
active

然后分别访问本机地址：

curl -i --max-time 3 http://127.0.0.1/healthz
curl -sS --max-time 3 http://127.0.0.1/

预期类似：

HTTP/1.1 200 OK
...
ok

以及：

node=hk-ha01

备用节点应返回自己的主机名。此时还没有配置 VIP，访问 10.10.0.100 失败是正常现象。

如果 nginx -t 失败，先不要启动 Keepalived，按以下顺序检查：

sudo nginx -t
sudo journalctl -u nginx -b --no-pager -n 50
sudo ss -lntp | grep ':80'

常见原因包括默认站点重复监听、配置文件拼写错误、端口 80 已被其他服务占用以及站点目录权限错误。

五、编写 Nginx 健康检查脚本

在两台服务器上创建同一份检查脚本：

sudo tee /usr/local/sbin/check_nginx.sh >/dev/null <<'EOF'
#!/bin/sh

set -eu

/usr/sbin/nginx -t >/dev/null 2>&1
/usr/bin/systemctl is-active --quiet nginx
/usr/bin/curl -fsS --max-time 1 http://127.0.0.1/healthz >/dev/null
EOF

sudo chown root:root /usr/local/sbin/check_nginx.sh
sudo chmod 755 /usr/local/sbin/check_nginx.sh

手动执行测试：

sudo /usr/local/sbin/check_nginx.sh
echo $?

返回 0 表示检查成功。故意停止 Nginx 后再次执行：

sudo systemctl stop nginx
sudo /usr/local/sbin/check_nginx.sh
echo $?
sudo systemctl start nginx

此时脚本应返回非零状态。确认 Nginx恢复后再继续配置 Keepalived：

sudo nginx -t
sudo systemctl is-active nginx
curl -fsS http://127.0.0.1/healthz

健康检查脚本放在 /usr/local/sbin，由 root 执行。不要让普通用户可以修改该文件，否则攻击者可能通过修改检查逻辑影响 VIP 漂移。

六、配置 Keepalived

1. 主节点配置

在 hk-ha01 上写入 /etc/keepalived/keepalived.conf：

sudo install -d -m 700 /etc/keepalived

sudo tee /etc/keepalived/keepalived.conf >/dev/null <<'EOF'
global_defs {
    router_id HK_HA01
    script_user root
    enable_script_security
}

vrrp_script chk_nginx {
    script "/usr/local/sbin/check_nginx.sh"
    interval 2
    timeout 1
    fall 2
    rise 2
    weight -20
}

vrrp_instance VI_1 {
    state MASTER
    interface eth1

    virtual_router_id 51
    priority 110
    advert_int 1

    unicast_src_ip 10.10.0.11
    unicast_peer {
        10.10.0.12
    }

    authentication {
        auth_type PASS
        auth_pass Kp8a2026
    }

    virtual_ipaddress {
        10.10.0.100/24 dev eth1
    }

    garp_master_delay 1
    garp_master_repeat 3

    track_script {
        chk_nginx
    }
}
EOF

sudo chown root:root /etc/keepalived/keepalived.conf
sudo chmod 600 /etc/keepalived/keepalived.conf

参数含义如下：

router_id：本机标识，两台服务器必须不同；
interface：承载私网 VIP 的网卡；
virtual_router_id：同一组 Keepalived 必须相同；
priority：数值越大，越倾向于成为主节点；
advert_int：VRRP 通告间隔，示例为 1 秒；
unicast_src_ip：本机私网地址；
unicast_peer：对端私网地址；
weight -20：健康检查失败后，主节点有效优先级从 110 降到 90，低于备用节点的 100，促使 VIP 切换；
virtual_ipaddress：Keepalived 动态添加和删除的 VIP；
garp_master_repeat：成为主节点后发送多次 GARP，帮助同网段设备刷新 ARP 缓存。

不要把 10.10.0.100 静态写进 Netplan 或其他网络配置中。VIP 应由 Keepalived 动态管理。

2. 备用节点配置

在 hk-ha02 上写入配置。与主节点相比，必须修改 router_id、state、priority、源地址和对端地址：

sudo install -d -m 700 /etc/keepalived

sudo tee /etc/keepalived/keepalived.conf >/dev/null <<'EOF'
global_defs {
    router_id HK_HA02
    script_user root
    enable_script_security
}

vrrp_script chk_nginx {
    script "/usr/local/sbin/check_nginx.sh"
    interval 2
    timeout 1
    fall 2
    rise 2
    weight -20
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth1

    virtual_router_id 51
    priority 100
    advert_int 1

    unicast_src_ip 10.10.0.12
    unicast_peer {
        10.10.0.11
    }

    authentication {
        auth_type PASS
        auth_pass Kp8a2026
    }

    virtual_ipaddress {
        10.10.0.100/24 dev eth1
    }

    garp_master_delay 1
    garp_master_repeat 3

    track_script {
        chk_nginx
    }
}
EOF

sudo chown root:root /etc/keepalived/keepalived.conf
sudo chmod 600 /etc/keepalived/keepalived.conf

两台服务器的认证密码、virtual_router_id、VIP、健康检查参数应保持一致。auth_pass 在 VRRP 配置中建议使用不超过 8 个字符的值，并且配置文件权限应限制为 root 可读。

3. 检查 Keepalived 配置语法

两台服务器分别执行：

sudo keepalived -t -f /etc/keepalived/keepalived.conf

不同发行版的 Keepalived 版本可能对参数提示略有差异。只要命令没有返回致命配置错误即可。然后查看系统日志：

sudo journalctl -u keepalived -b --no-pager -n 50

如果出现网卡不存在、脚本不可执行、VIP 格式错误或权限相关错误，应先处理后再启动服务。

七、按顺序启动并确认 VIP

为了避免部署过程中出现两个节点同时争抢 VIP，建议先启动主节点，再启动备用节点。

1. 配置服务启动顺序

两台服务器都创建 systemd drop-in 配置：

sudo install -d /etc/systemd/system/keepalived.service.d

sudo tee /etc/systemd/system/keepalived.service.d/override.conf >/dev/null <<'EOF'
[Unit]
Wants=network-online.target nginx.service
After=network-online.target nginx.service
EOF

sudo systemctl daemon-reload
sudo systemctl enable nginx keepalived

这只负责服务启动顺序，不会替代健康检查。即使 Keepalived 启动，Nginx 本机检查失败时也不应该继续持有 VIP。

2. 启动主节点

在 hk-ha01 上执行：

sudo systemctl start nginx
sudo systemctl start keepalived

sudo systemctl is-active nginx
sudo systemctl is-active keepalived
sudo ip -br addr show dev eth1

预期能看到类似结果：

eth1             UP             10.10.0.11/24 10.10.0.100/24

查看 Keepalived 状态：

sudo journalctl -u keepalived -b --no-pager -n 80

正常日志通常会包含进入 MASTER STATE 或添加 VIP 的信息。

3. 启动备用节点

确认主节点已经持有 VIP 后，在 hk-ha02 上执行：

sudo systemctl start nginx
sudo systemctl start keepalived

sudo systemctl is-active nginx
sudo systemctl is-active keepalived
sudo ip -br addr show dev eth1

备用节点正常情况下只能看到自己的私网地址，不应看到 10.10.0.100/24：

eth1             UP             10.10.0.12/24

检查备用节点日志：

sudo journalctl -u keepalived -b --no-pager -n 80

预期状态是 BACKUP。如果两台服务器都显示 MASTER，不要继续压测或接入生产流量，应立即检查 VRRP 协议是否被防火墙拦截。

八、切换前的基础验证

在与 VIP 同一私网、或者能够路由到 VIP 的第三台客户端上执行：

curl -i --max-time 3 http://10.10.0.100/healthz
curl -sS --max-time 3 http://10.10.0.100/

预期首页返回：

node=hk-ha01

同时在两台服务器分别检查：

sudo ss -lntp | grep ':80'
sudo ip -br addr show dev eth1

此时应满足：

只有一台服务器拥有 10.10.0.100/24；
两台服务器的 Nginx 都监听 TCP 80；
主节点本机 /healthz 返回 200；
备用节点本机 /healthz 也返回 200；
通过 VIP 访问时返回当前持有 VIP 节点的内容。

如果客户端无法访问 VIP，但主节点显示已经拥有 VIP，可以按以下顺序排查：

curl -i --max-time 3 http://10.10.0.11/healthz
curl -i --max-time 3 http://10.10.0.12/healthz
sudo ip neigh
sudo ss -lntp | grep ':80'

两台服务器本机均正常而 VIP 不通，重点检查安全组、VIP 所在网络是否允许漂移，以及客户端到 10.10.0.100 的路由。

九、执行 Nginx 故障切换验证

切换验证应在维护窗口进行。Keepalived 可以缩短故障时间，但不能保持已经建立的 TCP 连接不变；切换期间正在传输的请求可能失败或需要客户端重试。

1. 验证主节点 Nginx 停止

先确认当前 VIP 所在节点：

ip -br addr show dev eth1

在持有 VIP 的节点上停止 Nginx：

sudo systemctl stop nginx

由于健康检查每 2 秒执行一次，连续两次失败后，主节点的有效优先级会降低。等待数秒后，在两台服务器分别执行：

九、执行 Nginx 故障切换验证配图

ip -br addr show dev eth1

预期结果：

原主节点不再持有 10.10.0.100/24；
备用节点获得 10.10.0.100/24；
VIP 客户端请求返回：

node=hk-ha02

持续访问可以使用以下命令：

while true; do
    date '+%F %T'
    curl -sS --connect-timeout 1 --max-time 2 http://10.10.0.100/
    sleep 1
done

示例中可能出现一次或数次连接失败，这是 VIP 漂移和连接重建期间的正常现象。实际中断时间取决于 VRRP 通告、健康检查、ARP 刷新和客户端重试行为。

2. 恢复主节点 Nginx

在原主节点上先验证配置，再启动 Nginx：

sudo nginx -t
sudo systemctl start nginx
sudo systemctl is-active nginx
curl -fsS http://127.0.0.1/healthz

默认配置下，主节点恢复后会因为优先级更高而重新抢占 VIP。观察日志和地址：

sudo journalctl -u keepalived -f
ip -br addr show dev eth1

如果希望故障恢复后不立即自动抢占，而是由运维人员手工决定是否回切，可以在两台配置中评估使用 nopreempt。启用前要明确启动顺序和维护流程，否则重启后的节点可能长期处于备用状态。

3. 验证 Keepalived 进程故障

为了模拟 Keepalived 进程异常，在当前主节点上执行：

sudo systemctl stop keepalived

这会主动释放 VIP。备用节点在若干个通告周期内应接管地址。验证完成后，在原节点上恢复：

sudo systemctl start keepalived
sudo systemctl is-active keepalived

4. 验证整机故障

整机断电、重启或关闭私网网卡的测试风险较高，不建议直接在承载生产流量的服务器上执行。可以先使用云平台控制台或测试实例验证。

整机故障时，备用节点通常在收不到主节点 VRRP 通告后接管 VIP。验证重点不是“完全零中断”，而是确认：

VIP 能够在备用节点出现；
客户端能够重新建立连接；
Nginx 配置和站点内容一致；
DNS 不需要修改；
恢复主节点后不会出现双 VIP。

十、常见失败现象与处理方法

1. 两台服务器同时显示 MASTER

先停止其中一台已知备用节点的 Keepalived：

sudo systemctl stop keepalived

然后在保留服务的节点上确认 VIP 仍然存在：

ip -br addr show dev eth1

双主通常意味着两台服务器没有收到对方的 VRRP 通告，常见原因包括：

unicast_peer 地址写错；
unicast_src_ip 与本机实际私网地址不一致；
interface 写错；
云安全组拦截 IP 协议 112；
UFW 或其他主机防火墙拦截；
两台配置的 virtual_router_id 不一致；
两台机器不在支持 VIP 漂移的同一网络中。

可以在节点上查看路由：

ip route get 10.10.0.12

也可以临时安装 tcpdump 观察 VRRP 报文：

sudo apt install -y tcpdump
sudo tcpdump -ni eth1 'ip proto 112'

如果长时间看不到对端报文，优先检查安全组、主机防火墙和私网路由。

2. VIP 已经出现，但客户端访问失败

先在持有 VIP 的服务器本机测试：

curl -i --max-time 3 http://10.10.0.100/healthz

如果本机也失败，检查：

sudo nginx -t
sudo systemctl status nginx --no-pager
sudo ss -lntp | grep ':80'
sudo journalctl -u nginx -b --no-pager -n 80

如果本机成功、远程客户端失败，重点检查：

VIP 是否属于允许漂移的地址；
云平台是否启用源地址或 MAC 防欺骗；
安全组是否允许客户端访问 TCP 80；
客户端是否有到 VIP 的路由；
ARP 缓存是否仍指向旧节点。

云平台不支持二层 VIP 时，仅调整 Nginx 或 Keepalived 配置通常无法解决，应该切换到平台支持的浮动 IP 或故障转移方案。

3. VIP 频繁来回切换

查看 Keepalived 日志：

sudo journalctl -u keepalived -b --no-pager -n 150

同时检查健康脚本：

sudo /usr/local/sbin/check_nginx.sh
echo $?

如果脚本间歇性返回非零，可能是：

Nginx 配置检查失败；
本机端口 80 短暂不可用；
/healthz 被应用依赖拖慢；
CPU、磁盘或进程资源不足；
健康检查超时时间过短；
两台服务器的脚本内容不一致。

可以先把 /healthz 保持为轻量本机检查，确认切换稳定后，再逐步增加应用层检查。不要把包含数据库、外部接口和复杂业务流程的检查直接放到 2 秒周期内。

4. 备用节点没有接管 VIP

在备用节点检查：

sudo systemctl is-active keepalived
sudo systemctl status keepalived --no-pager
sudo journalctl -u keepalived -b --no-pager -n 100
sudo /usr/local/sbin/check_nginx.sh

备用节点只有在自身 Nginx 健康检查成功时，才适合接管 VIP。如果备用节点本地 /healthz 失败，Keepalived 可能不会成为有效的服务节点。

还需要确认备用节点的优先级高于主节点健康检查失败后的有效优先级。本示例中：

十、常见失败现象与处理方法配图

主节点正常：110；
主节点健康检查失败：110 - 20 = 90；
备用节点：100。

因此备用节点可以接管。若误把 weight 设置为 -10，主节点失败后的有效优先级仍为 100，可能无法形成明确的优先级差异。

5. 切换后仍然返回旧节点内容

检查持有 VIP 的节点：

ip -br addr show dev eth1

如果 VIP 已经在新节点，但首页仍显示旧节点主机名，可能是以下原因：

客户端访问的是旧节点公网 IP，而不是 VIP；
前面还有缓存、负载均衡或代理；
DNS 仍指向固定公网地址；
两台服务器部署的站点文件不一致；
客户端连接尚未重新建立。

可使用 curl --resolve 或直接访问 VIP，绕过 DNS 验证实际链路：

curl -sS --max-time 3 http://10.10.0.100/

十一、失败回滚方法

回滚前先确认另一台服务器的 Nginx 可以本机访问：

curl -fsS http://127.0.0.1/healthz

不要同时停止两台服务器的 Keepalived，否则 VIP 会暂时无人持有。

1. 回滚 Keepalived

如果新配置导致当前节点异常，先在该节点停止 Keepalived，让备用节点有机会接管：

sudo systemctl stop keepalived

如果需要完全退出双机热备但保留 Nginx 单机运行：

sudo systemctl disable keepalived
sudo systemctl stop keepalived

此时应在计划保留服务的节点上确认 VIP 是否存在。如果要恢复原有 Keepalived 配置，使用部署前生成的备份目录，例如：

BACKUP_DIR="/root/ha-backup-2026-10-04-120000"

if [ -f "$BACKUP_DIR/keepalived/keepalived.conf" ]; then
    sudo cp -a "$BACKUP_DIR/keepalived/keepalived.conf" \
        /etc/keepalived/keepalived.conf
    sudo chmod 600 /etc/keepalived/keepalived.conf
    sudo keepalived -t -f /etc/keepalived/keepalived.conf
fi

只有配置测试通过后，才能重新启动：

sudo systemctl start keepalived
sudo systemctl is-active keepalived

2. 回滚 Nginx 站点配置

如果只是回滚本次新增的示例站点：

sudo rm -f /etc/nginx/sites-enabled/ha-demo
sudo rm -f /etc/nginx/sites-available/ha-demo

如果之前停用了默认站点，并且备份文件存在，可以恢复：

BACKUP_DIR="/root/ha-backup-2026-10-04-120000"

if [ -e "$BACKUP_DIR/default" ]; then
    sudo cp -a "$BACKUP_DIR/default" \
        /etc/nginx/sites-enabled/default
fi

如果修改过 /etc/nginx/nginx.conf 或其他全局配置，应只恢复对应文件，不要在没有确认的情况下删除整个 /etc/nginx 目录：

sudo nginx -t
sudo systemctl reload nginx

如果配置测试失败，不要执行 reload，先从备份恢复产生错误的具体文件。

十二、上线验收与回滚检查项

正式把业务域名或公网浮动 IP 指向该架构前，至少确认以下项目：

两台服务器均为 Ubuntu 22.04 LTS，Nginx 和 Keepalived 已安装；
两台服务器私网地址、网卡名称和路由确认无误；
云安全组允许节点间 IP 协议 112；
主机防火墙没有拦截 VRRP；
两台服务器本机访问 /healthz 均返回 HTTP 200；
两台服务器的 Nginx 配置均通过 nginx -t；
只有一台服务器持有 10.10.0.100；
备用节点能够独立提供相同站点内容；
停止主节点 Nginx 后，VIP 能转移到备用节点；
停止主节点 Keepalived 后，备用节点能够接管；
恢复主节点后，回切行为符合预期；
切换期间客户端能够重新建立连接；
网站文件、证书、应用配置和会话处理方式已经在两台服务器保持一致；
已记录配置备份目录和回滚步骤；
回滚时不会同时停止两台节点的 Keepalived。

当 VIP 只在一个节点上存在、Nginx 健康检查稳定、故障切换和恢复流程均通过后，才适合将生产访问入口切换到该双机热备架构。

文章标签：香港服务器 Linux运维 Nginx Keepalived 故障切换

上一篇：Nginx+Keepalived主备切换后仍无法访问？香港服务器Linux环境如何预演与恢复？

下一篇：CentOS Stream 9香港服务器跨境访问延迟高，如何分层定位链路与系统问题？

更多栏目

新闻动态

文档中心

下载中心

目录结构

全文