使用指南

Nginx服务器块(虚拟主机)配置指南:一台服务器托管多个网站

  • 18 几分钟即可阅读
  • Hostragons 团队
Nginx服务器块(虚拟主机)配置指南:一台服务器托管多个网站

Nginx服务器块是一种虚拟主机逻辑,让你在单个Nginx实例中用独立的配置文件发布多个域名或网站。例如,你可以在同一台VPS上为 example.com、blog.example.com 和 ikinci-site.com 分别定义不同的根目录、日志文件、SSL证书和PHP设置。简单来说,解决方案就是:为每个站点创建独立目录,将域名的DNS记录指向服务器IP地址,在 /etc/nginx/sites-available 下编写单独的服务器块,将其链接到 sites-enabled 目录,测试配置并重载Nginx服务。

本指南将按照生产环境的标准,探讨如何使用Nginx服务器块托管多个网站。目标不仅是搭建一个能跑的结构,更是建立一个易于管理、安全、快速、可备份且可扩展的体系。我们将特别为代理商、开发者、电商运营者、多品牌管理企业以及在一台服务器上运行多个项目的系统管理员分享实用步骤。如果你还没有服务器,可以查看 VPS服务器 了解资源选择,以及 域名注册 了解域名管理。

什么是Nginx服务器块?

Nginx服务器块是Nginx配置中定义为 server 块的配置片段,用于决定传入的HTTP或HTTPS请求应指向哪个网站。它类似于Apache中的 VirtualHost 概念。当访问者在浏览器中输入一个域名时,DNS会将该域名解析到服务器的IP地址。随后,Nginx会查看请求中的 Host 头部,并执行 server_name 值与之匹配的服务器块。

这样一来,同一个IP地址和同一台物理或虚拟服务器上就可以发布几十个不同的网站。你可以为每个站点设置独立的 root 目录、访问日志、错误日志、重定向规则、SSL证书、缓存策略和安全规则。例如,你可以将企业站放在 /var/www/kurumsal/public 中,将博客放在 /var/www/blog/public 中,将测试环境放在 /var/www/staging/public 中。

Nginx在这方面的效率极高,因为它的事件驱动架构能够以极低的资源消耗处理高并发连接。因此,在共享主机、VPS、云服务器和高流量应用基础设施中,它常常是首选。为了让多站点托管健康运行,从文件权限到DNS指向,从SSL安装到日志分离,每一个细节都需要正确规划。

何时使用Nginx服务器块?

当你需要在单台服务器上管理多个Web资产时,Nginx服务器块就派上了用场。这有时可能是两个小型企业网站,有时也可能是几十个客户项目、子域名或微服务。其中的关键在于,每个项目在逻辑上要彼此分离。

  • 当你想在同一台VPS上发布多个域名时。
  • 当你想将带www和不带www的域名重定向到单一权威地址时。
  • 当你想将子域名指向不同的文件夹或应用程序时。
  • 当你想为每个站点定义独立的SSL证书和安全策略时。
  • 当你想通过独立的日志文件跟踪客户项目时。
  • 当你想在同一台服务器上运行Laravel、WordPress、静态HTML和Node.js等不同应用时。

例如,一家数字代理商完全可以在单台4GB内存的VPS上发布8个低流量的企业站。但必须计算每个站点的流量、磁盘使用量、PHP进程数、数据库负载和备份频率。如果项目流量很大,或者资源隔离至关重要,那么更强大的VPS、云服务器或可管理的托管方案会是更优选择。在这一点上,可以对比 网络托管企业托管 选项。

开始前的准备工作

本指南假设你使用的是基于Ubuntu或Debian的Linux服务器。命令可能因发行版不同而略有差异,但逻辑是相通的。在生产环境中操作之前,务必进行备份。错误的Nginx配置可能导致所有站点暂时无法访问。

必要的技术准备

  • 拥有root或sudo权限的Linux用户账户。
  • 已安装并正在运行的Nginx服务。
  • 至少一个已指向服务器IP地址的域名。
  • 防火墙中已开放80和443端口。
  • 存放站点文件的规整目录结构。
  • 用于SSL的有效证书,或使用免费的Let's Encrypt。
  • 针对PHP应用的PHP-FPM安装。

