1. 项目背景与需求分析
最近在部署iscweb前端项目时遇到了一个典型问题:前端静态资源需要访问后端fs-isc服务,但直接访问存在跨域问题。经过多次实践,我发现用Nginx反向代理是最优雅的解决方案。这种架构在前后端分离项目中非常常见,特别是当静态资源需要与多个后端服务交互时。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备与工具选型
2.1 Nginx版本选择
我推荐使用Nginx 1.18+版本,这个版本系列稳定性好,功能完善。在Ubuntu 20.04上安装非常简单:
bash复制sudo apt update
sudo apt install nginx
验证安装:
bash复制nginx -v
2.2 项目目录结构
合理的目录结构能避免很多配置问题。我的项目结构如下:
code复制/var/www/
├── iscweb/ # 前端静态资源
│ ├── index.html
│ ├── static/
│ └── ...
└── nginx/
├── conf.d/ # 自定义配置
└── ssl/ # SSL证书
3. 核心配置详解
3.1 基础静态资源服务
首先配置Nginx提供静态资源服务:
nginx复制server {
listen 80;
server_name localhost;
root /var/www/iscweb;
index index.html;
location / {
try_files $uri $uri/ /index.html;
}
}
这个配置实现了:
- 监听80端口
- 设置静态资源根目录
- 启用HTML5 history模式支持
3.2 后端API反向代理
关键的反向代理配置:
nginx复制location /api/ {
proxy_pass http://fs-isc-service:8080/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
# 超时设置
proxy_connect_timeout 60s;
proxy_read_timeout 600s;
# 启用gzip压缩
proxy_set_header Accept-Encoding gzip;
}
这里有几个重要细节:
/api/前缀用于区分前后端请求proxy_pass指向后端服务地址- 必要的header设置保证请求信息完整传递
4. 高级配置与优化
4.1 缓存控制策略
静态资源缓存是性能优化的关键:
nginx复制location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires 30d;
add_header Cache-Control "public, no-transform";
# 开启gzip压缩
gzip on;
gzip_types text/plain text/css application/json application/javascript;
}
4.2 负载均衡配置
当后端服务有多个实例时:
nginx复制upstream fs_isc_cluster {
server fs-isc-1:8080 weight=5;
server fs-isc-2:8080;
server fs-isc-3:8080;
keepalive 32;
}
location /api/ {
proxy_pass http://fs_isc_cluster;
# 其他proxy配置...
}
5. 安全加固措施
5.1 基础安全防护
nginx复制server {
# 禁用不必要的HTTP方法
if ($request_method !~ ^(GET|HEAD|POST)$ ) {
return 405;
}
# 防止信息泄露
server_tokens off;
# 安全header
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
}
5.2 HTTPS配置
使用Let's Encrypt证书:
nginx复制server {
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256...';
ssl_prefer_server_ciphers on;
}
6. 常见问题排查
6.1 502 Bad Gateway错误
可能原因及解决方案:
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 502错误 | 后端服务未启动 | 检查fs-isc服务状态 |
| 502错误 | 网络不通 | 测试容器/服务间连通性 |
| 502错误 | 端口错误 | 确认后端服务监听端口 |
6.2 静态资源加载失败
检查步骤:
- 确认Nginx有目录读取权限
- 检查文件路径是否正确
- 查看Nginx error日志
bash复制tail -f /var/log/nginx/error.log
7. 性能监控与调优
7.1 基础监控配置
nginx复制# 启用stub_status模块
location /nginx_status {
stub_status;
allow 127.0.0.1;
deny all;
}
7.2 关键性能参数
nginx复制events {
worker_connections 1024;
multi_accept on;
}
http {
# 文件描述符缓存
open_file_cache max=1000 inactive=20s;
open_file_cache_valid 30s;
# 缓冲区优化
client_body_buffer_size 10K;
client_header_buffer_size 1k;
}
8. 部署与维护实践
8.1 配置热重载
修改配置后不需要重启Nginx:
bash复制sudo nginx -t # 测试配置
sudo nginx -s reload # 热重载
8.2 日志轮转配置
编辑/etc/logrotate.d/nginx:
code复制/var/log/nginx/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 0640 www-data adm
sharedscripts
postrotate
[ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
endscript
}
9. 容器化部署方案
9.1 Docker Compose配置
yaml复制version: '3'
services:
nginx:
image: nginx:1.21
ports:
- "80:80"
- "443:443"
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf
- ./conf.d:/etc/nginx/conf.d
- ./ssl:/etc/nginx/ssl
- ../iscweb:/var/www/iscweb
networks:
- app-network
fs-isc:
image: fs-isc:latest
ports:
- "8080:8080"
networks:
- app-network
networks:
app-network:
driver: bridge
9.2 Kubernetes Ingress配置
yaml复制apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: iscweb-ingress
spec:
rules:
- host: iscweb.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginx
port:
number: 80
- path: /api
pathType: Prefix
backend:
service:
name: fs-isc
port:
number: 8080
10. 实际案例分享
最近为一个客户部署了类似架构,遇到了几个典型问题:
-
静态资源更新后浏览器缓存问题
- 解决方案:在文件名中添加hash值
nginx复制location /static/ { expires max; add_header Cache-Control "public"; access_log off; } -
API响应慢导致前端超时
- 调整Nginx超时设置:
nginx复制proxy_connect_timeout 300s; proxy_send_timeout 300s; proxy_read_timeout 300s; send_timeout 300s; -
上传大文件失败
- 调整client_max_body_size:
nginx复制client_max_body_size 100M;
这个配置方案已经在生产环境稳定运行了6个月,日均处理请求量超过50万。关键是要根据实际业务需求调整各种超时参数和缓冲区大小。
