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

主节点故障后，Keepalived 日志显示已经完成状态切换，并不代表业务入口已经恢复。Nginx+Keepalived 主备架构中，Keepalived 主要负责虚拟 IP（VIP）的归属与漂移，Nginx 负责监听端口和转发请求，应用、证书、配置文件、数据库及云平台网络策略则分别承担其他可用性责任。只要其中一层没有同步或没有放行，主备切换后仍然可能出现超时、连接拒绝、502、证书异常或页面数据不一致。

恢复时应先从外到内确认四件事：备节点是否真正持有 VIP，客户端请求是否到达备节点，备节点的 Nginx 是否监听 80/443 端口，以及 Nginx 后端应用是否可用。若 VIP 没有漂移，检查 Keepalived、VRRP 通信和服务器平台对浮动 IP 的支持；若 VIP 已经漂移但本机访问失败，重点检查 Nginx 配置、证书、应用端口和防火墙；若本机访问正常而外部仍超时，则更可能是云平台路由、访问控制或客户端 ARP 缓存问题。

先确定架构边界和恢复目标

Keepalived 能解决什么，不能解决什么

Keepalived 通过 VRRP 或单播 VRRP 在两台 Linux 服务器之间选举主节点，并将一个 VIP 绑定到当前主节点。例如：

• 主节点：192.0.2.11
• 备节点：192.0.2.12
• 业务 VIP：192.0.2.10
• 网卡：ens3

这里使用的是文档示例地址，实际部署时应替换为香港服务器所在网络中的真实地址。

Keepalived 可以处理：

• 主节点宕机后的 VIP 漂移；
• Keepalived 进程故障；
• Nginx 进程停止后的优先级降低；
• 通过健康检查触发主备切换；
• 主备节点之间的状态选举。

Keepalived 无法单独处理：

• 两台服务器之间的 Nginx 配置差异；
• 备节点没有部署应用或证书；
• 后端数据库、上传文件和用户会话没有复制；
• 云平台不允许同一个 IP 在两台服务器间漂移；
• 安全组、网络 ACL 或主机防火墙未开放 80/443；
• DNS 仍然指向旧的固定 IP；
• 客户端或上游设备仍缓存旧的 MAC 地址。

因此，判断“切换是否成功”不能只看：

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

还要结合 VIP、端口、HTTP 响应和后端应用共同确认。

先定义 RTO 和 RPO

在开始部署或演练前，应先确定恢复目标。

例如，RTO 设为 5 分钟，并不意味着只要 5 分钟内 VIP 漂移就算成功。如果备节点返回的是 502，或者用户刚提交的数据在切换后消失，业务仍然没有真正恢复。

典型失效场景与判断条件

主备切换后无法访问，通常可以归纳为以下几类。

香港服务器环境的网络前提

两台服务器能否直接使用 Keepalived，关键不在服务器所在地区，而在网络平台是否允许 VIP 归属发生变化。

适合直接使用传统 VIP 漂移的条件通常包括：

• 两台服务器处于同一二层网络或同一可支持 VRRP 的网络域；
• VIP 与两台服务器处于同一网段；
• 上游交换网络接受 Gratuitous ARP（免费 ARP）更新；
• 云平台允许一个浮动 IP 在不同实例之间切换；
• 主机和安全组允许 VRRP 通信，通常涉及 IP 协议号 112；
• 对外访问流量能够按照新的 VIP 归属转发。

如果服务器使用的是严格绑定到单台实例的公网 IP，或者云平台采用三层路由并禁止服务器自行添加 VIP，那么 Keepalived 日志可能显示切换成功，但外部请求仍然到不了备节点。此时应使用云平台提供的浮动 IP、故障转移 IP 或路由切换机制；不能仅靠 ip addr add 把公网 IP 强行添加到另一台服务器上。

部署前的资产和配置准备

检查网卡、地址和监听端口

先在两台服务器分别执行以下命令，确认网卡名称、地址和路由，不要直接假设网卡一定叫 eth0。

ip -br addr
ip route
ss -lntp
systemctl is-enabled nginx
systemctl is-enabled keepalived

应重点确认：

