排查Nginx故障转移需依次验证：upstream后端连通性、错误日志报错、proxy_next_upstream配置、健康检查路径有效性、fallback静态资源路径及权限、include文件是否存在且可读。
排查Nginx故障转移配置中绝对路径或文件缺失，核心是确认所有被引用的路径真实存在、权限正确，且未被配置逻辑意外跳过。
检查 upstream 指向的后端地址是否可达
故障转移依赖于 upstream 块中定义的服务器列表。若其中某台服务器地址写错（如 IP 不存在、端口未监听），Nginx 在尝试连接失败后才会触发 fallback，但错误本身可能被掩盖。
- 用 curl -I http://192.168.1.10:8080/health 或 telnet 192.168.1.10 8080 手动验证每个 upstream 成员的连通性
- 检查 Nginx 错误日志中是否有类似 "upstream connect error or timeout" 或 "no live upstreams" 的记录
- 确保 proxy_next_upstream 启用了对应错误类型（如 error timeout http_502）
验证健康检查所依赖的路径和响应内容
如果启用了主动健康检查（如 commercial 版本的 health_check 指令，或 OpenResty + lua_healthcheck），其检查路径（如 /healthz）必须是真实可访问的 endpoint，且返回状态码需匹配配置要求。
- 确认该路径在后端服务中已部署，不是仅存在于开发环境的 mock 接口
- 检查返回响应头中是否含 Content-Length，某些健康检查对空响应体敏感
- 若使用自定义检查脚本或 Lua 模块，确保其文件（如 /etc/nginx/lua/check.lua）存在且 Nginx 用户有读取权限
核对 fallback location 或 error_page 指向的静态资源路径
当故障转移触发后，Nginx 常通过 error_page 502 /fallback.html 或 location = /fallback.html { root /var/www/errors; } 提供兜底页面。此时 root 路径或 alias 路径极易出错。
- 执行 ls -l /var/www/errors/fallback.html 确认文件存在，且父目录可被 Nginx worker 进程访问（通常属主为 www-data 或 nginx）
- 若用 alias，注意末尾斜杠： alias /var/www/errors/; 是正确的，而 alias /var/www/errors;（无斜杠）会导致路径拼接错误
- 用 nginx -t 可校验语法，但不会验证文件是否存在——需人工或脚本补充检查
排查 include 文件路径是否失效
大型部署常把 upstream 或 health check 配置拆到独立文件（如 include /etc/nginx/upstreams/*.conf;）。若该目录被误删、重命名或权限收紧，Nginx 启动时会静默跳过，导致故障转移逻辑完全不生效。
- 运行 nginx -T 2>/dev/null | grep -A5 "upstream.*backend" 查看实际加载的 upstream 定义
- 检查 include 指令中的路径是否存在：ls -ld /etc/nginx/upstreams/
- 确认该目录下有 .conf 文件且非空：find /etc/nginx/upstreams/ -name "*.conf" -exec ls -l {} \;
