nginx反向代理配置详解

什么是反向代理？

反向代理（Reverse Proxy）是服务器架构中常用的一种模式。简单来说，客户端请求先到达 Nginx，由 Nginx 根据规则将请求转发给内部网络中的后端服务器（如 Tomcat、Node.js、Spring Boot 等），再把后端返回的结果回传给客户端。对客户端而言，它只与 Nginx 通信，并不知道后端服务器的真实地址。 反向代理带来的好处很直接：可以统一入口、隐藏后端结构、实现负载均衡、提供 SSL 终止、缓存静态资源，以及通过访问控制增强安全性。

环境准备

在开始配置之前，请确认您已经：

• 安装 Nginx（推荐 1.18 及以上版本，可通过 `nginx -v` 查看版本）
• 后端服务已经启动并可以正常访问（例如本机的 `127.0.0.1:8080`）
• 拥有 Nginx 配置目录的读写权限（通常为 `/etc/nginx/`）
• 若修改了防火墙规则，在执行前请再次确认，避免中断现有业务

最小反向代理配置

Nginx 的配置主体位于 `http` 块内，反向代理的核心指令是 `proxy_pass`。以下是一个最基础的代理示例，将访问 `http://your-domain.com` 的请求转发到本机 `8080` 端口的后端服务。 nginx server { listen 80; server_name your-domain.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_pass`：指定后端服务器的协议、域名或 IP、端口。注意，如果 `location` 中使用了正则表达式，则 `proxy_pass` 后不能带 URI 路径。
• `proxy_set_header`：向后端传递原始请求信息。其中 `Host` 字段保留客户端请求的域名，`X-Real-IP` 记录真实客户端 IP，`X-Forwarded-For` 用于跨越多次代理时记录完整链路，`X-Forwarded-Proto` 标记请求是 HTTP 还是 HTTPS。

常用配置项详解

#### 1. 代理超时设置 后端服务响应较慢时，Nginx 默认的 60 秒超时可能不够。您可以根据业务调整以下参数： nginx proxy_connect_timeout 5s; # 与后端建立连接的超时时间 proxy_read_timeout 30s; # 从后端读取响应的超时时间 proxy_send_timeout 30s; # 向后端发送请求的超时时间 若您的后端接口处理耗时长（如报表导出），建议适当增加 `proxy_read_timeout`，但不要盲目设置过大，以免连接被长时间占用。 #### 2. 负载均衡配置 当后端有多台服务器时，可以使用 `upstream` 定义一个服务器组，然后在 `proxy_pass` 中引用它。 nginx upstream backend_pool { server 192.168.1.10:8080 weight=3; server 192.168.1.11:8080 weight=1; keepalive 32; # 启用连接池，提高复用效率 } server { listen 80; server_name your-domain.com; location /api/ { proxy_pass http://backend_pool; proxy_http_version 1.1; proxy_set_header Connection ""; } } 以上配置表示默认按轮询策略分发，权重为 3 的服务器会承担更多请求。您也可以在 `upstream` 中指定 `least_conn`（最少连接）或 `ip_hash`（按客户端 IP 哈希）等策略。 #### 3. WebSocket 代理 如果后端提供 WebSocket 服务，则需要额外配置升级请求头： nginx location /ws/ { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 3600s; # WebSocket 长连接需要更长的超时时间 } 注意，`$http_upgrade` 变量只有在客户端发送 `Upgrade` 头时才存在。该配置常用于即时通讯、在线协作等功能。 #### 4. 静态资源与动态请求分离 为了减轻后端压力，常见做法是由 Nginx 直接处理静态文件，只将动态请求代理给后端。 nginx location /static/ { alias /var/www/static/; expires 7d; access_log off; } location / { proxy_pass http://127.0.0.1:8080;

此处省略其他 proxy_set_header

} `alias` 与 `root` 的区别需要特别注意：`alias` 将 URL 中的 `/static/` 部分映射到指定目录，不会拼接 `location` 后的路径；而 `root` 会将整个 URI 添加到根目录后。上面的示例中，访问 `/static/a.png` 对应文件 `/var/www/static/a.png`。

安全与性能加固建议

• 隐藏 Nginx 版本号，避免暴露精确版本导致漏洞被利用。在 `http` 块中添加 `server_tokens off;`。
• 若后端只接受来自 Nginx 的请求，建议在防火墙中限制后端端口仅允许 Nginx 所在服务器访问，操作前请确认规则优先级，至少保留 SSH 管理端口。
• 对于可能包含敏感信息的响应，可设置 `proxy_hide_header` 来屏蔽后端自定义的头部，比如 `proxy_hide_header X-Powered-By;`。
• 使用 Gzip 压缩文本类传输内容时，注意不要对已压缩的图片、视频再次压缩。可在 `location` 中结合 `gzip_types` 按需开启。
• 推荐为代理配置日志格式，并记录 `$upstream_addr` 与 `$upstream_response_time`，便于排查问题。

nginx log_format main '$remote_addr [$time_local] "$request" ' 'status=$status upstream_addr=$upstream_addr ' 'upstream_time=$upstream_response_time request_time=$request_time'; access_log /var/log/nginx/access.log main;

验证与重载配置

每次修改配置文件后，务必先测试语法是否正确，再平滑重载 Nginx。 bash nginx -t nginx -s reload 如果 `nginx -t` 输出 `syntax is ok` 与 `test is successful`，说明配置无误。`reload` 会让 Nginx 使用新配置，同时不会中断现有请求。

常见误区与回滚方式

• `proxy_pass` 末尾带斜杠问题：当 `location` 使用前缀匹配且 `proxy_pass` 后带 URI（例如 `proxy_pass http://127.0.0.1:8080/;`）时，会将匹配到 location 部分替换为 `/`。不带 URI 时（如 `http://127.0.0.1:8080;`），则将原始 URI 完整传给后端。理解这一点可避免 404 或路径错误。
• 忽略 `Host` 头：许多后端框架依赖 `Host` 生成绝对链接，如果不传递原始 `Host`，可能导致跳转地址错误。
• 超时时间设置过短：若后端存在长任务或数据库慢查询，Nginx 超时会造成 504 错误。此时建议先分析后端日志，而不是单纯增加超时。
• 忘记检查 SELinux 或防火墙策略：在某些 Linux 发行版中，即使 Nginx 配置正确，也可能因 SELinux 阻止 Nginx 发起对外连接，导致 502/504。可使用 `setse