error_log 是排查 Nginx upstream 连接拒绝和 502 错误最直接入口，需调至 info 或 debug 级获取目标地址、errno（如111/113）、upstream 名称等关键上下文，并结合 netstat/ss、健康检查配置及 DNS 解析行为交叉验证根因。
当 Nginx 报“upstream refused connection”或 502 错误时，error_log 是最直接的排查入口。关键不是单纯打开日志，而是让日志输出足够多与 upstream 建立连接相关的细节，尤其是失败瞬间的上下文。
确保 error_log 级别足够高
Nginx 默认 error_log 级别是 error，但连接拒绝（如 Connection refused、No route to host）通常只在 info 或 debug 级别才记录完整原因和目标地址。生产环境不建议长期开 debug，但定位 upstream 连接问题时可临时启用：
- 在
http、stream或 server 块中添加：error_log /var/log/nginx/upstream_error.log info; - 重启或重载 Nginx：
nginx -s reload - 触发一次请求后，立即检查日志：
tail -f /var/log/nginx/upstream_error.log | grep -i "upstream\|connect\|refused"
关注日志中明确的错误线索
典型 upstream 连接拒绝日志会包含以下关键信息，逐条对照：
-
“connect() failed (111: Connection refused)”：后端进程未监听对应端口，或防火墙拦截。检查
netstat -tlnp | grep :端口号和ss -tlnp -
“connect() failed (113: No route to host)”：IP 不可达，常见于容器网络、跨主机通信或 DNS 解析到错误地址。用
ping或telnet ip port验证连通性 -
“no live upstreams while connecting to upstream”：所有 upstream server 被标记为 down（例如健康检查失败），或配置了
max_fails/fail_timeout导致临时剔除 - 日志中出现具体 upstream 名称和 server 地址：确认 Nginx 实际尝试连接的是哪个后端，避免配置 alias 或变量导致解析偏差
配合 upstream 健康检查与连接参数验证
仅靠 error_log 有时不够，需结合配置确认行为是否符合预期：
- 检查
upstream块是否启用了health_check（HTTP 模块）或check（需第三方模块），并确认健康检查路径/端口/间隔设置合理 - 确认
proxy_connect_timeout是否过短（默认 60s），在高延迟网络下可能误判为拒绝；可临时调大至 5–10 秒观察日志变化 - 若使用域名作为 upstream server（如
server backend.example.com:8080），Nginx 默认只在启动时解析一次 DNS。需加resolve参数（需 resolver 配置）或改用 IP 避免 DNS 缓存导致连接旧地址
进阶：用 debug 日志定位连接发起细节
如果 info 级仍无足够信息，启用 debug 日志（仅限临时诊断）：
- 编译时需含
--with-debug；配置中设：error_log /var/log/nginx/debug.log debug; - debug 日志会显示每次 upstream 请求的完整决策链：选哪个 server、DNS 解析结果、socket 创建、connect() 系统调用返回值、errno 含义等
- 重点搜索：
"upstream connect"、"connect to"、"failed"、"getaddrinfo"、"setsockopt" - 注意：debug 日志量极大，务必限制时间并及时关掉，避免磁盘打满
