一、为什么需要多站点管理
想象你有一台服务器，但需要同时运行公司官网、博客系统、客户后台三个项目。如果每个项目都单独占用一台服务器，成本会很高。这时候，Nginx的多站点管理功能就能帮上大忙了。
Nginx就像个聪明的邮递员，能根据不同的收件地址（域名），把请求准确投递到对应的项目（站点）。比如访问www.company.com就转到官网，访问blog.company.com就转到博客系统。
二、准备工作：环境与基础配置
首先确保你的服务器已经安装了Nginx。如果还没安装，在Ubuntu系统上可以这样操作：
# 技术栈：Linux + Nginx
sudo apt update
sudo apt install nginx
安装完成后，关键的目录结构是这样的：
- /etc/nginx/nginx.conf （主配置文件）
- /etc/nginx/sites-available/ （可用站点配置）
- /etc/nginx/sites-enabled/ （已启用站点）
建议的配置方式是：
- 在sites-available中创建每个站点的独立配置
- 通过软链接将需要启用的配置放到sites-enabled
- 在主配置中include sites-enabled/*
三、实战配置：三个典型场景
场景1：基于域名的基本配置
假设我们有两个域名指向同一服务器：
- example.com → 官网项目（端口3000）
- api.example.com → API服务（端口5000）
创建第一个配置文件：
# /etc/nginx/sites-available/example.com
server {
listen 80; # 监听80端口
server_name example.com www.example.com; # 响应的域名
location / {
proxy_pass http://localhost:3000; # 转发到本地3000端口
proxy_set_header Host $host; # 保留原始域名信息
}
}
第二个配置文件：
# /etc/nginx/sites-available/api.example.com
server {
listen 80;
server_name api.example.com;
location / {
proxy_pass http://localhost:5000;
# API项目通常需要特殊头部
proxy_set_header X-Real-IP $remote_addr;
}
}
启用配置：
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/api.example.com /etc/nginx/sites-enabled/
sudo nginx -t # 测试配置
sudo systemctl reload nginx # 重载配置
场景2：带SSL证书的HTTPS站点
现在给官网添加SSL证书（使用Let's Encrypt免费证书）：
server {
listen 443 ssl;
server_name example.com www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
location / {
proxy_pass http://localhost:3000;
# 重要：告诉后端这是HTTPS请求
proxy_set_header X-Forwarded-Proto $scheme;
}
}
# HTTP自动跳HTTPS
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
场景3：静态资源与动态请求分离
对于访问量大的站点，我们可以拆分静态资源：
server {
listen 80;
server_name static.example.com;
# 静态资源直接由Nginx处理
location / {
root /var/www/static;
expires 30d; # 缓存30天
}
}
server {
listen 80;
server_name app.example.com;
location / {
proxy_pass http://localhost:8000;
}
# 静态请求仍走static子域名
location /static/ {
return 301 http://static.example.com$request_uri;
}
}
四、高级技巧与性能优化
1. 负载均衡配置
当某个项目需要多实例运行时：
upstream backend {
server 127.0.0.1:8000 weight=3; # 主实例，权重3
server 127.0.0.1:8001; # 备用实例
server 127.0.0.1:8002 backup; # 仅当前面都不可用时启用
}
server {
location / {
proxy_pass http://backend;
proxy_next_upstream error timeout http_500; # 自动故障转移
}
}
2. 缓存策略优化
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m inactive=60m;
server {
location / {
proxy_cache my_cache;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
add_header X-Cache-Status $upstream_cache_status;
}
}
3. 访问限制
防止恶意请求：
location /admin/ {
# 每分钟允许10个请求
limit_req zone=req_limit burst=10 nodelay;
# 同时允许2个连接
limit_conn conn_limit 2;
auth_basic "Admin Area";
auth_basic_user_file /etc/nginx/.htpasswd;
}
五、常见问题解决方案
1. 502 Bad Gateway错误
可能原因：
- 后端服务未启动
- 防火墙阻止了端口访问
- 后端处理超时
检查步骤：
# 检查端口是否监听
netstat -tulnp | grep :3000
# 测试能否访问后端
curl -v http://localhost:3000/health
解决方案：
# 增加超时时间
proxy_connect_timeout 60s;
proxy_read_timeout 60s;
2. 静态资源404
典型配置错误：
# 错误示范：root和alias混淆
location /static/ {
root /path/to/static; # 实际会查找/path/to/static/static/
}
# 正确应该用alias
location /static/ {
alias /path/to/static/; # 注意结尾的/
}
六、最佳实践与注意事项
目录结构建议：
- /var/www/site1/
- /var/www/site2/
- 每个站点独立目录，包含logs、public等子目录
日志分割：
server {
access_log /var/log/nginx/site1.access.log main buffer=32k;
error_log /var/log/nginx/site1.error.log warn;
}
配合logrotate实现日志轮转
安全建议：
- 禁用server_tokens（不显示Nginx版本）
- 限制敏感目录访问
- 定期更新SSL证书
维护技巧：
# 快速测试配置
sudo nginx -t
# 优雅重载（不中断现有连接）
sudo nginx -s reload
# 查看运行状态
systemctl status nginx
七、总结与选择建议
适用场景：
- 中小型项目初期阶段
- 开发测试环境
- 资源有限的服务器
优势：
- 节省服务器成本
- 统一管理入口
- 灵活的流量分配
局限性：
- 单点故障风险（可通过集群解决）
- 资源竞争（CPU/内存密集型项目不适合）
- 配置复杂度随站点数量增加
对于刚开始接触Nginx多站点管理的开发者，建议从简单的基于域名的配置开始，逐步尝试更复杂的场景。记住每次修改配置后都要测试语法，并做好配置备份。
评论