直接查看 /var/log/nginx/error.log，重点筛选含 upstream 和错误编号的行，如 connect() failed (111: connection refused)、upstream timed out (110: connection timed out)、upstream sent too big header 等，可快速定位 502 根源；配合 tail -f | grep -i 实时过滤及 client/request/upstream 上下文交叉验证，高效区分后端宕机、超时或响应头过大等问题。
直接看 /var/log/nginx/error.log，重点抓带 upstream 和错误编号的行——这是最快定位 502 根源的方式，比重启服务、改配置、查网络都靠前。
盯住日志里那几个关键错误码
错误日志不是泛读，要快速扫出这几类线索：
-
"connect() failed (111: Connection refused)"：Nginx 根本连不上后端。常见于后端没启动、端口写错、容器内用了
127.0.0.1却没映射对、防火墙拦了连接。 -
"upstream timed out (110: Connection timed out)"：连是连上了，但等响应超时。问题大概率在后端处理慢、卡死、或 Nginx 的
proxy_read_timeout设得太小。 -
"upstream sent too big header"：后端返回的响应头太大（比如 Cookie 或 Set-Cookie 过长），超出 Nginx 默认的 1KB 缓冲，需调大
proxy_buffer_size。 -
"SSL alert number 80"：HTTPS 反代时 TLS 握手失败，90% 是漏了
proxy_ssl_server_name on;，导致 SNI 不传，后端证书校验不过。
用命令实时过滤，别手动翻日志
别打开文件一行行找，终端里敲这一条就能聚焦问题：
tail -f /var/log/nginx/error.log | grep -i "502\|upstream\|timeout\|refused\|header"
请求一复现，错误立刻滚动出来；加 -n 50 可看最近 50 行历史，配合 curl 触发一次请求，再看日志输出，因果关系一目了然。
结合请求上下文交叉验证
日志里每条报错后面通常跟着：client: X.X.X.X, server: example.com, request: "GET /api/user HTTP/1.1", upstream: "http://127.0.0.1:8000/api/user"。这三段信息很关键：
- client IP：确认是不是特定用户或某类客户端触发（比如爬虫、旧版 App）；
- server name 和 request path：锁定是哪个域名、哪个接口出问题，缩小排查范围；
-
upstream 地址：直接拿这个地址去
curl -v http://127.0.0.1:8000/api/user直连测试，看是否真能通、多久返回、返回什么状态码——绕过 Nginx 验证后端本身是否健康。
别只看 error.log，顺手查 upstream 日志
Nginx 日志告诉你“没收到响应”，但不告诉你“为什么没收到”。这时必须切到后端侧：
- PHP-FPM：看
/var/log/php-fpm.log或catalina.out（Tomcat）、pm2 logs（Node.js）； - 关注是否有
segmentation fault、out of memory、connection reset、worker exited等关键词； - 如果后端日志里有大量
unable to fork或pool is busy，说明进程池或连接数已耗尽，不是 Nginx 的问题，而是后端资源瓶颈。
