语法错误虽不直接引发502，但会导致nginx启动或重载失败，使proxy_pass指向无效地址，上游无响应而返回502；需用nginx -t校验语法，-t确认生效配置，并注意https场景下proxy_ssl_server_name等关键指令缺失亦会因sni握手失败致502。
语法错误本身不会直接导致 502，但它会让 Nginx 启动失败或重载失败，进而使旧配置残留、新 upstream 未生效，或者 proxy_pass 指向一个根本不存在的地址——最终表现为请求被转发到空地址或错误端口，上游无响应，Nginx 就返回 502。
检查 Nginx 配置语法是否合法
这是最基础也最容易被跳过的一步。哪怕只多了一个分号、少了一个花括号，或用了中文标点，Nginx 都可能无法正确解析 location 或 upstream 块。
- 运行 nginx -t：它会校验全局语法，并提示出错行号和大致原因（例如 “unexpected end of file” 或 “invalid number of arguments in 'proxy_pass' directive”）
- 如果提示 “test is successful”，说明语法无硬性错误；但注意：语法合法 ≠ 逻辑正确，比如 proxy_pass https://example.com; 写对了，但如果没配 proxy_ssl_server_name on，仍会在 HTTPS 域名转发时因 SNI 握手失败而报 502
- 若使用 include 加载子配置，需确保所有被包含文件路径存在、权限可读，否则 nginx -t 也会报错
重点关注 HTTPS 反向代理特有的语法陷阱
当 proxy_pass 指向 HTTPS 域名时，常见配置缺失会导致 SSL 握手失败，Nginx 日志里会出现类似 “SSL_do_handshake() failed … sslv3 alert handshake failure” 的报错，最终归为 502。
- 必须显式开启 SNI 支持：proxy_ssl_server_name on;（否则 Nginx 默认用 IP 建连，不发 Server Name，后端 TLS 终止服务无法选中对应证书）
- 若 upstream 使用域名，需配合 proxy_ssl_name 指定期望的 SNI 名称，例如 proxy_ssl_name "api.example.com";
- 避免在 proxy_pass 中混用 HTTP 和 HTTPS 协议与 Host 头：比如 proxy_pass https://backend; 却又手动设 proxy_set_header Host http://backend;，会造成协议不一致
验证配置是否真正生效
语法正确、重载成功，不代表当前运行的 Nginx 正在用你刚改的配置。尤其在 Docker 或 systemd 环境下容易误判。
- 执行 nginx -T（大写 T）：输出当前**实际加载并生效的全部配置内容**，确认你修改的 server 块、upstream、proxy_pass 行确实存在于其中
- 检查是否多个 conf 文件冲突：比如 /etc/nginx/conf.d/*.conf 和 /etc/nginx/sites-enabled/ 同时存在，且有重复的 server_name，可能导致某段配置被覆盖或忽略
- 观察重载命令输出：nginx -s reload 成功不代表新配置已接管，要结合 ps aux | grep nginx 看 worker 进程启动时间是否更新，或用 kill -USR1 $(cat /var/run/nginx.pid) 强制日志 reopen，再查 error.log 是否有新条目
