还在被502折磨？Nginx反向代理配置，看这一篇就够了

大家好，我是站长。做网站运维这么多年，要说哪个配置最让人又爱又恨，Nginx反向代理绝对排得上号。爱它，是因为它能让我们的服务架构变得无比灵活；恨它，是因为一旦配置不当，各种502、504错误能让人瞬间崩溃。

今天这篇文章，我们不谈虚的，直接切入正题，把Nginx反向代理的配置逻辑、实操步骤以及那些年我们踩过的坑，一次性讲清楚。无论你是刚入门的运维新手，还是被项目进度逼着上手的开发者，这篇内容都能帮你省下不少排查问题的时间。

一、为什么你的架构需要反向代理？

在动手写配置之前，我们得先想明白一个问题：为什么要用反向代理？ 简单来说，它就像是客户端和后端服务器之间的一个“调度员”。

负载均衡： 把海量请求分发给多台后端服务器，避免单点压力过大。
安全隔离： 后端服务器不直接暴露公网IP，隐藏真实拓扑。
统一入口： 无论后端是Java、Python还是Node.js，对外都只暴露80/443端口。
动静分离： 将静态资源请求和动态请求分开处理，提升响应速度。

二、核心配置指令拆解

💡 延伸阅读：别被“免费”忽悠了！一文看懂 Docker 开源生态，从零部署你的第一个容器

Nginx的配置语法并不复杂，核心就是proxy_pass这个指令。但往往越简单的东西，细节越致命。

1. 基础反向代理配置

假设我们有一个运行在8080端口的Tomcat应用，需要通过80端口对外提供服务。配置如下：


server {
    listen       80;
    server_name  www.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

注意看那四个proxy_set_header，这是最容易被忽略的。如果不把真实的Host和客户端IP传过去，后端应用拿到的全是Nginx的IP，这会导致应用里的日志分析、用户定位功能全部失效。

2. 负载均衡配置（Upstream）

当单台服务器扛不住压力时，我们就需要引入upstream模块了。这是Nginx反向代理的精髓所在。


upstream backend_servers {
    server 192.168.1.10:8080 weight=5;
    server 192.168.1.11:8080 weight=3;
    server 192.168.1.12:8080 backup;
}

server {
    listen 80;
    server_name www.example.com;

    location / {
        proxy_pass http://backend_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

这里的weight代表权重，数字越大分配到的请求越多。backup表示备用机，只有当其他服务器都宕机时才会启用。这是构建高可用架构的基础。

3. 路径重写与代理

很多时候，前端和后端的路径是不一致的。比如前端访问/api/，但后端接口实际在/v1/下。这时候就需要用到rewrite或直接在proxy_pass后加URI。


location /api/ {
    # 将 /api/xxx 代理到 http://backend/v1/xxx
    rewrite ^/api/(.*)$ /v1/$1 break;
    proxy_pass http://backend_servers;
}

这里要特别提醒一点：如果proxy_pass后面没有URI（即没有路径），它会把原始的URI原封不动地传给后端；如果带了URI（比如http://backend/），则会用新的URI替换掉location匹配的部分。这是最容易搞混的逻辑，建议大家亲手实验一遍。

三、高频疑难杂症排查手册

💡 深度技术指南：服务器被黑才知道的痛：Linux安全攻防实战笔记，从入侵检测到应急响应全记录

配置写好了，但运行起来总出问题怎么办？下面这几个场景，是笔者在维护服务器时最常遇到的。

场景一：频繁出现502 Bad Gateway

这通常意味着Nginx无法连接到后端的服务。检查步骤按顺序来：

后端服务是否存活？ 在服务器上执行 curl -I 127.0.0.1:8080 看是否有响应。
防火墙/安全组策略： 云服务器厂商的安全组规则是否放行了Nginx到后端端口的数据包。
后端连接数耗尽： 如果后端是Tomcat或PHP-FPM，检查其最大连接数配置，有可能线程池已满，拒绝了新连接。

对于PHP-FPM导致的502，通常还需要调整fastcgi_connect_timeout等参数，但那是另一个话题了。

场景二：WebSocket代理失败

现在很多应用都用到WebSocket，但Nginx默认对长连接支持不友好。如果代理后WebSocket握手失败，记得加上这两个头：


location /ws/ {
    proxy_pass http://backend_servers;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

必须要显式声明HTTP/1.1和Upgrade头，否则浏览器会一直报WebSocket connection failed。

场景三：上传大文件超时

默认Nginx的client_max_body_size只有1MB，上传个安装包直接报413错误。如果做文件分享服务，必须修改：


location /upload {
    client_max_body_size 100m;
    proxy_read_timeout 300s;
    proxy_send_timeout 300s;
    proxy_pass http://backend_servers;
}

这里的proxy_read_timeout也要相应调大，否则后端处理时间稍长，Nginx就会提前掐断连接。

四、性能调优的进阶技巧

如果你的业务量不小，仅仅能跑通是不够的，还需要考虑性能。以下几个参数建议根据服务器实际内存情况调整。


# 开启gzip压缩，减少传输体积
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

# 开启缓存，减少后端压力
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;

location / {
    proxy_cache my_cache;
    proxy_cache_valid 200 302 60m;
    proxy_cache_valid 404 1m;
    proxy_pass http://backend_servers;
}

设置缓存时要格外小心，如果是用户个性化页面，千万别缓存，否则会造成用户数据串号的事故。

五、写在最后的几点忠告

配置Nginx没有太多玄学，核心就是多测、多验、多看日志。每次修改完配置，务必执行nginx -t检查语法，再平滑重载nginx -s reload。

另外，既然聊到了服务器架构，笔者也多说一句。反向代理是架构的“门面”，它的稳定性至关重要。如果你还在为选择哪家云服务商发愁，或者被某些小厂的低价套餐坑过，不妨看看站长。我们提供高性能的云服务器和稳定的BGP网络，让你在配置Nginx时，至少不用为了底层网络抖动而背锅。毕竟，算法写得好，不如服务器跑得稳。

希望这篇详解能帮到你。如果在配置过程中遇到任何奇怪的问题，欢迎在评论区留言，我们一起探讨。