502根因需优先查nginx error.log中upstream相关错误，重点识别“connection refused”“upstream timed out”“connection reset by peer”三类关键词，结合upstream地址、时间戳及上游日志交叉验证。
看到 502 Bad Gateway，别急着重启。真正能快速定位根因的，是 Nginx 的 error_log——它不是辅助材料，而是故障现场的第一手证据。
盯住 error_log 里的三类关键线索
每条 502 相关错误日志都自带上下文。重点抓：
-
错误类型关键词：如
"connect() failed (111: Connection refused)"→ 上游根本没监听；"upstream timed out (110: connection timed out)"→ 连上了但等不到响应；"recv() failed (104: Connection reset by peer)"→ 后端主动断连（常见于崩溃或内存溢出） -
upstream 地址：日志末尾的
upstream: "fastcgi://127.0.0.1:9000"或upstream: "http://backend:8080"明确告诉你 Nginx 尝试连的是谁——这个地址、端口、协议是否真实可达，必须验证 -
时间戳与请求上下文：结合
client、request字段，可判断是否特定路径（如/api/report）、特定用户或 IP 触发，从而区分是偶发抖动还是集中性故障
用一条命令归类高频原因
人工翻日志效率低。直接统计最近一小时最常出现的错误模式：
dcc-cli-gateway
下载
通过 `dcc-mcp-cli` 命令行工具控制实时 DCC 主机（Maya、Blender、Houdini、Photoshop、3ds Max 以及自定义的 Studio 工具）。 针对 ClawHub、OpenClaw、Cursor、Claude 和支持 shell 的 Agent 主机：验证网关健康状态、列出已注册的 DCC 实例、搜索工具、检查 Schema、调用工具——全程无需直接编写或发送 MCP 请求。 若系统中未安装 `dcc-mcp-cli`，需先征得用户同意，再从 GitHub
grep "502" /var/log/nginx/error.log | grep "$(date -d '1 hour ago' '+%Y/%m/%d %H')" | awk -F': ' '{print $3}' | cut -d' ' -f1-5 | sort | uniq -c | sort -nr
输出示例：
-
124 upstream timed out → 优先查
proxy_read_timeout或后端处理慢 -
87 Connection refused → 立即检查 PHP-FPM 是否运行、端口是否监听：
systemctl status php-fpm、netstat -tuln | grep :9000 -
32 Connection reset → 查后端应用日志（如 Laravel 的
storage/logs/laravel.log），大概率是脚本崩溃或 OOM
交叉验证上游日志，确认“后厨”状态
Nginx error_log 告诉你“传菜失败”，要知“为何失火”，必须看上游日志：
-
PHP-FPM：查
/var/log/php-fpm.log，找"server reached pm.max_children"（进程池打满）或"child exited on signal Segmentation fault"（段错误） -
Node.js / uWSGI：查对应应用日志，重点关注未捕获异常（
uncaughtException）、启动失败、OOM killer 杀进程记录（dmesg -T | grep -i "killed process"） -
远程后端服务：直接登录那台机器，执行
journalctl -u your-app --since "1 hour ago"，比只看 Nginx 日志更接近真相
配合 access_log 锁定问题请求特征
虽然 access_log 不记录根因，但它能帮你缩小范围：
- 确认日志格式含
$upstream_response_time和$upstream_addr，例如：log_format main '$remote_addr "$request" $status $upstream_response_time $upstream_addr'; - 搜索
grep ' 502 ' /var/log/nginx/access.log，关注：
–$upstream_addr是否一致（是否全指向同一台宕机节点）
–$upstream_response_time是-（零响应）还是具体数值（如62.345，说明超时）
– 请求路径是否集中在某个耗时接口（如导出报表、图片上传）
