该报错表示Nginx无法连接后端服务，根本原因是目标IP和端口无进程监听；常见情形包括后端未启动、监听地址不匹配（如仅127.0.0.1却配置为远程IP）、端口被占、Unix套接字与TCP端口配置不一致，或防火墙/SELinux等系统级限制。
这个报错不是 Nginx 本身出错，而是它在尝试把用户请求转发给后端服务（比如 Java 应用、PHP-FPM、Node.js 等）时，连接失败了。核心意思是：Nginx 找不到那个地址+端口上正在监听的服务。
关键原因：后端服务根本没在目标地址和端口上监听
错误码 111（Connection refused）在 Linux 网络层有明确语义：客户端调用了 connect()，但目标主机的内核直接回了一个 RST 包——因为它压根没有进程在对应 IP 和端口上 bind() + listen()。常见情况包括：
- 后端应用进程根本没启动，或启动后异常退出了
- 后端只监听了
127.0.0.1:8060，但 Nginx 配置的是proxy_pass http://192.168.1.100:8060，跨网卡访问被拒绝 - 后端监听的是 Unix socket（如
/tmp/app.sock），但 Nginx 的proxy_pass写成了http://127.0.0.1:8060 - 端口被其他进程占用，后端启动时 fallback 到别的端口，而 Nginx 还在连旧端口
快速验证三步法
不看日志、不改配置，先确认基础连通性：
AI舌诊面诊问诊医疗系统+诊疗商城系统源码
下载
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
-
查进程：运行
ps aux | grep your-app-name，确认应用进程存在且状态为S或R -
查端口：运行
netstat -tlnp | grep :端口号（如:8060），看是否有 LISTEN 状态及对应 PID；若无，说明没监听 -
本地直连测试：在服务器上执行
curl -v http://127.0.0.1:端口号/health或telnet 127.0.0.1 端口号，能通才说明服务就绪
Nginx 配置常见陷阱
即使后端跑着，Nginx 自身配置错也会触发该报错：
- proxy_pass 地址写死为 127.0.0.1，但后端实际部署在另一台机器或容器里：应改为真实 IP 或 upstream 名称
-
upstream 块中 server 地址配错：比如写成
server 127.0.0.1:9000，但 PHP-FPM 实际监听的是/tmp/php.sock -
location 中 proxy_pass 末尾斜杠不一致导致路径拼接错误：例如
proxy_pass http://backend/;和proxy_pass http://backend;行为不同，可能让请求发到不存在的路径而被后端直接拒绝 -
防火墙或安全组拦截了本机到本机的 loopback 流量（少见但存在）：检查
iptables -L -n或云平台安全组规则
别忽略资源类底层问题
尤其在低配服务器（如 2核2G）上，容易被忽视：
-
OOM Kill：系统内存耗尽，内核强制杀掉后端进程（如 Java 应用），
dmesg -T | grep -i "killed process"可查证据 -
文件描述符耗尽：后端大量短连接未释放，
cat /proc/$(pgrep -f your-app)/limits | grep "Max open files"查上限，lsof -p $(pgrep -f your-app) | wc -l查已用数 - SELinux 或 AppArmor 限制网络绑定：在 CentOS/RHEL 上临时设为 permissive 模式测试是否缓解
