“connection refused”或“no route to host”报错基本锁定upstream端口配置错误，需确认upstream地址和端口真实可达：检查docker中localhost误用、后端监听地址（如127.0.0.1 vs 0.0.0.0）、防火墙拦截、proxy_pass协议端口一致性、unix socket权限、upstream名称拼写错误及dns解析准确性。
直接看 Nginx error.log 里是否出现 “Connection refused” 或 “No route to host”，这类报错基本锁定 upstream 端口配置错误。
确认 upstream 地址和端口是否真实可达
上游服务必须在指定 IP 和端口上监听，且能被 Nginx 所在机器访问到。常见错误包括：
- Docker 容器内写
localhost:8080—— 实际应改用宿主机 IP、Docker 网络别名（如backend:8080）或host.docker.internal - 后端服务只监听
127.0.0.1:8080，但 Nginx 尝试连0.0.0.0:8080或其他 IP —— 检查后端绑定地址，改为0.0.0.0:8080或对应网卡地址 - 防火墙/安全组拦截了该端口 —— 在 Nginx 服务器上执行
telnet 192.168.1.100 3000或nc -zv 192.168.1.100 3000测试连通性
核对 Nginx 配置中 proxy_pass 的协议与端口一致性
proxy_pass 后的地址必须与 upstream 实际暴露的协议、端口完全匹配：
- 后端是 HTTP 服务，却配成
https://backend:8443→ 导致连接建立后协议不兼容，常表现为 502 - 后端监听 8080，但 proxy_pass 写成
http://backend:80→ 连接成功但无响应，Nginx 等待超时后可能返回 502 或 504 - 使用 Unix socket（如
unix:/var/run/php-fpm.sock）时，检查 socket 文件是否存在、权限是否允许 Nginx worker 进程读写
验证 upstream 块是否被正确引用
容易忽略的是：upstream 定义了，但 location 中没用它，或者用了拼写错误的名字：
- 定义：
upstream api_backend { server 10.0.1.5:8000; } - 错误引用：
proxy_pass http://api_backends;（多了一个 s）→ Nginx 启动不报错，但请求会 fallback 到默认 resolver 或失败，日志显示connect() failed (111: Connection refused) - 检查方法：
nginx -t不会发现名字不匹配问题，必须结合 error.log + 实际请求路径交叉验证
排查 DNS 解析导致的端口误判
当 upstream 使用域名（如 server backend.example.com:3000），而 DNS 解析结果指向错误 IP 或端口未开放时，也会表现为端口级失败：
- 执行
nslookup backend.example.com或dig +short backend.example.com查看解析 IP - 再对该 IP 执行端口探测：
nc -zv $(nslookup backend.example.com | tail -1) 3000 - Nginx 默认不缓存 DNS，每次请求都解析；若 DNS 不稳定，可能导致部分请求连错地址，间歇性 502