在DNS方面,A记录将主域名指向IPv4地址,AAAA记录(如果有的话)指向IPv6地址。对于 www 这样的子域名,可以使用CNAME或A记录。DNS传播通常在几分钟到24小时内完成。在全新安装时,先准备好DNS记录,然后再进行Nginx服务器块配置,可以加快进程。

推荐的目录结构

在多站点托管中,最常见的错误之一就是把所有文件混乱地放在同一个目录里。这种做法短期内看似简单,但在维护、备份和调试过程中会严重浪费时间。更好的方法是,为每个域名设置一个独立的顶层目录,并在其中使用 public、logs、backups 等子目录。

一个示例结构可以这样规划:/var/www/site1.com/public、/var/www/site1.com/logs、/var/www/site2.com/public 和 /var/www/site2.com/logs。Nginx的 root 值应直接指向 public 目录。这样,应用文件、.env 等敏感文件以及备份就不会通过Web直接访问到。

对于示例静态测试页面,你可以在每个站点文件夹中放置一个简单的 index.html 文件。在内容中写上站点名称,就能快速验证哪个服务器块在生效。在生产环境中,这些文件夹的所有权通常归属于 www-data 用户或用于部署的专用用户。文件权限方面,目录设为755,文件设为644,在大多数静态场景下就足够了。对于像WordPress这样需要写入权限的应用,uploads 目录等区域需要另行评估。

逐步创建Nginx服务器块

以下步骤以 site1.com 域名为例进行说明。你可以对第二个、第三个或更多站点重复使用相同的方法。关键点在于,每个站点都要使用唯一的 server_name、root 和日志文件。

1. 创建站点文件夹

第一步是创建存放Web文件的目录。示例:sudo mkdir -p /var/www/site1.com/public。然后,创建一个 /var/www/site1.com/public/index.html 文件用于测试,并写入类似“这是site1.com测试页面”这样的可区分文本。

可以使用 sudo chown -R www-data:www-data /var/www/site1.com 命令来正确设置文件所有权。如果你使用其他用户进行部署操作,请相应调整组权限。在生产环境中,要避免使用777这样所有人都有写入权限的设置。这种权限可能导致攻击者恶意利用上传目录。

2. 创建服务器块文件

在Nginx中,常见的做法是将非活跃的配置文件放在 /etc/nginx/sites-available 下,并通过符号链接将需要激活的文件链接到 /etc/nginx/sites-enabled 中。示例文件:/etc/nginx/sites-available/site1.com。

一个简单的HTTP服务器块可以这样写:server { listen 80; server_name site1.com www.site1.com; root /var/www/site1.com/public; index index.html index.htm; access_log /var/log/nginx/site1.com.access.log; error_log /var/log/nginx/site1.com.error.log; location / { try_files $uri $uri/ =404; } }

在这个配置中,listen 80 监听HTTP流量,server_name 指定哪些域名属于此块,root 指向Web文件所在目录,index 定义默认文件。try_files 则在找不到请求的文件或文件夹时返回404。对于静态站点来说,这个结构已经足够了。

3. 启用站点

要激活配置,可以创建符号链接:sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com。这种方法比复制文件更可靠,因为你只需维护一个主配置文件。当你做修改时,链接的文件也会保持更新。

如果你不希望默认的Nginx页面覆盖你的站点,可以禁用默认配置。为此,可以移除 /etc/nginx/sites-enabled/default 链接。但在这样做之前,请确保你自己的服务器块能正常工作。

4. 测试配置并重载Nginx

每次修改后,都应使用 sudo nginx -t 命令进行语法测试。如果测试成功,使用 sudo systemctl reload nginx 命令可以无中断地重载服务。reload 命令通常比 restart 命令更安全,因为它能更平滑地处理现有连接。