1. 两台服务器使用的网卡名称一致或配置文件已分别适配；
2. 主节点和备节点地址处于同一规划网段；
3. VIP 没有被其他设备占用；
4. Nginx 计划监听的端口没有被其他进程占用；
5. 两台服务器都已安装相同主版本的 Nginx 和 Keepalived；
6. 两台服务器的时间、主机名和基础网络配置正常。

如果系统是 Debian/Ubuntu，可使用发行版对应的 apt 安装缺失软件；如果是 RHEL 系列，可使用 dnf。安装或升级软件会改变生产环境的软件包状态，应先确认维护窗口，并保留现有配置备份。

需要复制或统一的内容

双机热备并不只是复制一个 Keepalived 配置。至少应建立以下资产清单：

• Nginx 主配置和站点配置；
• TLS 证书、私钥及证书链；
• 静态文件和前端发布文件；
• 后端应用程序、启动参数和环境变量；
• 应用依赖的本地目录；
• 防火墙规则和安全组规则；
• 定时任务、日志轮转和监控配置；
• 数据库连接信息；
• 上传文件、会话和缓存的处理方案。

其中，私钥和环境变量不能直接通过不安全的公开渠道复制。复制前应确认文件权限、属主和备节点上的服务账户一致。

配置 Nginx 和应用健康检查

下面给出一个用于说明的 Nginx 配置。示例假设后端应用监听 127.0.0.1:8080，生产环境应替换为实际端口和域名。

修改前先备份 Nginx 配置。备份目录应保留到确认演练成功之后：

sudo cp -a /etc/nginx /etc/nginx.backup.$(date +%Y%m%d%H%M%S)

在两台服务器上保持站点配置一致，例如创建 /etc/nginx/conf.d/ha-site.conf：

upstream app_backend {
    server 127.0.0.1:8080 max_fails=3 fail_timeout=5s;
}

server {
    listen 80;
    server_name example.com;

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

    location = /readyz {
        access_log off;
        proxy_pass http://app_backend/healthz;
        proxy_connect_timeout 1s;
        proxy_read_timeout 2s;
        proxy_send_timeout 2s;
    }

    location / {
        proxy_pass http://app_backend;
        proxy_http_version 1.1;
        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_connect_timeout 3s;
        proxy_read_timeout 30s;
    }
}

这里区分了两个接口：

• /healthz 只说明 Nginx 进程能够返回响应；
• /readyz 还会检查后端应用是否能返回健康响应。

Keepalived 应检查 /readyz，否则可能出现“Nginx 进程还活着，但应用已经停止”，Keepalived 仍然认为主节点可用的情况。

修改后先验证语法，再平滑加载：

sudo nginx -t
sudo systemctl reload nginx
sudo curl -fsS -H 'Host: example.com' http://127.0.0.1/healthz
sudo curl -fsS -H 'Host: example.com' http://127.0.0.1/readyz

如果 nginx -t 失败，不要执行 reload。应根据错误提示恢复备份配置，或者只修正当前文件后重新测试。对于已经存在的 443 配置，还应在两台服务器上同步证书、私钥、listen 443 ssl、证书链和域名配置。只验证 80 端口，不能证明 HTTPS 业务已经具备切换条件。

配置 Keepalived 主备关系

健康检查脚本

创建 /etc/keepalived/check_nginx_ready.sh：

sudo install -o root -g root -m 0750 /dev/stdin /etc/keepalived/check_nginx_ready.sh <<'EOF'
#!/bin/sh
set -eu

curl -fsS \
  --max-time 2 \
  -H 'Host: example.com' \
  http://127.0.0.1/readyz \
  >/dev/null
EOF

该脚本依赖本机已经安装 curl，并假定 Nginx 配置中的站点域名为 example.com。实际部署时应替换为业务域名。

主节点配置

主节点 /etc/keepalived/keepalived.conf 示例：

global_defs {
    router_id HK_NODE_A
    enable_script_security
}

vrrp_script check_nginx_ready {
    script "/etc/keepalived/check_nginx_ready.sh"
    interval 2
    timeout 3
    fall 2
    rise 2
    weight -30
    user root
}

