该报错本质是Nginx无法连接后端服务，根本原因是目标IP和端口无进程监听；需依次验证后端进程状态、端口监听情况（netstat/ss）、proxy_pass配置一致性、系统级限制（OOM、防火墙、文件描述符等），并区分111（拒绝）与110（超时）错误码。
这个报错本质是 Nginx 在转发请求时，连不上后端服务。它不表示 Nginx 自己坏了，而是“伸手没够着”——目标地址和端口上压根没人监听。
先确认后端进程和端口状态
别急着改配置，先看最基础的两件事：
- 运行 ps aux | grep your-app-name，确认应用进程确实在运行，且状态不是 Z（僵尸）或 <defunct>
- 运行 netstat -tlnp | grep :端口号（比如
:8080），检查是否有 LISTEN 状态及对应 PID；若没结果，说明服务根本没监听该端口 - 在 Nginx 所在服务器上执行 curl -v http://127.0.0.1:端口号/health 或 telnet 127.0.0.1 端口号，能通才算真正就绪
核对 Nginx 配置与后端实际监听方式是否一致
常见错配场景包括：
- 后端只监听 127.0.0.1:8080，但 Nginx 的
proxy_pass写的是http://192.168.1.100:8080——跨网卡访问被拒绝 - 后端用 Unix socket（如
/tmp/app.sock），Nginx 却配置成proxy_pass http://127.0.0.1:8080 -
upstream块里写的是server 127.0.0.1:9000，但 PHP-FPM 实际监听的是/tmp/php.sock -
proxy_pass http://backend/和proxy_pass http://backend;行为不同：前者会自动拼接路径，后者直接替换整个 URI，容易发到错误路径被后端拒绝
排查系统级限制
尤其在资源紧张的环境，这些底层问题容易被忽略：
- 检查是否触发 OOM Kill：运行 dmesg -T | grep -i "killed process"，看后端进程是否被内核强制杀掉
- 确认文件描述符是否耗尽：高并发下可能占满，影响新连接建立
- 检查防火墙或 SELinux 是否拦截了本地 loopback 流量（少见但存在），可用 iptables -L -n 或 sestatus 初步判断
- 验证系统最大连接数限制：默认常为 1024，可通过 ulimit -n 查看，必要时调整
区分 111 和 110 错误码
两者表现相似但原因不同，需分开处理：
- (111: Connection refused)：目标端口明确拒绝连接，说明那里没有服务在监听，或监听地址不匹配
- (110: Connection timed out)：Nginx 发起了连接，但等不到响应，常见于网络不通、防火墙丢包、DNS 解析异常（如域名解析出多个 IP，仅部分放行）或目标服务僵死无响应