如果测试失败,错误信息通常会显示文件名和行号。缺少分号、大括号不匹配、目录路径错误或 server_name 值冲突是最常见的问题。在解决问题之前,切勿重载Nginx。

添加第二个和第三个站点

托管多个网站的魅力在于,在第一次正确安装之后,整个过程就变得可复制了。对于 site2.com,你只需创建 /var/www/site2.com/public 目录,编写 /etc/nginx/sites-available/site2.com 文件,将 root 和 log 值改为 site2.com,创建符号链接,然后运行Nginx测试。

第二个站点的基本结构可以这样分离:server { listen 80; server_name site2.com www.site2.com; root /var/www/site2.com/public; index index.html; access_log /var/log/nginx/site2.com.access.log; error_log /var/log/nginx/site2.com.error.log; location / { try_files $uri $uri/ =404; } }

为每个站点使用独立的日志在实际运维中非常有价值。例如,可能一个站点的404错误激增,而另一个站点却毫无问题。借助独立的日志结构,你可以在几秒钟内找到问题根源。同样,流量分析、机器人攻击、死链和性能问题都可以按站点进行监控。

SSL和HTTPS配置

在2026年的SEO标准中,HTTPS已不仅仅是安全特性,更是用户信任和技术质量的标志。浏览器会将HTTP站点标记为不安全;对于包含支付、注册、表单或管理后台的项目,SSL是强制性的。在托管多个站点时,必须为每个域名定义正确的证书。关于SSL需求,你可以浏览Hostragons的 SSL证书 页面。

如果你使用Let's Encrypt,可以通过Certbot为每个域名获取证书。在示例流程中,certbot --nginx -d site1.com -d www.site1.com 命令会检测Nginx配置并自动添加HTTPS块。但在自动修改后检查文件是一个好习惯。可能会出现重定向错误或重复的 server 块问题。

在HTTPS配置中,通常会将80端口的流量永久重定向到443端口。301重定向在SEO方面会传递永久性的首选信号。请决定是否使用 www,并将所有变体集中到一个权威地址。例如,如果你打算使用 https://site1.com 而不是 https://www.site1.com,那么请将HTTP和HTTPS下带www的流量都重定向到不带www的地址。这可以降低重复内容的风险。

针对PHP和WordPress站点的Nginx服务器块

静态HTML站点的配置很简单,但WordPress、Laravel或自定义PHP应用需要与PHP-FPM集成。这种情况下,需要定义 index.php 文件,并将PHP请求转发到相应的socket。例如,在Ubuntu上,PHP 8.3的socket路径可能是 /run/php/php8.3-fpm.sock。版本会因服务器而异。

基于PHP的示例逻辑:server { listen 80; server_name wordpress-site.com www.wordpress-site.com; root /var/www/wordpress-site.com/public; index index.php index.html; location / { try_files $uri $uri/ /index.php?$args; } location ~ php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.3-fpm.sock; } }

对于WordPress,为了让固定链接生效,try_files $uri $uri/ /index.php?$args 这个结构至关重要。此外,还应考虑一些安全措施,比如限制 xmlrpc.php 访问、对 wp-login.php 进行速率限制、禁止在 uploads 目录中执行PHP等。如果你在同一台VPS上托管大量WordPress站点,请为每个站点使用独立的数据库、独立的用户,并制定定期更新策略。对于寻找WordPress托管替代方案的用户,WordPress托管 可能是一个更易于管理的选择。

Nginx服务器块与Apache VirtualHost对比

Nginx服务器块与Apache VirtualHost对比

Nginx和Apache通过不同的架构实现同一目标。两者都能在单台服务器上托管多个网站。选择取决于应用需求、管理习惯和性能预期。

Nginx服务器块与Apache VirtualHost对比
对比项Nginx服务器块Apache VirtualHost
性能在高并发连接下,以低资源消耗见长。根据模块和进程模型,可能消耗更多资源。
配置采用集中且简洁的配置逻辑。通过.htaccess提供基于目录的灵活性。
静态文件服务非常快速且高效。性能不错,但Nginx通常更轻量。
PHP执行通过PHP-FPM运行。可以使用mod_php或PHP-FPM选项。
使用场景在反向代理、静态文件、高流量和现代应用方面表现强大。对于依赖.htaccess的旧应用和共享主机架构很实用。

