Nginx upstream connection refused如何解决?

在网站的日常运维中，Nginx作为高性能的反向代理服务器，承担着流量分发的核心重任。然而，当用户访问网站时突然遭遇502 Bad Gateway错误，或者Nginx错误日志中频繁出现“connect() failed (111: Connection refused) while connecting to upstream”的报错时，往往意味着Nginx与后端服务(Upstream)之间的通信出现了严重阻断。这个错误本质上是一个明确的系统级信号，表示Nginx尝试建立连接时，目标端口没有进程在监听。面对这种突发状况，我们需要冷静分析，通过科学的排查路径来快速恢复服务。

第一步：查阅错误日志，精准定位故障源头

排查问题的首要原则是让数据说话。当出现Connection refused错误时，第一步应当是查看Nginx的错误日志(通常位于 /var/log/nginx/error.log)。通过执行 tail -f /var/log/nginx/error.log 命令实时监控日志，我们可以清晰地看到报错详情。日志中不仅会明确提示“Connection refused”，还会包含请求的具体路径以及Nginx尝试连接的上游地址(例如 http://127.0.0.1:8080)。这为我们提供了最直接的排查线索，告诉我们究竟是哪个IP和端口的后端服务出现了问题。

第二步：验证后端服务状态与端口监听

确认了目标地址后，我们需要检查该后端服务是否真正在运行。可以通过执行 ss -tlnp | grep :8080 或 netstat -tlnp | grep 8080 命令来查看端口的监听状态。如果命令执行后没有任何输出，说明后端服务(如PHP-FPM、Tomcat、Node.js等)根本没有启动，或者启动失败导致端口未开放。此时，应前往检查对应后端服务的运行状态，例如执行 systemctl status php-fpm，若发现服务处于inactive状态，将其启动即可。如果后端服务已启动，但Nginx依然报错，则需要仔细核对Nginx配置文件中的 proxy_pass 或 fastcgi_pass 指令，确认填写的端口号是否与后端实际监听的端口完全一致。

第三步：排查Unix Socket路径与权限问题

除了TCP端口连接，Nginx与后端服务之间也经常使用Unix Socket进行通信。如果日志中提示的是 connect() to unix:/run/php/php8.1-fpm.sock failed (2: No such file or directory)，则说明Socket文件不存在。这通常是因为Nginx配置中的Socket路径与后端服务(如PHP-FPM的 www.conf)中配置的 listen 路径不一致所致。此外，权限问题也是导致Socket连接失败的常见原因。如果Nginx的运行用户与Socket文件的属主不一致，Nginx将无权访问该文件。行之有效的解决方案是统一两端的Socket路径，并在后端配置中明确设置Socket文件的属主、属组及读写权限(例如设置为 www-data 用户及 0660 权限)，修改后重启相关服务即可生效。

第四步：检查系统防火墙与安全组规则

如果后端服务运行正常，端口也在监听，且配置路径无误，那么问题很可能出在网络层面的拦截上。服务器本地的防火墙(如iptables、ufw)或者云服务商控制台的安全组规则，可能没有放行Nginx与后端服务之间的通信端口。特别是在容器化部署(如Docker)或跨主机部署的场景下，网络策略的变更极易导致连接被拒绝。此时，需要检查并放行相应的端口，或者使用 curl 命令在Nginx所在服务器本地直接访问后端接口，以验证网络连通性是否畅通。

总结

面对Nginx的upstream connection refused错误，核心的排查逻辑可以概括为：看日志定地址、查进程看端口、核配置对路径、查网络排拦截。只要遵循这一套标准化的排查流程，绝大多数代理连接故障都能被迅速定位并解决，从而保障网站的稳定运行。

纵横云服务器租赁，欢迎随时联系，客服联系方式：QQ3494196421,手机微信19906048601。