vrrp_instance VI_1 {
    state BACKUP
    interface ens3
    virtual_router_id 51
    priority 120
    advert_int 1

    unicast_src_ip 192.0.2.11
    unicast_peer {
        192.0.2.12
    }

    authentication {
        auth_type PASS
        auth_pass ha-pass
    }

    virtual_ipaddress {
        192.0.2.10/24 dev ens3
    }

    track_script {
        check_nginx_ready
    }

    garp_master_repeat 3
    garp_master_refresh 60
    nopreempt
}

备节点配置

备节点只需要替换节点标识、优先级、源地址和对端地址：

global_defs {
    router_id HK_NODE_B
    enable_script_security
}

vrrp_script check_nginx_ready {
    script "/etc/keepalived/check_nginx_ready.sh"
    interval 2
    timeout 3
    fall 2
    rise 2
    weight -30
    user root
}

vrrp_instance VI_1 {
    state BACKUP
    interface ens3
    virtual_router_id 51
    priority 100
    advert_int 1

    unicast_src_ip 192.0.2.12
    unicast_peer {
        192.0.2.11
    }

    authentication {
        auth_type PASS
        auth_pass ha-pass
    }

    virtual_ipaddress {
        192.0.2.10/24 dev ens3
    }

    track_script {
        check_nginx_ready
    }

    garp_master_repeat 3
    garp_master_refresh 60
    nopreempt
}

priority 120 和 priority 100 只是示例值。由于健康检查失败时主节点会减少 30 分，主节点 Nginx 或后端不可用时，备节点有机会取得更高的有效优先级。

这里使用 nopreempt 是为了避免故障节点恢复后立即抢回 VIP，减少恢复过程中的二次抖动。代价是主节点恢复后不会自动回切，需要通过计划内操作完成回切。如果业务要求主节点恢复后自动回切，可以去掉 nopreempt，但必须评估网络抖动、服务未完全恢复和重复切换的风险。

在正式启动前，分别执行配置检查：

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

如果系统中的 Keepalived 不支持该参数，应先查看本机版本帮助信息：

keepalived --help
keepalived --version

确认语法无误后，再按“先备节点、后主节点”的顺序启动或重载，避免两台服务器同时修改配置时难以判断 VIP 归属：

sudo systemctl enable nginx keepalived
sudo systemctl restart keepalived
sudo systemctl status keepalived --no-pager

restart keepalived 可能触发 VIP 变化，应在维护窗口或演练时执行。查看当前 VIP 归属：

ip -br addr show dev ens3
sudo journalctl -u keepalived -n 80 --no-pager

正常情况下，只有一台服务器显示 192.0.2.10。如果两台都持有 VIP，属于脑裂风险，应立即停止继续测试，先检查 virtual_router_id、对端地址、主机防火墙和云平台网络策略。

预防切换后无法访问

同步配置，但不要盲目覆盖

Nginx 配置可以通过版本管理或受控复制保持一致。使用 rsync 时，先执行试运行，不要一开始就使用会删除目标文件的参数：

sudo rsync -aHn \
  --exclude='logs/' \
  /etc/nginx/ backup-node:/etc/nginx/

-n 表示只模拟不修改。确认源目录、目标目录和排除项无误后，才可以在维护窗口执行正式同步。--delete 会删除目标端源端不存在的文件，使用前必须完成目标端备份，并确认不会误删备节点独有的配置。正式同步后，在备节点执行：

sudo nginx -t
sudo systemctl reload nginx

证书复制也要单独核对有效期、权限和证书链：

sudo openssl x509 -in /etc/nginx/ssl/example.com.crt -noout -subject -dates
sudo stat /etc/nginx/ssl/example.com.key

同时检查主机防火墙和云平台策略

两台服务器都应允许业务端口：

• TCP 80；
• TCP 443；
• 两台节点之间的 Keepalived/VRRP 通信；
• 必要的健康检查和管理访问。

先读取现有规则，不要为了排障直接清空防火墙：

sudo nft list ruleset
sudo ss -lunp

使用 firewalld 或其他防火墙管理工具时，应通过现有管理方式查看和修改规则。云平台安全组、网络 ACL 和主机防火墙需要同时允许流量，任何一层拒绝都可能表现为“VIP 已经切换但网站无法访问”。

让健康检查接近真实业务

健康检查过于简单会导致错误切换，过于复杂又可能因短暂依赖抖动频繁切换。建议至少分为三层：