如果你的应用重度依赖.htaccess规则,Apache可能更省事。但对于高流量、反向代理、缓存和现代部署流程,Nginx在大多数项目中都是一个强有力的选择。在某些基础设施中,也可以将Nginx用作反向代理,Apache用作后端应用服务器,两者协同工作。

安全最佳实践

在同一台服务器上托管多个网站在成本方面有优势,但也会增加安全责任。为了防止一个站点的漏洞影响其他站点,应遵循隔离和最小权限原则。

  • 为每个站点创建独立的数据库和数据库用户。
  • 将Web根目录限制在 public 文件夹内。
  • 将备份、.env、.git、config 和SQL文件放在Web访问范围之外。
  • 定期更新SSL证书,并强制使用HTTPS重定向。
  • 在服务器上使用UFW或类似的防火墙,只开放必要的端口。
  • 定期更新Nginx和操作系统。
  • 为每个站点保留独立的 access_log 和 error_log。
  • 为管理后台添加IP限制或额外的身份验证。
  • 在文件权限中避免使用777等过于宽松的设置。

此外,添加基本的安全头部也很有益。X-Frame-Options、X-Content-Type-Options、Referrer-Policy 和 Content-Security-Policy 等头部可以在合适的项目中评估使用。但尤其要注意,如果 Content-Security-Policy 配置不当,可能会阻止脚本和样式文件加载;因此,应先在测试环境中尝试。关于安全的更多内容,可以链接到 网站安全 文章。

性能和SEO注意事项

Nginx服务器块不仅关乎发布,也会影响性能和SEO质量。错误的重定向链、不规范的权威地址选择、缺少gzip或brotli压缩、庞大的日志文件以及不足的缓存设置,都可能降低网站速度。Google的页面体验信号是以用户为中心的;响应快速、安全且稳定的网站往往表现更好。

首先,为每个域名确定一个唯一的权威版本。将HTTP重定向到HTTPS,将带www重定向到不带www(或反之),最好一步完成。重定向链不应是这样的:http://site.com 先到 http://www.site.com,再到 https://www.site.com,最后到 https://site.com。更正确的做法是用单个301直接跳转到目标。

可以为静态文件使用 cache-control 头部。图片、CSS和JS文件可以在浏览器中缓存一定时间。但对于频繁变动的文件,应采用文件名版本化或查询字符串策略。gzip压缩可以减少HTML、CSS、JS和JSON等文本类文件的带宽消耗。对于高流量站点,可以考虑使用Nginx微缓存、FastCGI缓存或CDN。对于CDN和全球访问需求,可以链接到 什么是CDN 等内容。

日志管理和监控

在多站点托管中,日志管理是解决问题的关键。独立的日志文件能清晰地显示哪个站点发生了什么错误。access_log 记录访问者请求,error_log 记录配置、权限、文件未找到和上游错误。502 Bad Gateway错误通常与PHP-FPM或后端服务连接有关。403 Forbidden可能是权限或索引文件问题。404 Not Found则可能指向文件路径、重写规则或DNS解析后的错误 root 问题。

为防止日志文件无限增大,应检查 logrotate 配置。在小型项目中,每天或每周轮转一次可能就够了。对于高流量站点,应使用集中式日志收集、指标监控和告警系统。磁盘空间耗尽会导致Nginx无法写入日志、数据库停止运行以及站点无法访问。因此,为磁盘使用量设置阈值是一项实用的预防措施。

常见错误与快速解决方案

