1. 项目概述单服务器多站点的现实需求在项目初期或者个人开发者、中小团队的实际运维场景里我们经常会遇到一个看似简单却至关重要的需求手头只有一台云服务器但需要承载多个独立的网站或Web应用。这些应用可能包括公司官网、后台管理系统、产品演示站甚至是几个不同客户的小型项目。如果为每个站点都单独购置一台服务器成本会急剧上升管理复杂度也会成倍增加。这时利用Nginx这款高性能的HTTP和反向代理服务器在一台物理或虚拟服务器上通过配置不同的“服务器块”server block在旧版本中常被称为虚拟主机 virtual host来区分和响应来自不同域名的请求就成了一个既经济又高效的解决方案。这个方案的核心价值在于“资源共享与隔离”。服务器资源CPU、内存、磁盘I/O、网络带宽被多个站点共享显著降低了硬件和运维成本。同时通过Nginx的精确配置每个站点在逻辑上又是完全独立的拥有自己的域名、网站根目录、日志文件、SSL证书乃至后端应用互不干扰。无论是部署个人博客矩阵还是托管多个客户的小型企业站这种模式都能游刃有余。接下来我将结合十多年的运维和开发经验为你深入拆解从环境准备、配置解析到安全加固和性能调优的完整实战流程并提供大量“踩坑”后总结的独家技巧。2. 核心原理与架构设计拆解2.1 Nginx如何处理多域名请求要理解单服务器多站点的部署首先得弄清楚Nginx的工作机制。当用户在浏览器输入一个网址例如www.site-a.com并回车时背后发生了一系列事件DNS解析用户的设备会向DNS服务器查询www.site-a.com对应的IP地址最终得到你那台服务器的公网IP。TCP连接浏览器与你的服务器IP的80HTTP或443HTTPS端口建立TCP连接。HTTP请求浏览器发送一个HTTP请求报文。这个报文头部Header里有一个至关重要的字段Host。对于刚才的例子Host字段的值就是www.site-a.com。Nginx的抉择Nginx监听80/443端口接收到这个请求后它并不会直接去文件系统里找文件而是先解析请求头中的Host字段。服务器块匹配Nginx会将自己配置文件中所有的server块拿出来逐一比对server_name指令后列出的域名。一旦发现某个server块的server_name与请求的Host值匹配比如server_name www.site-a.com;Nginx就会启用这个server块的配置来处理本次请求。请求处理根据匹配到的server块内的指令如root指定网站根目录index指定默认首页Nginx将请求映射到服务器上的具体文件或者转发给后端的应用服务器如PHP-FPM、Gunicorn、Tomcat等最后生成响应返回给用户。如果没有任何server块的server_name与请求的Host匹配Nginx会使用默认的server块通常是配置文件中第一个server块或者显式标记了default_server的块来处理。这就解释了为什么配置错误的域名可能会访问到另一个不相关的网站。2.2 关键配置指令深度解析一个典型的用于多站点的Nginxserver块配置骨架如下我们来逐一拆解其核心指令server { listen 80; server_name www.site-a.com site-a.com; root /var/www/site-a/public; index index.html index.htm; access_log /var/log/nginx/site-a.access.log; error_log /var/log/nginx/site-a.error.log; location / { try_files $uri $uri/ 404; } }listen: 定义这个server块监听哪个端口和IP。listen 80;表示监听所有IPv4地址的80端口。你也可以指定IP如listen 192.168.1.100:80;。对于HTTPS则是listen 443 ssl;。server_name:这是多站点配置的灵魂。它定义了哪些域名请求应由这个server块处理。你可以列出一个主域名和多个别名用空格分隔。支持通配符如*.example.com和正则表达式以~开头但需谨慎使用优先级有特定规则。root: 指定该站点文件的根目录。Nginx会将请求的URI附加到这个路径后面来寻找文件。例如请求/css/style.css且root为/var/www/site-a/publicNginx就会尝试访问/var/www/site-a/public/css/style.css。index: 当请求以目录/结尾时Nginx会按顺序尝试寻找该指令列出的文件作为默认首页。access_log/error_log:强烈建议为每个站点配置独立的日志文件。这不仅是良好的运维习惯便于排查问题更是安全审计和流量分析的基础。混在一起日志会让你在排查某个站点的问题时痛苦不堪。location: 用于根据请求的URI进行更精细化的配置。上面的location /匹配所有请求try_files指令会按顺序检查请求的文件$uri、目录$uri/是否存在如果都不存在则返回404错误。这是处理静态文件的经典模式。实操心得server_name的匹配优先级Nginx对server_name的匹配有明确的优先级从高到低依次是完全匹配的名称如www.site-a.com。以通配符*开头的最长匹配名称如*.site-a.com。以通配符*结尾的最长匹配名称如www.site-a.*不常见。第一个匹配的正则表达式按配置文件中的出现顺序。如果以上都不匹配则使用listen指令后带有default_server参数的server块或者第一个listen端口相同的server块。 理解这个优先级可以避免因配置顺序或通配符使用不当导致的意外行为。3. 完整部署流程与实战配置3.1 环境准备与Nginx安装假设我们使用的是一台干净的CentOS 8或Ubuntu 20.04 LTS服务器。安装Nginx的步骤因系统而异。对于CentOS/RHEL系列# 添加EPEL仓库如果需要 sudo dnf install epel-release # 安装Nginx sudo dnf install nginx # 启动并设置开机自启 sudo systemctl start nginx sudo systemctl enable nginx对于Ubuntu/Debian系列# 更新软件包列表 sudo apt update # 安装Nginx sudo apt install nginx # 启动并设置开机自启 sudo systemctl start nginx sudo systemctl enable nginx安装完成后在浏览器访问服务器的公网IP你应该能看到Nginx的默认欢迎页面。这证明Nginx已成功安装并运行。注意事项防火墙配置如果无法访问很可能是防火墙阻止了80/443端口。你需要放行这些端口FirewallD (CentOS):sudo firewall-cmd --permanent --add-servicehttp sudo firewall-cmd --permanent --add-servicehttps sudo firewall-cmd --reloadUFW (Ubuntu):sudo ufw allow Nginx Full # 同时允许HTTP和HTTPS sudo ufw reload3.2 规划目录结构与文件权限清晰的目录结构是高效管理多站点的基石。我推荐采用以下结构/var/www/ # 所有网站文件的根目录 ├── site-a.com/ # 站点A的目录 │ ├── public/ # 对外公开的Web根目录Nginx root 指向这里 │ │ ├── index.html │ │ ├── css/ │ │ └── js/ │ ├── logs/ # 站点专属日志可选如果不用系统路径 │ └── .env或config/ # 应用配置文件如PHP、Python应用 ├── site-b.com/ │ └── public/ └── site-c.com/ └── public/创建目录并设置权限# 以站点 site-a.com 为例 sudo mkdir -p /var/www/site-a.com/public # 假设你当前登录用户是 youruser并且Nginx worker进程以 nginx 或 www-data 用户运行 # 将目录所有者改为你的用户方便上传文件 sudo chown -R youruser:youruser /var/www/site-a.com # 将Web根目录的组设置为Nginx运行用户组并赋予组读执行权限 sudo chmod -R 755 /var/www/site-a.com/public # 更精细的权限控制推荐设置目录为775文件为664 find /var/www/site-a.com/public -type d -exec chmod 775 {} \; find /var/www/site-a.com/public -type f -exec chmod 664 {} \; # 将目录的组所有权改为Nginx运行组根据系统查找通常是nginx或www-data sudo chgrp -R nginx /var/www/site-a.com/public权限设置是安全的关键。原则是Nginx进程只需要读取和执行文件的权限不需要写入权限上传目录等特殊情况除外。你的用户账户拥有所有权以便管理。3.3 配置域名解析DNS在服务器配置好之前你需要将你的域名指向服务器的公网IP。这需要在你的域名注册商或DNS服务商的控制台进行操作。添加一条A记录。主机记录Name/Record填写代表裸域名如site-a.com填写www代表www.site-a.com。通常两者都配置。记录值/指向Value/Points to填写你的云服务器的公网IP地址。TTL生存时间可以使用默认值。配置完成后DNS生效需要几分钟到几小时不等。你可以使用dig或nslookup命令来检查解析是否生效dig www.site-a.com short如果返回你的服务器IP说明解析成功。3.4 编写并启用站点配置文件Nginx的主配置文件通常是/etc/nginx/nginx.conf。它通常会在http块内通过include指令引入其他目录下的配置文件例如http { ... include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; }最佳实践是不要直接修改主配置而是为每个站点创建一个独立的配置文件。以Ubuntu为例使用sites-available和sites-enabled目录创建站点配置在/etc/nginx/sites-available/目录下为site-a.com创建配置文件。sudo nano /etc/nginx/sites-available/site-a.com写入配置内容server { listen 80; listen [::]:80; # 监听IPv6 server_name www.site-a.com site-a.com; root /var/www/site-a.com/public; index index.html index.htm index.php; # 如果支持PHP access_log /var/log/nginx/site-a.com.access.log; error_log /var/log/nginx/site-a.com.error.log; location / { try_files $uri $uri/ /index.php?$query_string; # 适用于Laravel等框架 # 对于纯静态站点可以用try_files $uri $uri/ 404; } # 如果使用PHP-FPM需要配置PHP处理 location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php/php8.1-fpm.sock; # 根据实际PHP版本修改 fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; include fastcgi_params; } # 禁止访问隐藏文件如 .htaccess, .git location ~ /\. { deny all; } # 静态资源缓存设置 location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { expires 30d; add_header Cache-Control public, immutable; } }启用站点创建一个符号链接到sites-enabled目录。sudo ln -s /etc/nginx/sites-available/site-a.com /etc/nginx/sites-enabled/测试配置并重载在重载Nginx前务必测试配置文件语法是否正确。sudo nginx -t如果输出syntax is ok和test is successful则可以安全重载。sudo systemctl reload nginx # 平滑重载不影响正在处理的连接 # 或 sudo systemctl restart nginx以CentOS为例常用conf.d目录过程更简单直接在/etc/nginx/conf.d/目录下创建site-a.com.conf文件写入上述配置内容然后测试并重载Nginx即可。踩坑实录配置重载失败常见原因语法错误nginx -t是救命稻草。仔细检查拼写、分号、花括号。端口冲突确保没有其他server块监听相同的IP:端口组合尤其是当你有多个配置都监听80端口但server_name不同时这本身是允许的。冲突常发生在你试图为一个IP的80端口指定多个default_server。目录或文件不存在检查root指令指向的路径是否存在权限是否正确。符号链接问题在Ubuntu风格中确保sites-enabled里的链接指向有效的文件。3.5 为第二个站点添加配置重复上述过程为site-b.com创建配置。关键在于使用不同的server_name和不同的root目录。创建文件/etc/nginx/sites-available/site-b.comserver { listen 80; listen [::]:80; server_name www.site-b.com site-b.com; # 域名不同 root /var/www/site-b.com/public; # 根目录不同 index index.html; access_log /var/log/nginx/site-b.com.access.log; error_log /var/log/nginx/site-b.com.error.log; location / { try_files $uri $uri/ 404; } # ... 其他与站点A类似的配置如PHP处理、静态缓存等 }同样创建符号链接并重载Nginx。现在访问www.site-a.com和www.site-b.comNginx会根据Host头将它们分别引导到/var/www/site-a.com/public和/var/www/site-b.com/public。4. 进阶配置与性能安全优化4.1 启用HTTPSSSL/TLS加密当今网站启用HTTPS是必须的。我们可以使用Let‘s Encrypt提供的免费证书并通过certbot工具自动化申请和续期。安装Certbot# Ubuntu sudo apt install certbot python3-certbot-nginx # CentOS (需要启用EPEL) sudo dnf install certbot python3-certbot-nginx获取并自动配置证书sudo certbot --nginx -d site-a.com -d www.site-a.com按照交互提示操作输入邮箱、同意协议等。Certbot会自动修改你的Nginx配置文件添加SSL相关指令并设置自动重定向HTTP到HTTPS。验证自动续期Let‘s Encrypt证书有效期为90天Certbot会自动设置定时任务续期。可以手动测试续期sudo certbot renew --dry-runCertbot修改后的配置片段示例server { listen 443 ssl http2; # 启用HTTP/2 listen [::]:443 ssl http2; server_name www.site-a.com site-a.com; ssl_certificate /etc/letsencrypt/live/site-a.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/site-a.com/privkey.pem; # 包含推荐的SSL安全配置 include /etc/letsencrypt/options-ssl-nginx.conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; root /var/www/site-a.com/public; # ... 其他配置 } # HTTP强制跳转HTTPS server { listen 80; listen [::]:80; server_name www.site-a.com site-a.com; return 301 https://$server_name$request_uri; }4.2 静态资源优化与缓存策略合理的缓存能极大减轻服务器压力提升用户体验。浏览器缓存如前面配置所示为图片、CSS、JS等静态资源设置长期缓存。location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff|woff2)$ { expires 1y; # 缓存一年 add_header Cache-Control public, immutable; # immutable 告诉浏览器在资源有效期内内容永不改变跳过协商缓存验证 }代理缓存如果站点有动态内容但变化不频繁可以考虑使用Nginx的proxy_cache进行反向代理缓存。http { # 定义缓存路径和参数 proxy_cache_path /var/cache/nginx levels1:2 keys_zonemy_cache:10m inactive60m use_temp_pathoff; server { location / { proxy_pass http://backend_app; # 后端应用地址 proxy_cache my_cache; proxy_cache_key $scheme$request_method$host$request_uri; proxy_cache_valid 200 302 10m; # 200和302状态码缓存10分钟 proxy_cache_valid 404 1m; add_header X-Cache-Status $upstream_cache_status; # 在响应头中显示缓存命中状态 } } }4.3 安全加固配置要点隐藏Nginx版本信息在http块或server块中添加防止信息泄露。server_tokens off;设置安全响应头add_header X-Frame-Options SAMEORIGIN always; # 防止点击劫持 add_header X-Content-Type-Options nosniff always; # 禁止MIME类型嗅探 add_header Referrer-Policy strict-origin-when-cross-origin always; # 控制Referer信息 # 内容安全策略(CSP)根据你的站点资源仔细配置 # add_header Content-Security-Policy default-src self; always;限制请求方法与大小# 在特定location中如API接口限制只允许GET和POST limit_except GET POST { deny all; } # 限制客户端请求体大小防止过大文件上传攻击 client_max_body_size 10m;基础访问控制# 禁止访问敏感目录 location ~ ^/(\.git|\.env|config|storage|logs)/ { deny all; return 404; } # 或者使用上面提到的通用隐藏文件拦截规则 location ~ /\.5. 高级场景与故障排查指南5.1 基于不同端口的部署有时你可能希望站点运行在非标准端口如8080, 9000上。配置很简单只需修改listen指令。server { listen 8080; server_name app.site-a.com; root /var/www/app-a/public; # ... 其他配置 }访问时需带上端口号http://app.site-a.com:8080。注意防火墙需要放行对应端口。5.2 代理转发到后端应用服务器现代Web应用常采用前后端分离架构。前端如Vue/React构建的静态文件由Nginx直接服务API请求则需要转发到后端服务器如Node.js, Java Spring Boot, Go等。server { listen 80; server_name api.site-a.com; location / { # 转发到本机3000端口运行的Node.js应用 proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; 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_cache_bypass $http_upgrade; # 可选设置超时 proxy_connect_timeout 60s; proxy_send_timeout 60s; proxy_read_timeout 60s; } }5.3 常见问题与排查技巧实录即使配置再小心问题也难免出现。下面是一个快速排查清单问题现象可能原因排查命令与步骤访问显示“403 Forbidden”1.root目录权限不足。2.root目录下没有index指令指定的文件。3. SELinux/AppArmor限制常见于CentOS。1.ls -la /var/www/site-a.com/public检查权限。2. 确认index.html等文件存在。3. CentOS检查SELinuxgetenforce临时禁用测试setenforce 0或修正上下文chcon -Rt httpd_sys_content_t /var/www/site-a.com/public。访问显示“404 Not Found”1.root路径配置错误。2. 请求的文件确实不存在。3.try_files指令逻辑问题。1. 检查root指令的绝对路径是否正确。2. 根据访问日志中的请求路径在服务器上确认文件是否存在。3. 检查location和try_files配置。访问站点A却显示了站点B的内容1. DNS解析未生效或本地hosts缓存。2. Nginx配置中server_name未正确设置或重复。3. 没有匹配的server块落到了默认块。1.nslookup www.site-a.com或curl -I -H Host: www.site-a.com http://服务器IP测试。2.grep -r server_name /etc/nginx/检查冲突。3. 确保每个域名都有对应的server块或设置明确的default_server。Nginx重启或重载失败配置文件语法错误。sudo nginx -t查看具体错误行。仔细检查最近修改的配置特别是分号、括号和指令拼写。SSL证书不生效或浏览器提示不安全1. 证书路径错误。2. 证书链不完整。3. 服务器防火墙443端口未开放。1. 检查ssl_certificate和ssl_certificate_key路径。2. 使用在线工具如SSL Labs检测证书链。3.sudo firewall-cmd --list-all或sudo ufw status检查端口。网站加载慢静态资源无缓存未配置或缓存头未生效。浏览器开发者工具 - Network标签查看资源响应头是否有Cache-Control和Expires。检查Nginx配置中静态资源location块的缓存指令。日志是你的最佳朋友遇到任何问题第一时间查看错误日志和访问日志。# 实时跟踪特定站点的错误日志 sudo tail -f /var/log/nginx/site-a.com.error.log # 查看最近的访问记录 sudo tail -f /var/log/nginx/site-a.com.access.log访问日志能告诉你用户实际访问的URL、IP、状态码错误日志则直接记录了Nginx处理请求时遇到的内部错误。6. 性能监控与日常维护建议部署完成并非终点持续的监控和维护才能保证服务稳定。基础监控进程状态systemctl status nginx连接数netstat -an | grep :80 | wc -l或使用ss -ant。资源占用使用top或htop查看Nginx进程的CPU和内存使用情况。日志轮转与清理Nginx默认通过logrotate管理日志但需要确保配置正确/etc/logrotate.d/nginx。定期检查日志文件大小避免磁盘被撑满。配置版本管理将/etc/nginx/目录下的配置文件纳入Git版本控制是一个极好的习惯。在做出任何修改前先提交可以轻松回滚到任何已知的正常状态。定期更新保持Nginx和系统软件包更新以获取安全补丁和性能改进。# Ubuntu sudo apt update sudo apt upgrade nginx # CentOS sudo dnf update nginx更新后务必sudo nginx -t测试配置然后sudo systemctl reload nginx。单服务器部署多个网站是每个运维和开发人员都应掌握的核心技能。它不仅仅是改改配置文件更涉及对HTTP协议、服务器资源管理、网络安全和性能优化的综合理解。从清晰的目录规划、严谨的权限设置到细致的缓存和安全头配置每一步都影响着站点的稳定性、安全性和用户体验。我个人的体会是把基础打牢把日志用好把自动化工具如Certbot用起来多站点管理并不会增加太多负担反而能让你对Web服务的运作有更深刻的掌控。如果在配置过程中遇到本文未覆盖的特定框架如Laravel, Django, Next.js的深度配置需求记住一个原则先理解该框架的官方部署文档再将其规则翻译成Nginx的location指令问题大多能迎刃而解。