1. 进程层：Nginx 和应用进程是否存在；
2. 端口层：Nginx 和后端端口是否监听；
3. 就绪层：应用是否能在合理超时内返回有效响应。

不要让健康检查执行写数据库、上传文件或修改业务状态。健康检查应是只读操作，否则每两秒一次的检查可能产生额外数据或锁竞争。

按顺序预演主备切换

演练前应准备一个外部测试客户端。不要只在当前服务器上执行 curl，因为本机访问可能绕过真实入口。测试域名、VIP、HTTPS 和一个只读业务接口。

切换前基线检查

在当前主节点和备节点都执行：

hostname
ip -br addr show dev ens3
sudo systemctl is-active nginx
sudo systemctl is-active keepalived
sudo nginx -t
sudo ss -lntp | grep -E ':(80|443|8080)\b'

从外部客户端执行：

curl -sS -o /dev/null \
  -w 'http=%{http_code} connect=%{time_connect}s total=%{time_total}s\n' \
  --resolve example.com:80:192.0.2.10 \
  http://example.com/healthz

如果业务使用 HTTPS：

curl -skS -o /dev/null \
  -w 'https=%{http_code} connect=%{time_connect}s total=%{time_total}s\n' \
  --resolve example.com:443:192.0.2.10 \
  https://example.com/healthz

确认基线返回 200 后，再开始故障注入。示例配置中 192.0.2.10 只是文档地址，实际测试必须替换为真实 VIP。

演练 Keepalived 故障

在当前 VIP 持有节点执行：

sudo systemctl stop keepalived

这会主动触发一次主备切换，属于有影响的操作，应在维护窗口执行。预期结果是：

• 备节点日志出现状态变化；
• 备节点的网卡上出现 VIP；
• 原主节点不再持有 VIP；
• 外部 HTTP/HTTPS 请求在短暂中断后恢复；
• 备节点的 /readyz 返回成功。

在备节点检查：

ip -br addr show dev ens3
sudo journalctl -u keepalived --since "-5 min" --no-pager
sudo curl -fsS -H 'Host: example.com' http://127.0.0.1/readyz

从外部客户端连续观察请求：

for i in $(seq 1 20); do
    date '+%H:%M:%S'
    curl -sS -o /dev/null \
      -w 'http=%{http_code} total=%{time_total}s\n' \
      --connect-timeout 3 \
      --max-time 5 \
      --resolve example.com:80:192.0.2.10 \
      http://example.com/healthz || echo "request_failed"
    sleep 1
done

这组结果可以用于估算切换期间的中断时间，但不要把示例中的结果当作固定保证。实际时间会受 VRRP 检测间隔、脚本失败次数、服务启动时间、ARP 更新和云平台转发策略影响。

演练 Nginx 或应用故障

仅停止 Keepalived，只能证明 VIP 选举可以工作，不能证明 Nginx 故障检查有效。可以在维护窗口中，在当前主节点执行：

sudo systemctl stop nginx

预期结果是健康检查连续失败，主节点有效优先级下降，备节点取得 VIP。此时应同时观察：

sudo journalctl -u keepalived -f
sudo journalctl -u nginx -n 50 --no-pager

恢复原节点服务：

sudo systemctl start nginx
sudo nginx -t
sudo systemctl is-active nginx

如果使用了 nopreempt，原节点恢复后不应自动抢回 VIP。这样可以先确认它已经处于健康状态，再执行计划内回切。

回切和回滚

使用 nopreempt 时，回切可以按以下顺序进行：

1. 确认原主节点的 Nginx、应用和健康检查已经恢复；
2. 在当前持有 VIP 的备节点停止 Keepalived；
3. 确认原主节点重新获得 VIP；
4. 从外部客户端验证 HTTP、HTTPS 和业务只读接口；
5. 再启动备节点 Keepalived，让其回到备状态。

停止当前主节点的 Keepalived 会再次造成短暂切换，不应在没有观察窗口的情况下操作。如果验证失败，应优先恢复到“只有一台节点持有 VIP”的状态，禁止两台服务器同时手工添加 VIP。

主备切换后仍无法访问的排障顺序

第一步：确认域名、VIP 和访问路径

先确认域名解析结果：

getent hosts example.com
dig +short example.com

