Nginx + Keepalived 高可用环境中日志异常主因是主备切换后日志路径不一致、权限未继承、Nginx 未重载、SELinux 拦截或日志源混淆；须统一 error_log 路径、校验配置重载、检查 SELinux 和防火墙、区分 Nginx 与 Keepalived 日志。
在 Nginx + Keepalived 高可用环境中，日志异常往往不是孤立问题，而是主备切换、权限错配或日志路径未同步引发的连锁反应。排查重点不在“有没有日志”，而在“日志为什么没写到该写的地方”——尤其当主节点宕机、VIP漂移后，原日志路径可能失效或权限不继承。
确认 error_log 路径是否随角色切换保持一致
Keepalived 不接管 Nginx 的日志配置，但主备节点若使用不同路径（如主节点写 /data/logs/nginx/error.log，备节点仍用默认 /var/log/nginx/error.log），切换后日志就会“消失”。必须确保：
- 两台节点的 nginx.conf 中 error_log 指令完全一致，且指向同一逻辑路径（推荐使用绝对路径 + 共享存储或本地同步目录）
- 若用本地路径，需检查备节点对应目录是否存在、属主是否为 nginx 运行用户（如 www-data 或 nginx）
- 避免依赖相对路径或 $prefix 变量，防止编译安装路径差异导致解析偏差
检查 Keepalived 切换时 Nginx 是否真正重载或重启
很多故障源于 Keepalived 触发的健康检查脚本只 kill -9 nginx 进程，却未 clean pid 文件或未调用 nginx -s reload，导致新进程启动失败或沿用旧配置（含旧日志路径）。验证方式：
- 查看 nginx_check.sh 脚本末尾是否包含 nginx -s reload || nginx 或明确启动命令
- 切换后执行 ps aux | grep nginx，确认 worker 进程 UID 与配置中 user 指令一致
- 用 nginx -t -c /etc/nginx/nginx.conf 手动校验配置，避免因语法错误导致静默降级为默认日志路径
排查 SELinux 和防火墙对日志写入的拦截
主备节点 SELinux 状态常不一致：主节点关闭了，备节点仍 enforcing；或 audit 日志里有 avc denied 但未被发现。关键动作：
- 在备节点运行 ausearch -m avc -ts recent | grep nginx，查是否有 denied write 类型报错
- 临时设为 permissive：setenforce 0，再启 nginx 观察日志是否恢复（确认是 SELinux 问题后再针对性赋权）
- VRRP 使用组播地址 224.0.0.18，部分防火墙策略会拦截其通信，间接导致 Keepalived 状态误判、频繁切换，从而干扰日志连续性
区分 Nginx 日志与 Keepalived 自身日志的异常源头
常有人把 keepalived.log 里的 “VRRP_Instance(VI_1) Entering MASTER STATE” 当作 Nginx 故障线索，其实它只说明 VIP 已绑定。真正要盯的是：
- Keepalived 日志（默认 /var/log/messages 或 journalctl -u keepalived）：关注 track_script 执行结果、priority 变更、advert timeout 等
- Nginx 错误日志：聚焦 emerg / alert / error 级别，特别是 “bind() to 0.0.0.0:80 failed”、“open() “/xxx/error.log” failed” 这类路径/权限报错
- systemd journal：journalctl -u nginx -u keepalived --since “2 hours ago”，交叉比对时间线，定位切换瞬间的失败环节
