Nginx 问题看起来都像“页面打不开”，但背后可能是 upstream 不通、端口错、路径转发错、HTTPS 配置错、静态资源路径错或超时设置太短。排障时先把请求链路拆开，效率会高很多。
先确认请求到达了哪里
浏览器报错只是入口，真正要看 Nginx access log 和 error log。access log 能看到状态码、请求路径、耗时和 upstream 状态；error log 会告诉你连接失败、超时、权限不足还是文件不存在。
如果日志里没有请求，说明问题可能在 DNS、端口、安全组或前置网关。如果日志有请求，再继续看 Nginx 到后端的转发。
502 优先检查 upstream
502 常见原因是后端服务没启动、端口不对、容器网络不通、协议不匹配或 upstream 主机名解析失败。先在 Nginx 所在机器上 curl 后端地址，确认它能直接访问。
如果后端是 Docker 容器，要区分宿主机端口、容器端口和 Compose service name。很多本地能通、容器里不通的问题，都出在网络命名空间不同。
超时要分连接和读取
接口慢时，Nginx 可能返回 504 或提前断开。排查时要看是连接后端超时，还是后端处理太久导致读取超时。前者通常是网络或服务不可达，后者通常要回到应用日志和慢查询。
不要一上来把超时时间调得很大。超时配置是兜底，不是性能优化。真正慢的接口仍要从业务、数据库和外部依赖查原因。
静态资源路径看 root 和 alias
前端构建产物部署时，404 经常来自 root、alias、try_files 和 history fallback 配置错误。SPA 页面刷新 404，要看是否把未知路径回退到 index.html；资源文件 404，则要看构建 base 路径和 Nginx 路径是否一致。
Nginx 排障的核心是顺着链路看证据：浏览器、访问日志、错误日志、upstream、应用日志。每一层确认一次，就不会在配置文件里盲改。