如果域名仍解析到故障节点固定 IP，而不是 VIP，Keepalived 的切换不会改变 DNS 结果。DNS 变更还会受 TTL 和客户端缓存影响，因此固定 IP 入口应优先改为可漂移的 VIP 或平台浮动 IP。

ping 可以帮助判断基本连通性，但 ICMP 被禁用时，ping 失败不代表 80/443 一定不可用：

ping -c 3 192.0.2.10

如果需要观察到 80 端口的路径，可使用：

traceroute -n -T -p 80 192.0.2.10

traceroute 中出现 * 可能只是中间设备不返回探测报文，不能单独证明业务端口故障。最终仍应以 curl 的 TCP 连接和 HTTP 响应为准。

第二步：确认 VIP 是否真正归属备节点

在备节点执行：

ip -br addr show dev ens3
ip route

如果看不到 VIP，继续查看 Keepalived 日志：

sudo journalctl -u keepalived --since "-10 min" --no-pager
sudo systemctl status keepalived --no-pager

常见判断方式如下：

• 没有任何状态日志：Keepalived 可能未启动或服务名不正确；
• 日志显示配置解析失败：检查配置语法、网卡名、地址和权限；
• 日志显示持续收到对端但无法成为主节点：检查优先级、健康检查和是否启用 nopreempt；
• 两台都显示成为主节点：优先检查单播对端地址、VRRP 通信和防火墙；
• 备节点显示已成为主节点但外部仍不可达：进入云平台 VIP、ARP 和安全组检查。

第三步：确认备节点本机能否提供服务

在备节点执行：

sudo ss -lntp | grep -E ':(80|443)\b'
sudo nginx -t
sudo systemctl is-active nginx
sudo curl -v -H 'Host: example.com' http://127.0.0.1/healthz
sudo curl -v -H 'Host: example.com' http://127.0.0.1/readyz

不同结果代表不同方向：

• 本机 healthz 失败：Nginx 配置、进程或监听地址有问题；
• healthz 成功但 readyz 失败：后端应用或应用健康接口有问题；
• 本机两个接口都成功，VIP 访问失败：优先检查 VIP 归属、路由、防火墙和平台网络；
• HTTP 返回 502：Nginx 已经收到请求，但无法连接后端；
• HTTP 返回 404：请求可能进入了错误的 server_name 或默认站点；
• HTTPS 报证书错误：备节点证书、证书链、域名配置或文件权限不一致。

第四步：检查后端应用和错误日志

查看 Nginx 错误日志：

sudo tail -n 100 /var/log/nginx/error.log

如果系统使用独立站点日志，也应检查对应的 error.log。常见信息包括：

• connect() failed (111: Connection refused)：后端没有监听或端口配置错误；
• upstream timed out：后端响应过慢、依赖服务不可用或超时设置过短；
• no live upstreams：后端定义失效或全部被标记为不可用；
• 权限或证书错误：备节点文件属主、权限或路径不一致。

后端端口可单独测试：

sudo ss -lntp | grep ':8080'
curl -v --max-time 3 http://127.0.0.1:8080/healthz

如果后端只监听在某个特定地址，而 Nginx 配置使用 127.0.0.1，两者也可能无法连接。不要只修改 Nginx 超时时间来掩盖后端没有启动的问题。

第五步：检查防火墙、ARP 和平台转发

本机服务正常、VIP 也显示在备节点，但外部无法访问时，依次检查：

1. 主机防火墙是否允许 80/443；
2. 云平台安全组是否允许访问备节点；
3. 节点之间是否允许 VRRP 单播通信；
4. 上游是否接受新的免费 ARP；
5. 平台是否要求通过控制台或 API 绑定浮动 IP；
6. 客户端是否仍缓存旧的 MAC 地址。

同一二层网络中的测试客户端可以使用 arping 观察 VIP 的响应：

sudo arping -I ens3 -c 3 192.0.2.10

该命令只适合在网络条件允许的情况下使用，远程客户端或三层网络通常不能直接通过它判断业务入口。不要在没有确认平台支持的情况下手工执行 ip addr add 或强制刷新邻居表，因为可能造成重复 IP 或短时间双主。

数据一致性：VIP 切换不等于数据切换

配置一致性

