“Connection refused”本质是内核返回RST包，表明目标IP+端口无监听进程或被防火墙/SELinux/安全组拦截；需用ss/netstat确认真实监听状态（注意0.0.0.0 vs 127.0.0.1）、检查Docker映射、Unix socket协议匹配、防火墙规则、ephemeral port及文件描述符限制，并结合日志时间点交叉验证。
遇到 Nginx 报“Connection refused”，本质是操作系统内核明确拒绝建连——它发出了 RST 包，说明目标地址+端口没有监听进程，或被系统策略拦截。排查不能只看配置，必须下沉到网络栈和资源层。
确认后端是否真实监听对应地址和端口
服务“启动了”不等于“正在监听”。常见问题包括绑定地址错误、端口冲突或容器映射异常：
- 执行 ss -tuln | grep :8080，检查输出中 Listen 地址是否为 0.0.0.0:8080 或具体网卡 IP；若只显示 127.0.0.1:8080，Nginx 就无法从外部访问
- 用 netstat -tulnp | grep :8080 查 PID，再运行 ps -p PID -o pid,comm,args 确认该进程确实是你的后端，而非残留旧进程
- Docker 环境下，执行 docker port
核对宿主机端口映射（如 8080->0.0.0.0:3000 表示容器内 3000 映射到宿主机 8080） - 若用 Unix socket，proxy_pass 必须写成 unix:/tmp/app.sock，写成 http://127.0.0.1:8080 会协议错配直接拒连
检查防火墙、SELinux 与云环境安全组
这些组件可能在连接到达监听进程前就截断请求，且通常不记录详细日志：
- CentOS 7 默认启用 firewalld：firewall-cmd --list-all，确认目标端口（如 8080）在 public zone 的 ports 列表中
- 若用 iptables，运行 sudo iptables -L OUTPUT -n -v 查看出向规则是否放行
- 执行 getenforce，若返回 Enforcing，临时设为 permissive：sudo setenforce 0 测试是否恢复；若确认是 SELinux 导致，用 audit2why -a 分析日志
- 云服务器（如阿里云、AWS）需检查安全组入方向规则，确保允许 Nginx 所在机器 IP 访问后端端口
验证系统级资源是否耗尽
低配机器或高并发场景下，ephemeral port 或文件描述符不足会导致内核静默拒绝新连接：
- 查看临时端口范围：cat /proc/sys/net/ipv4/ip_local_port_range（默认 32768–60999，仅约 28K 可用），压测时易耗尽；可扩至 1024 65535
- 统计已分配 ephemeral port 数量：netstat -an | awk '$4 ~ /:[0-9]+$/ {print $4}' | cut -d: -f2 | sort | uniq -c | sort -nr | head -10
- 检查 Nginx worker 进程的文件描述符限制：cat /proc/$(pgrep nginx)/limits | grep "Max open files"；若为 1024，需在 /etc/security/limits.conf 中调高并重启 worker
- 运行 dmesg -T | grep -i "killed process"，确认 OOM Killer 是否干掉后端进程（如 Java 或 Node 进程被杀）
结合 Nginx 错误日志交叉验证
日志是第一线索，重点不是报错本身，而是错误出现的时间点和上下文：
- connect() failed (111: Connection refused)：说明 Nginx 尝试 connect 时内核返回 RST，目标无监听或被拦截
- 该错误若集中出现在某次部署、扩容或配置变更后，大概率是监听地址/端口/防火墙变更所致
- 若同时伴随 no live upstreams，说明健康检查持续失败，需回溯 upstream 配置中的 max_fails 和 fail_timeout
- 不要忽略日志时间戳，用 date -d "@$(stat -c %Z /var/log/nginx/error.log)" 确认日志最后更新时间是否与故障发生一致
