若依前后端分离版部署实战：Nginx反向代理+生产环境优化配置
若依前后端分离版生产环境部署全攻略：Nginx调优与安全实践
第一次将若依框架部署到生产环境时，我遇到了前端资源加载缓慢、后端接口频繁超时的问题。经过多次实战调优，终于总结出一套兼顾性能与安全的部署方案。本文将分享从基础部署到深度优化的完整路径，特别适合已经完成本地开发但缺乏生产环境经验的团队。
1. 生产环境基础架构设计
若依前后端分离架构的核心在于解耦前端资源与后端服务。典型的生产环境部署采用三层结构：前端静态资源由Nginx直接托管，后端Java服务独立运行，Nginx同时承担反向代理和负载均衡的角色。这种架构的优势在于：
- 资源隔离：静态资源与动态API分离部署，避免相互干扰
- 弹性扩展：前后端可独立横向扩展
- 安全增强：通过Nginx实现请求过滤和流量控制
在硬件资源配置上，建议：
- 2核4G及以上配置的云服务器
- 单独的数据盘用于存放日志和备份
- 至少10Mbps的公网带宽
2. Nginx核心配置实战
2.1 反向代理基础配置
修改nginx.conf中的server块，实现基础路由分离：
server { listen 80; server_name yourdomain.com; # 前端静态资源 location / { root /opt/project/ruoyi-ui; index index.html; try_files $uri $uri/ /index.html; } # 后端API代理 location /prod-api/ { 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; } }关键参数说明：
try_files确保前端路由正常跳转proxy_set_header传递真实客户端IP- 路径中的
/prod-api/需与前端请求基地址一致
2.2 性能优化配置
在http上下文中添加以下优化参数：
http { # 文件传输优化 sendfile on; tcp_nopush on; tcp_nodelay on; # 连接超时控制 keepalive_timeout 65; client_header_timeout 15; client_body_timeout 15; send_timeout 25; # 缓冲控制 client_body_buffer_size 128k; client_max_body_size 10m; # 压缩配置 gzip on; gzip_min_length 1k; gzip_comp_level 4; gzip_types text/plain application/javascript application/x-javascript text/css; }优化效果对比：
| 配置项 | 默认值 | 优化值 | 提升效果 |
|---|---|---|---|
| keepalive_timeout | 75s | 65s | 减少连接占用时间 |
| gzip_comp_level | 1 | 4 | 压缩率提升30% |
| tcp_nodelay | off | on | 减少小包延迟 |
3. HTTPS安全部署方案
3.1 证书申请与配置
使用Let's Encrypt免费证书：
# 安装certbot sudo apt install certbot python3-certbot-nginx # 获取证书（需提前解析域名） sudo certbot --nginx -d yourdomain.com # 设置自动续期 sudo certbot renew --dry-runNginx的SSL配置示例：
server { listen 443 ssl; server_name yourdomain.com; ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem; # 安全协议配置 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384'; ssl_prefer_server_ciphers on; ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; # HSTS增强安全 add_header Strict-Transport-Security "max-age=63072000" always; }3.2 安全防护配置
在server块中添加安全头：
add_header X-Frame-Options "SAMEORIGIN"; add_header X-Content-Type-Options "nosniff"; add_header X-XSS-Protection "1; mode=block"; add_header Content-Security-Policy "default-src 'self'";常见攻击防护策略：
DDoS防护：限制单个IP的请求频率
limit_req_zone $binary_remote_addr zone=one:10m rate=30r/m;SQL注入防护：过滤特殊字符
set $block_sql_injections 0; if ($query_string ~ "union.*select.*\(") { set $block_sql_injections 1; } if ($block_sql_injections = 1) { return 403; }
4. 高级性能调优技巧
4.1 静态资源优化
配置独立的静态资源服务：
server { listen 80; server_name static.yourdomain.com; location / { root /opt/project/ruoyi-ui/static; expires 365d; access_log off; add_header Cache-Control "public"; } }前端构建优化建议：
- 配置webpack的chunk splitting
- 开启资源hash命名
- 使用CDN加速静态资源
4.2 后端服务优化
若依Java服务启动参数：
nohup java -server \ -Xms2048m -Xmx2048m \ -XX:+UseG1GC \ -XX:MaxGCPauseMillis=200 \ -XX:ParallelGCThreads=4 \ -XX:ConcGCThreads=2 \ -jar ruoyi-admin.jar >/dev/null 2>&1 &JVM参数对比测试：
| 参数组合 | 平均响应时间 | GC停顿时间 | 内存占用 |
|---|---|---|---|
| 默认参数 | 320ms | 450ms | 1.2GB |
| G1GC优化 | 280ms | 210ms | 1.5GB |
| 并行GC+堆调优 | 260ms | 180ms | 1.8GB |
4.3 监控与日志方案
Nginx日志格式化：
log_format main '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' '$request_time $upstream_response_time';日志分析工具推荐：
- GoAccess：实时流量分析
goaccess /var/log/nginx/access.log -o report.html --log-format=COMBINED - ELK Stack：分布式日志系统
- Prometheus+Grafana：性能监控看板
5. 常见问题排查指南
问题1：前端页面刷新后404
- 检查Nginx的try_files配置
- 确认Vue路由模式是否为history
- 验证静态资源路径是否正确
问题2：接口请求跨域
- 确保Nginx代理路径配置一致
- 检查后端CORS配置
- 验证HTTPS环境下协议一致性
问题3：上传文件大小限制
# Nginx配置调整 client_max_body_size 50m; # Spring Boot配置调整 spring.servlet.multipart.max-file-size=50MB spring.servlet.multipart.max-request-size=50MB问题4：Redis连接超时
- 检查requirepass配置一致性
- 验证bind地址是否为0.0.0.0
- 确认防火墙规则放行6379端口
在最近一次客户现场部署中，我们发现当并发用户超过500时，默认的Nginx worker配置会出现请求堆积。通过调整以下参数解决了问题：
worker_processes auto; worker_connections 4096; multi_accept on;