Nginx 502 与 504 怎么排查？先看上游状态，再看超时原因
网站显示 502 或 504，并不意味着需要重装 Nginx。反向代理站点往往同时经过 CDN、负载均衡、Nginx、应用服务和数据库；错误可能出在其中任意相邻环节。正确顺序是确认报错层、找同一请求的日志，再检查它访问的上游。
先辨认 502 和 504 的含义
在常见代理场景中，502 表示网关未从上游获得有效响应，可能涉及连接被拒绝、上游提前关闭或协议不匹配；504 表示等待上游超时。应用或前置代理也可能返回这两个状态码，因此不能仅凭浏览器页面样式认定是这台 Nginx 生成的错误。
记录请求发生时间、路径、请求标识、是否只有特定接口失败，以及前端是否经过 CDN。检查相关层的访问日志中有没有同一请求。Nginx 根本没有记录该请求时，先核对前置代理、DNS 和日志配置；有记录时，再结合上游状态与错误日志判断。
找到错误发生阶段
在常见 Linux 安装中可以先查看以下信息，日志路径应以本站配置为准：
sudo nginx -t
sudo systemctl status nginx --no-pager
sudo tail -n 100 /var/log/nginx/error.log
sudo ss -lntp
nginx -t 用于检查配置语法与相关文件，不能证明后端应用健康。读取日志时，将时间、请求路径和上游地址连起来看：connect() failed 且附有拒绝连接信息，先查监听端口；upstream prematurely closed connection，先查应用退出、崩溃和资源限制；upstream timed out 则继续看发生在建立连接还是读取响应阶段。
如果站点使用 PHP-FPM 的 FastCGI 通道，应检查对应服务与 socket，不能照搬 HTTP 反向代理的端口假设。socket 路径错误、运行用户无权访问、PHP-FPM 进程池耗尽，都可能表现为网关错误。只修正已确认的路径或权限，不要把 socket 或网站目录统一改成任何人可写。
在 Nginx 所在环境直接测试上游
假设真实配置指向本机 3000 端口，并且应用确实提供无副作用的 /health 检查接口，可以做一次请求：
curl --max-time 5 -sS -o /dev/null -w 'status=%{http_code} total=%{time_total}\n' http://127.0.0.1:3000/health
把地址、端口和路径换成实际值。没有健康检查接口时，选择已确认不会产生写入的页面；不要拿支付、下单或任务创建接口反复测试。连接立即失败时，查看应用是否启动、是否监听预期地址；能连接但超过测试时限时，查看应用线程、数据库连接池及外部依赖。
如果 Nginx 在容器中，127.0.0.1 指向的是该容器自身；宿主机请求成功，不代表容器到上游的路径可用，应在等效网络环境里验证。上游要求特定 Host、HTTPS 或认证时，也要按实际代理条件测试，否则一次返回异常不能直接证明应用故障。
504 要找出时间花在哪里
先对照应用日志判断慢请求是在数据库查询、锁等待、远程 API 还是任务队列中耗时。若只有报表导出超时，普通页面正常，应针对该工作负载优化查询或改为后台任务；若所有接口一起变慢，则更需要检查资源耗尽与共享依赖。
Nginx 的 proxy_connect_timeout 管建立上游连接，proxy_read_timeout 管相邻两次读取上游响应之间的等待，并非整个请求统一的总时长。PHP-FPM 则使用相应的 FastCGI 配置。把所有超时一并加大，可能只是让更多连接长期等待。Nginx HTTP 代理模块文档
访问日志可按需要加入 $request_time、$upstream_connect_time、$upstream_response_time 和 $upstream_status，对照整体耗时与上游耗时。多次上游尝试时，变量可能包含多个值，应按实际请求链解释；记录时避免写入密码、令牌及敏感正文。Nginx 上游变量文档
修复后，验证实际业务并保留回退
若故障紧随应用发布出现，优先判断能否回退到已验证版本；数据库结构已变化时，必须确认旧版本仍兼容。配置修改前保存原值，语法检查通过后再重新加载；验证既要包含普通页面，也要包含原来失败的业务路径。
对需要增加超时的正常长任务，先确定合理等待上限，再核对 CDN、负载均衡和应用自身的限制是否协调。支付或创建订单请求失败后，不能不加判断地重试，因为服务器可能已完成写入却未成功返回响应。
观察错误比例、响应时间、应用进程与连接池是否恢复稳定。若 502 减少但排队更严重，说明只是改变了症状，应恢复临时参数并继续定位上游瓶颈。把出错请求、日志证据和最终处理方式保留下来，便于下次快速区分同类故障。