在使用Nginx服务器块时,几乎每个项目都可能遇到一些错误。提前了解这些可以大大缩短安装时间。

  • 域名打开了错误的站点:检查 server_name 冲突和默认的 server 块。
  • 403 Forbidden错误:检查 root 目录、文件权限以及索引文件是否存在。
  • 404 Not Found错误:检查 root 路径和 try_files 规则。
  • 502 Bad Gateway错误:确认PHP-FPM服务正在运行,且socket路径正确。
  • SSL证书显示为错误的站点:检查443端口上的 server_name 和证书文件。
  • 发生重定向循环:简化HTTP-HTTPS和www重定向规则。
  • Nginx无法重载:根据 sudo nginx -t 输出中的行号修正语法错误。

有经验的管理员会遵循一个简单的检查清单:DNS正确吗?Nginx配置激活了吗?root 文件夹存在吗?权限正确吗?服务通过测试了吗?日志显示了什么?按照这个顺序排查,可以让你不慌乱地快速找到解决方案。

生产环境实用检查清单

在上线之前,请使用以下检查清单验证每个站点。特别是在客户项目中,在交付前记录这些项目,可以建立专业的工作标准。

  • 域名A或AAAA记录指向正确的IP地址。
  • 在带www和不带www的版本中,已选定一个作为权威版本。
  • HTTP流量通过301重定向到HTTPS。
  • SSL证书有效,且自动续期功能已激活。
  • 为每个站点定义了独立的 root 和日志文件。
  • Nginx配置已通过 sudo nginx -t 验证。
  • 备份计划已确定,并已进行恢复测试。
  • 文件权限符合最小权限原则。
  • 防火墙中只开放了必要的端口。
  • 上线后至少监控错误日志15分钟。

这份清单看似简短,但在实际项目中能大幅降低服务中断的风险。特别是SSL续期、DNS检查和日志监控步骤,能及早发现大多数不可见的错误。

总结

Nginx服务器块是在单台服务器上有序、安全且高性能地托管多个网站的基本方法之一。通过正确的目录结构、独立的配置文件、清晰的重定向规则、HTTPS的使用、日志分离和定期测试流程,多站点管理可以变得相当高效。从一个小型作品集网站到多个客户项目,都可以应用相同的原则。

如果你打算发布一个新项目,请先明确域名、服务器资源和SSL需求;然后按照上述检查清单,一步步搭建你的Nginx配置。如果你正在寻找更易于管理的基础设施,可以查看Hostragons的 托管套餐VPS服务器SSL证书 解决方案,为你的项目选择合适的起点。

常见问题

使用Nginx服务器块可以托管多少个网站?

从技术上讲,你可以在同一台服务器上用Nginx托管大量网站;限制通常取决于CPU、内存、磁盘、流量、数据库负载和PHP-FPM的处理能力。对于低流量的静态站点,托管几十个是可能的,但对于高流量的WordPress或电商项目,托管较少的站点会更稳妥。

每个站点都需要单独的SSL证书吗?

是的,如果每个域名或子域名都要通过HTTPS发布,就必须包含在证书覆盖范围内。可以使用单独的证书,也可以选择SAN或多域名通配符证书。重要的是,在Nginx的443服务器块中,要将正确的证书文件与正确的域名关联起来。

可以用Nginx服务器块发布子域名吗?

可以。对于 blog.site.com 或 panel.site.com 这样的子域名,你可以定义单独的 server_name,并将其指向不同的 root 目录或不同的后端应用。你需要在DNS端为相应的子域名创建A记录或CNAME记录。

sites-available 和 sites-enabled 有什么区别?

sites-available 是存放可用配置文件的地方,而 sites-enabled 包含的是已激活的配置。通常,会在 sites-enabled 中创建一个指向 sites-available 文件的符号链接。这种方法使得启用和禁用站点更加有序。

如果打开了错误的网站,问题可能出在哪里?

最常见的原因是DNS解析到了错误的IP、server_name 值有误、默认的Nginx块捕获了请求,或者在443端口上错误的SSL块在生效。请先检查DNS记录,然后查看 nginx -t 的输出、sites-enabled 中的活动链接以及相关的 access_log 文件。

分享这篇文章:

Hostragons 团队

我们的专家团队提供关于主机、服务器和域名方面的最新指南。让我们一起找到适合您项目的解决方案。

联系我们