两台服务器的 Nginx 配置、证书和应用版本必须一致，否则 VIP 虽然切换成功，用户看到的内容仍可能不同。建议每次发布至少完成以下动作：

1. 在非当前主节点更新配置；
2. 执行 nginx -t；
3. 在本机验证健康接口；
4. 对比主备配置和证书版本；
5. 再更新当前主节点；
6. 完成一次外部请求验证。

配置文件同步前，先查看差异：

sudo diff -ruN /etc/nginx/ /path/to/backup-nginx/

不要将运行日志、缓存目录和临时文件作为业务配置一起覆盖。对于含有 --delete 的同步命令，必须确认源端是正确版本，并提前备份目标端。

数据库和写入请求

如果两台服务器只是 Nginx 和应用的主备，而数据库仍然只有一个实例，那么切换 Nginx 并不会自动恢复数据库故障。应用可能出现以下情况：

• 页面可以打开，但登录失败；
• 查询正常，写入失败；
• 写入已经返回成功，但切换后读不到；
• 主节点接受了请求，数据尚未同步到备节点；
• 上传文件保存在故障节点本地，切换后出现文件不存在。

因此，数据库应根据业务要求设计单写入、复制、备份和故障恢复机制。没有经过验证的数据库复制，不应把“主备两台 Web 服务器”描述成完整的数据高可用。

一次写请求可能经历“应用收到请求、数据库提交、返回客户端”多个阶段。如果主节点在提交后、响应前发生故障，客户端可能重试，造成重复写入；如果主节点在响应前数据尚未持久化，切换后则可能出现数据缺失。演练时不能只访问首页，还应使用专门的测试记录验证：

• 写入前后是否能读到同一条记录；
• 切换期间是否出现重复记录；
• 上传文件是否仍可读取；
• 会话是否需要重新登录；
• 切换后应用是否继续连接正确的数据库。

RTO 与 RPO 的验收方式

演练时记录四个时间点：

1. 最后一次从外部客户端成功访问的时间；
2. 主节点被停止或故障注入的时间；
3. 备节点获得 VIP 的时间；
4. 外部客户端第一次连续成功访问的时间。

第 4 个时间点减去第 1 个时间点，可以得到一次演练的业务中断时长。数据方面，则应对比切换前后测试记录和文件版本，确认实际数据丢失窗口，而不是只根据 Keepalived 的日志推测 RPO。

恢复优先级与演练检查项

发生真实故障时，建议按以下优先级处理：

1. 先恢复入口：确认域名、VIP、路由和外部访问路径；
2. 再恢复 Nginx：确认备节点监听 80/443，语法、证书和站点配置正确；
3. 再恢复应用：确认后端进程、端口和依赖服务可用，消除 502/504；
4. 再核对数据：检查数据库写入、上传文件、会话和消息处理状态；
5. 最后处理回切：不要在原因未查清时立即把 VIP 切回原节点；
6. 保留现场：保存 Keepalived 日志、Nginx 日志、应用日志和故障时间线。

每次预演至少应核对以下项目：

• [ ] 香港服务器所在网络支持 VIP 或平台浮动 IP；
• [ ] 两台节点的 Nginx 配置、应用版本和证书一致；
• [ ] VIP 只在一台服务器上持有；
• [ ] Keepalived 单播对端地址和优先级正确；
• [ ] 主机防火墙、安全组和 VRRP 通信规则已验证；
• [ ] 健康检查能够识别 Nginx 正常但后端异常的情况；
• [ ] 从外部客户端验证了 HTTP 和 HTTPS；
• [ ] 分别演练了 Keepalived 停止、Nginx 停止和应用异常；
• [ ] 记录了实际切换时间和业务中断时间；
• [ ] 验证了写入、读取、上传和会话等关键状态；
• [ ] 明确了 nopreempt 下的回切步骤；
• [ ] 备份和配置回滚路径可以在维护窗口内执行。

只有当 VIP 归属、网络可达、Nginx 监听、后端就绪和数据状态都通过验证时，主备切换才算完成。对于“日志显示切换成功但仍无法访问”的问题，最有价值的排查入口不是重复重启 Keepalived，而是先确认 VIP 是否真的到达备节点，再逐层验证端口、Nginx、应用和数据。