Nginx负载均衡与反向代理核心是三步：定义upstream、配置server转发、正确使用proxy_pass的URI处理方式；502/504及路径问题多因proxy_pass尾部斜杠误用、upstream健康检查缺失、必要header未透传或resolver未生效所致。
直接说结论：Nginx 做负载均衡 + 反向代理，核心就三步——定义上游服务器组、配置 server 块转发请求、选对 proxy_pass 的 URI 处理方式。多数 502/504 或后端收不到路径的问题，都出在最后这一步。
怎么写 upstream 块才不踩坑
upstream 不只是列 IP，关键在连接行为控制：
-
least_conn比默认轮询更合理，尤其当后端处理时长差异大时； - 务必加
max_fails=3 fail_timeout=30s，否则单点挂掉后 Nginx 还会持续重试，拖垮整体响应； - 如果后端是容器或动态扩缩容环境，别硬写 IP，改用
resolve+ DNS 名（需开启resolver），但注意 TTL 缓存问题； - 健康检查不能只靠
max_fails，生产环境建议配合health_check interval=5 fails=2 passes=2（需 stream 模块或商业版，开源版只能靠被动检测）。
proxy_pass 后面带不带斜杠，后果天差地别
这是最常导致 404 或后端收不到完整 path 的地方：
-
proxy_pass http://backend;（无尾部/）→ 原样转发请求 URI，比如/api/v1/users会完整传给后端； -
proxy_pass http://backend/;（有尾部/）→ 会剥离 location 匹配前缀，再拼接，比如location /api/ { proxy_pass http://backend/; }，则/api/v1/users实际发给后端的是/v1/users； - 千万别混用：比如
location /api { proxy_pass http://backend/; }（location没尾斜杠，proxy_pass有），这时 Nginx 会把/api整个替换为空，结果可能变成//v1/users，后端解析失败。
反向代理必须加的 proxy_set_header
缺这几个 header，后端拿不到真实客户端信息，日志和鉴权全乱：
-
proxy_set_header Host $host;：不加的话，后端收到的是 upstream 名（如backend），不是原始域名； -
proxy_set_header X-Real-IP $remote_addr;和proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;：否则request.remote_addr在 Flask/Django 里永远是 Nginx 的内网 IP； -
proxy_set_header X-Forwarded-Proto $scheme;：后端判断 HTTPS 必须靠它，否则跳转链接变 HTTP； - 别漏
proxy_http_version 1.1;和proxy_set_header Upgrade $http_upgrade;，否则 WebSocket 连接直接断开。
为什么 reload 后出现 502，但 curl 后端又通
常见原因不是后端挂了，而是 Nginx 进程没拿到新配置里的 resolver 或 upstream 变更：
- 改了
upstream里 IP 或加了resolve，但没执行nginx -t && nginx -s reload，只 kill -HUP； - DNS 解析失败时，Nginx 不报错，但 upstream 成员状态为
unresolved，nginx -s reload后也不会自动重查，得重启主进程（nginx -s stop && nginx）； - SELinux 开启时，
proxy_pass到非标准端口（如 8080）可能被拦截，看ausearch -m avc -ts recent，临时放开用setsebool -P httpd_can_network_connect 1； -
proxy_buffering off开着又没配proxy_buffer_size，大响应体直接触发 502。
真正麻烦的从来不是写几行配置，而是 upstream 状态看不见、header 转发被覆盖、URI 重写逻辑和 location 匹配规则咬在一起——调的时候建议开 error_log /var/log/nginx/error.log debug;，重点盯 http proxy 相关行，比猜快得多。
