nginx“请求分发失败”需按顺序验证日志线索、配置语法、后端连通性、资源限制：先查error.log中no live upstreams、connection refused等错误，再执行nginx -t校验配置，curl直连后端确认存活，最后检查连接数、磁盘、防火墙等资源瓶颈。
遇到 Web 服务不可用，比如页面打不开、接口返回异常，别急着改代码或重启整个系统。真正的问题往往藏在 Nginx 和后端之间的“交接地带”。排查的关键不是猜，而是按顺序验证每一层是否真正连通、是否按时响应、是否有资源瓶颈。
先看 Nginx 错误日志，定位第一线索
Nginx 自己不报错，但它会把失败原因记下来。打开 /var/log/nginx/error.log，重点找带 [error] 或 [crit] 的行：
- connect() failed (111: Connection refused) → 后端根本没监听，或者地址/端口写错了
- upstream timed out → 请求发出去了，但后端没回，超时了
- no live upstreams → upstream 配置里所有服务器都标记为 down，可能是健康检查失败
- recv() failed (104: Connection reset by peer) → 后端进程突然崩溃或主动断开连接
确认 Nginx 配置语法与代理路径正确
配置写错一个字母，Nginx 就可能静默失效：
- 运行 nginx -t，确保输出 “syntax is ok” 和 “test is successful”
- 检查 proxy_pass 地址是否和后端实际监听地址一致（例如写成
http://127.0.0.1:8000，但后端只监听localhost:8000或0.0.0.0:8000，部分系统解析行为不同） - 确认 upstream 块中服务器状态正常，没有误加
down或backup - 若用了 Unix socket（如
unix:/run/php/php-fpm.sock），检查文件是否存在、权限是否允许 nginx 用户（通常是 www-data 或 nginx）读写
验证后端服务真实可用且响应及时
绕过 Nginx 直接测后端，能快速区分问题是出在代理层还是应用层：
- 用 curl -v http://localhost:3000/health（替换为你后端端口和路径）测试是否能通、响应码是否 200
- 查后端进程：systemctl status your-app 或 ps aux | grep node，确认进程存活
- 看后端日志（如
/var/log/myapp/error.log），常见问题包括数据库连接失败、内存溢出、未捕获异常 - 如果后端响应慢，用 time curl -o /dev/null -s -w "%{http_code}\n" http://localhost:3000/api 测真实耗时，对比 Nginx 的
proxy_read_timeout
检查连接与资源限制是否卡住请求
即使服务活着，也可能因资源不足被系统或 Nginx 主动拒绝：
- 查当前连接数：netstat -anp | grep :80 | wc -l（Nginx 端口）和 netstat -anp | grep :3000 | wc -l（后端端口），接近上限需调参
- PHP-FPM 检查
pm.max_children是否被占满；Node.js 查最大文件描述符（ulimit -n）是否足够 - 确认磁盘空间：df -h，尤其是
/var/log和/tmp，日志打满会导致服务异常 - 防火墙是否放行：用 telnet 127.0.0.1 3000 或 nc -zv localhost 3000 测试本地连通性
