排查Nginx故障转移与Lua冲突，需确认Lua是否阻断upstream失败计数、是否覆盖proxy_pass流程、是否引发worker异常，并通过日志分析和配置隔离定位问题。
排查 Nginx 故障转移模块与 Lua 脚本执行冲突，关键在于厘清二者运行阶段、资源竞争点和错误表现特征。Nginx 的被动健康检查（max_fails/fail_timeout）和请求重试（proxy_next_upstream）属于 upstream 调度层逻辑，而 Lua 脚本（如 access_by_lua_block 或 content_by_lua_block）运行在请求处理流程中，若配置不当，可能干扰故障判定或掩盖真实失败原因。
确认 Lua 是否阻断了 upstream 的失败计数
Nginx 默认只对特定错误类型（如连接拒绝、超时、500/502/503/504）触发 max_fails 计数。如果 Lua 脚本在 access_by_lua_block 中提前返回 200 或拦截了原始后端错误（例如用 ngx.exit(200) 吞掉 502），上游错误就不会透传到 proxy 层，导致 Nginx 无法识别后端异常，max_fails 不会累加，故障节点无法下线。
- 检查 Lua 脚本是否调用
ngx.exit()、ngx.redirect()或修改了ngx.status，尤其避免在访问控制阶段“兜底返回成功” - 确保
proxy_next_upstream明确包含需重试的状态码，例如：proxy_next_upstream error timeout http_500 http_502 http_503 http_504; - 在
error.log中搜索upstream timed out或no live upstreams，对比是否有 Lua 日志先于这些记录出现
验证 Lua 模块是否影响 worker 进程稳定性
某些 Lua 操作（如阻塞式 I/O、未加保护的全局变量读写、cjson 解析超大响应体）可能导致 worker 进程卡顿或崩溃，间接使 upstream 健康检查失准——比如 worker 长时间无响应，Nginx 可能误判为后端不可达，或因进程重启丢失当前故障状态。
- 查看
error.log是否存在worker process is shutting down、segmentation fault或lua tcp socket read timeout等线索 - 禁用所有 Lua 指令（注释掉
access_by_lua_block、content_by_lua_block等），仅保留 upstream 配置，观察故障转移是否恢复正常 - 若使用 OpenResty，启用
lua_check_client_abort off;防止客户端中断引发 Lua 异常中断
检查 Lua 脚本是否覆盖或干扰 proxy_pass 行为
当 Lua 在 content_by_lua_block 中直接生成响应（如 ngx.say()），它会完全跳过 proxy_pass 流程，此时 upstream 的负载均衡、失败重试、backup 切换等机制全部失效。
- 确认 Lua 执行位置：仅在
access_by_lua_block或set_by_lua_block中做轻量判断或变量设置；避免在content_by_lua_block中替代反向代理逻辑 - 若必须用 Lua 调用后端，应使用
resty.http库异步发起请求，并手动实现重试与降级，而非依赖 Nginx 内置 upstream - 检查配置中是否同时存在
content_by_lua_block和proxy_pass在同一 location，这会导致配置冲突，Nginx 启动时通常报错"content phase handler" and "proxy_pass" cannot be used together
日志与调试建议
开启细粒度日志，定位冲突发生环节：
- 在 http 块中添加：
log_subrequest on;，让子请求（如 proxy_pass）也记入 access_log - 为 upstream 添加
verbose日志级别（OpenResty 支持）：upstream_log /var/log/nginx/upstream.log verbose; - 在 Lua 中用
ngx.log(ngx.WARN, "backend status:", ngx.status)输出关键状态，注意不要在 init_by_lua 中打日志（无请求上下文）
