在现代 Web 架构中，Nginx 最常见的使用场景不仅仅是作为静态文件服务器，更多时候是作为反向代理（Reverse Proxy）和负载均衡器。最近在部署前后端分离项目时，对 Nginx 的代理转发机制做了系统性的梳理，记录如下。

反向代理的核心概念 与正向代理（帮助客户端访问外部网络）不同，反向代理是代表服务器接收客户端的请求。对于客户端而言，Nginx 就是最终的服务器，它隐藏了后端真实的业务服务器（如 Tomcat、Node.js 或 Python 应用）。这样做的好处显而易见：提高了安全性，统一了 SSL 证书管理，并且可以灵活地进行负载均衡。

核心指令 proxy_pass 在配置文件中，最关键的指令就是 proxy_pass。它将请求转发到指定的 upstream 或具体的 IP:Port。需要注意的是 URL 结尾的斜杠处理：如果 proxy_pass 的目标地址后面带有斜杠，Nginx 会剔除掉匹配的路径部分；如果不带斜杠，则会把请求路径原封不动地拼接到后端地址上。这个细节在配置 API 转发时非常容易出错。

请求头的传递（Headers） 默认情况下，Nginx 在代理转发时会“重置”HTTP 请求头。如果不做特殊配置，后端应用获取到的 Host 往往是 Nginx 自身的 IP，而不是用户访问的域名；获取到的客户端 IP 也是 Nginx 的内网 IP。 为了解决这个问题，必须在 location 块中显式设置 proxy_set_header。通常需要传递 Host 字段以确保后端虚拟主机路由正确，以及传递 X-Real-IP 和 X-Forwarded-For 字段，以便后端日志能记录下用户的真实来源 IP。

关于 HTTPS 卸载（SSL Termination） 在生产环境中，为了减轻后端应用服务器的计算压力，通常会将 SSL/TLS 加密解密的工作交给性能更强的 Nginx 处理。Nginx 负责对外提供 HTTPS 服务，而对内则通过 HTTP 与后端通信。这种架构不仅提升了响应速度，还简化了证书的更新维护流程。

常见错误排查 运维中最怕见到的就是 502 Bad Gateway 错误。这通常意味着 Nginx 已经收到了请求，但无法连接到上游的后端服务器。排查思路一般是：先检查后端服务是否启动，再检查防火墙端口是否开放，最后检查 Nginx 配置中的 upstream 地址是否写错。