Hosting Multiple Websites with Nginx Server Blocks (Virtual Hosts)

Nginx server blocks are a virtual host structure that allows you to host multiple domain names or websites under a single Nginx installation with separate configurations. For instance, you can define different root directories, log files, SSL certificates, and PHP settings for example.com, blog.example.com, and second-site.com on the same VPS. In short, the solution involves creating separate directories for each site, pointing the domain's DNS records to the server's IP address, writing a distinct server block under /etc/nginx/sites-available, linking it to the sites-enabled directory, testing the configuration, and reloading the Nginx service.

In this guide, we will address the process of hosting multiple sites with Nginx server blocks in a manner suitable for a production environment. The goal is not just to set up a working structure, but to create a manageable, secure, fast, backup-ready, and scalable system. We will share practical steps particularly useful for agencies, developers, e-commerce owners, businesses managing multiple brands, and system administrators running multiple projects on a single server. If you don't have a server yet, you can check our pages on VPS Server for resource selection and Domain Registration for domain management.

What Are Nginx Server Blocks?

Nginx server blocks are configuration segments defined as server blocks within the Nginx configuration that determine which site an incoming HTTP or HTTPS request will be routed to. This is similar to the VirtualHost concept on the Apache side. When a visitor types a domain name into their browser, DNS resolves this domain name to the server's IP address. Nginx then looks at the Host header in the request and runs the server block that matches the server_name value.

This allows dozens of different websites to be hosted on the same IP address and the same physical or virtual server. It is possible to define separate root directories, access logs, error logs, redirect rules, SSL certificates, caching policies, and security rules for each site. For example, you can keep your corporate site in /var/www/corporate/public, your blog in /var/www/blog/public, and your testing environment in /var/www/staging/public.

Nginx is highly efficient in this structure because its event-driven architecture can manage high concurrent connections with low resource consumption. Therefore, it is frequently preferred in shared hosting, VPS, cloud server, and high-traffic application infrastructures. For the smooth operation of multi-site hosting, every detail from file permissions to DNS redirects, SSL installation to log separation must be correctly planned.

When to Use Nginx Server Blocks?

Nginx server blocks are particularly useful when you need to manage multiple web entities on a single server. This could range from two small corporate sites to dozens of client projects, subdomains, or microservices. The critical point here is the logical separation of each project.

• If you want to host multiple domain names on the same VPS.
• If you want to redirect www and non-www domain names to a single canonical address.
• If you want to link subdomains to different folders or applications.
• If you want to define separate SSL certificates and security policies for each site.
• If you want to track client projects with separate log files.
• If you want to run different applications like Laravel, WordPress, static HTML, and Node.js on the same server.

For instance, it is technically possible for a digital agency to host 8 low-traffic corporate sites on a single 4 GB RAM VPS. However, traffic, disk usage, PHP process count, database load, and backup frequency must be calculated for each site. If projects receive high traffic or if resource isolation is critical, stronger VPS, cloud server, or managed hosting solutions should be preferred. At this point, Web Hosting and Corporate Hosting options can be compared.

Requirements Before Getting Started

This guide assumes an Ubuntu or Debian-based Linux server. Commands may vary slightly depending on the distribution, but the logic remains the same. Always take a backup before making changes in a production environment. A misconfigured Nginx can render all sites temporarily inaccessible.

Necessary Technical Preparations

• A Linux user account with root or sudo privileges.
• An installed and running Nginx service.
• At least one domain name pointed to the server's IP address.
• Ports 80 and 443 must be open in the firewall.
• A regular directory structure for site files.
• A valid certificate for SSL or use of the free Let’s Encrypt.
• PHP-FPM installation for PHP-based applications.

On the DNS side, the A record points the main domain to the IPv4 address, and the AAAA record (if applicable) points to the IPv6 address. CNAME or A records can be used for subdomains like www. DNS propagation typically completes within a few minutes to 24 hours. To speed up the process when setting up a new installation, prepare the DNS records first, and then move on to the Nginx server block configuration.

Recommended Directory Structure

One of the most common mistakes in multi-site hosting is keeping all files in a cluttered single directory. While this approach may seem easy in the short term, it can lead to significant time loss during maintenance, backup, and debugging processes. A better method is to use a separate top-level directory for each domain and subdirectories like public, logs, backups within it.

An example structure could be planned as follows: /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public, and /var/www/site2.com/logs. The Nginx root value should directly point to the public directory. This way, application files, sensitive files like .env, and backups will not be directly accessible over the web.

For a simple static test page, you can place an index.html file in each site folder. By writing the site name in its content, you can quickly verify which server block is functioning. In production environments, ownership of these folders is typically managed by the www-data user or a special user performing deployments. For file permissions, 755 for folders and 644 for files are sufficient in most static scenarios. In applications like WordPress that require writing, areas such as the uploads directory should be evaluated separately.

Step-by-Step Creation of Nginx Server Block

The following steps are explained using the example domain site1.com. You can repeat the same method for a second, third, or more sites. The critical point is to use unique server_name, root, and log file for each site.

1. Create the Site Folder

The first step is to create the directory where the web files will reside. Example: sudo mkdir -p /var/www/site1.com/public. Then, for testing, create a /var/www/site1.com/public/index.html file and write distinguishable text like "This is the site1.com test page."

To correctly set the file ownership, you can use the command sudo chown -R www-data:www-data /var/www/site1.com. If you are performing deployment operations with a different user, adjust group permissions accordingly. Avoid permissions like 777 where everyone has write access in a production environment, as these can allow attackers to exploit upload directories.

2. Create the Server Block File

A common practice in Nginx is to keep inactive configurations under /etc/nginx/sites-available and link them to /etc/nginx/sites-enabled using symbolic links. Example file: /etc/nginx/sites-available/site1.com.

A simple HTTP server block is written with the following logic: 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; } }

In this configuration, listen 80 listens for HTTP traffic, server_name specifies which domain names belong to this block, root points to the directory where web files are located, and index defines the default file. try_files returns a 404 error if it cannot find the requested file or folder. This structure is quite sufficient for static sites.

3. Activate the Site

To activate the configuration, create a symbolic link: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. This method is healthier than copying files because you work on a single main configuration file. When you make changes, the linked file remains up to date.

If you do not want the default Nginx page to take precedence over your site, you can disable the default configuration. This can be done by removing the /etc/nginx/sites-enabled/default link. However, ensure that your own server block is functioning correctly before doing this.

4. Test the Configuration and Reload Nginx

After every change, you should perform a syntax test with the command sudo nginx -t. If the test is successful, reload the service seamlessly with the command sudo systemctl reload nginx. The reload command is generally safer than the restart command because it manages existing connections more gently.

If the test fails, the error message usually indicates the file name and line number. Missing semicolons, incorrect curly braces, wrong directory paths, or conflicting server_name values are the most common issues. Nginx should not be reloaded until the error is resolved.

Adding a Second and Third Site

The beauty of hosting multiple sites is that the process becomes repeatable after the first correct setup. You create the /var/www/site2.com/public directory for site2.com, write the /etc/nginx/sites-available/site2.com file, change the root and log values to site2.com, create a symbolic link, and run the Nginx test.

The simple structure for the second site is separated as follows: 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; } }

Using separate logs for each site is invaluable in real life. For example, while one site may see an increase in 404 errors, the other site may not have any issues. With a separate log structure, you can pinpoint the source of errors within seconds. Similarly, traffic analysis, bot attacks, broken links, and performance issues can be monitored on a site-by-site basis.

SSL and HTTPS Configuration

As of 2026, HTTPS is no longer just a security feature; it is also an indicator of user trust and technical quality. Browsers mark HTTP sites as insecure; SSL is mandatory for projects involving payments, memberships, forms, or admin panels. When hosting multiple sites, the correct certificate must be defined for each domain name. For your SSL needs, you can check the SSL Certificates page on Hostragons.

If you are using Let’s Encrypt, you can obtain a certificate for each domain name with Certbot. In the example process, the command certbot --nginx -d site1.com -d www.site1.com can detect the Nginx configuration and automatically add the HTTPS block. However, it is a good practice to check the file after automatic editing. Issues like incorrect redirects or duplicate server block problems may arise.

In HTTPS configuration, traffic on port 80 is usually permanently redirected to port 443. A 301 redirect signals a permanent preference from an SEO standpoint. Decide whether or not to use www and consolidate all variations to a single canonical address. For example, if you prefer https://site1.com instead of https://www.site1.com, redirect both HTTP and HTTPS www traffic to the non-www address. This reduces the risk of duplicate content.

Nginx Server Blocks for PHP and WordPress Sites

Configuration is straightforward for static HTML sites; however, for WordPress, Laravel, or custom PHP applications, integration with PHP-FPM is required. In this case, the index.php file is defined, and PHP requests are routed to the corresponding socket. For example, on Ubuntu, the socket path for PHP 8.3 might be /run/php/php8.3-fpm.sock. The version may vary depending on the server.

Example logic for 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; } }

For permalinks to work in WordPress, the structure try_files $uri $uri/ /index.php?$args is vital. Additionally, security measures should include restricting access to xmlrpc.php, rate limiting wp-login.php, and preventing PHP execution in the uploads directory. If you are hosting multiple WordPress sites on the same VPS, use a separate database, separate user, and a regular update policy for each site. For those looking for WordPress hosting alternatives, WordPress Hosting may be a more manageable option.

Comparison of Nginx Server Blocks and Apache VirtualHost

Nginx and Apache reach the same goal through different architectures. Both can host multiple sites on a single server. The choice depends on application needs, management habits, and performance expectations.

If your application heavily relies on .htaccess rules, Apache may seem easier. However, for high traffic, reverse proxy, cache, and modern deployment flows, Nginx is a strong choice for most projects. In some infrastructures, Nginx can be used as a reverse proxy while Apache serves as the backend application server.

Best Practices for Security

Hosting multiple sites on the same server provides cost advantages but increases security responsibilities. The principle of isolation and least privilege must be applied to ensure that a vulnerability in one site does not affect the others.

• Create separate databases and separate database users for each site.
• Limit the web root directory to only the public folder.
• Keep backups, .env, .git, config, and SQL files out of web access.
• Regularly renew SSL certificates and enforce HTTPS redirection.
• Use UFW or a similar firewall on the server; only open necessary ports.
• Regularly apply Nginx and operating system updates.
• Maintain separate access_log and error_log for each site.
• Add IP restrictions or additional authentication for admin panels.
• Avoid broad permissions like 777 in file permissions.

It is also beneficial to add basic security headers. Headers like X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Content-Security-Policy can be evaluated in suitable projects. However, particularly Content-Security-Policy can block script and style files if misapplied; hence it should be tested in a staging environment first. For more content on security, links can be provided to Website Security articles.

Performance and SEO Considerations

Nginx server blocks not only affect publishing but also the performance and SEO quality. Incorrect redirect chains, faulty canonical preferences, missing gzip or brotli compression, large log files, and insufficient cache settings can slow down the site. Google's page experience signals are user-centric; fast-responding, secure, and stable sites tend to perform better.

First, determine a single canonical version for each domain name. Redirect from HTTP to HTTPS, from www to non-www, or vice versa in a single step. The chain should not look like this: http://site.com first to http://www.site.com, then to https://www.site.com, then to https://site.com. Instead, it is more correct to reach the target with a single 301.

Cache-control headers can be used for static files. Images, CSS, and JS files can be cached in the browser for a specified duration. However, for frequently changing files, file name versioning or query string strategies should be employed. Gzip compression reduces bandwidth on text-based files such as HTML, CSS, JS, and JSON. For sites with high traffic, Nginx microcache, FastCGI cache, or CDN usage can be considered. Links to content like What is CDN can be provided for CDN and global access needs.

Log Management and Monitoring

Log management is key to troubleshooting in multi-site hosting. Separate log files clearly show which site is experiencing which error. The access_log records visitor requests, while the error_log captures configuration, permission, file not found, and upstream errors. A 502 Bad Gateway error is often related to PHP-FPM or backend service connections. A 403 Forbidden error may indicate permission or index file issues. A 404 Not Found error can signal a wrong file path, rewrite issue, or incorrect root problem post-DNS.

To prevent log files from growing indefinitely, the logrotate configuration should be checked. In small projects, daily or weekly rotation may suffice. For high-traffic sites, centralized log collection, metric monitoring, and alert systems should be used. Disk space exhaustion can lead to Nginx being unable to write logs, the database pausing, and sites becoming inaccessible. Thus, establishing threshold values for disk usage is a practical precaution.

Common Errors and Quick Fixes

While working with Nginx server blocks, some errors can arise in nearly every project. Knowing these can significantly shorten the setup time.

• The domain opens the wrong site: Check for server_name conflicts and the default server block.
• 403 Forbidden error: Check the root directory, file permissions, and the existence of the index file.
• 404 Not Found error: Review the root path and try_files rule.
• 502 Bad Gateway error: Verify that the PHP-FPM service is running and that the socket path is correct.
• The SSL certificate appears to belong to the wrong site: Check the server_name and certificate files on port 443.
• A redirect loop occurs: Simplify HTTP-HTTPS and www redirect rules.
• Nginx does not reload: Fix the syntax error according to the line number in the sudo nginx -t output.

Experienced administrators often use a simple checklist: Is DNS correct? Is the Nginx configuration active? Is the root folder present? Are permissions correct? Did the service pass the test? What do the logs say? Following this order helps you quickly find a solution without panicking.

Practical Checklist for Production Environment

Before going live, validate each site with the following checklist. Documenting these items before delivery, especially for client projects, establishes a professional working standard.

• The domain's A or AAAA record points to the correct IP address.
• One of the www and non-www versions has been chosen canonically.
• HTTP traffic is redirected to HTTPS with a 301.
• The SSL certificate is valid and automatic renewal is active.
• Separate root and log files have been defined for each site.
• The Nginx configuration has been validated with sudo nginx -t.
• A backup plan has been established, and a restore test has been conducted.
• File permissions comply with the principle of least privilege.
• Only necessary ports are open in the firewall.
• Error logs have been monitored for at least 15 minutes after going live.

This list may seem small, but it greatly reduces the risk of downtime in real projects. In particular, SSL renewal, DNS checks, and log monitoring steps catch many invisible errors early on.

Conclusion

Nginx server blocks are one of the fundamental methods for hosting multiple sites on a single server in an organized, secure, and efficient manner. With the right directory structure, separate configuration files, clear redirect rules, the use of HTTPS, log separation, and regular testing processes, managing multiple sites becomes highly efficient. The same principles can be applied from a small portfolio site to multiple client projects.

If you are about to launch a new project, first clarify your domain name, server resources, and SSL needs; then step by step configure your Nginx setup with the above checklist. If you are looking for a more manageable infrastructure, you can explore Hostragons' Hosting Packages, VPS Server, and SSL Certificates solutions to select the right starting point for your project.

Frequently Asked Questions

How many sites can be hosted with Nginx server blocks?

Technically, you can host numerous sites on the same server with Nginx; the limit usually depends on CPU, RAM, disk, traffic, database load, and PHP-FPM capacity. While dozens of low-traffic static sites may be possible, it is healthier to host fewer sites for high-traffic WordPress or e-commerce projects.

Is a separate SSL certificate required for each site?

Yes, each domain or subdomain that will be published over HTTPS must be included in the certificate coverage. Individual certificates can be used, or SAN or wildcard certificates may also be preferred. The important thing is that the correct certificate files are linked to the correct domain in the Nginx 443 server block.

Can subdomains be published with an Nginx server block?

Yes. You can define separate server_name for subdomains like blog.site.com or panel.site.com and route them to different root directories or different backend applications. You will need to create an A or CNAME record for the corresponding subdomain on the DNS side.

What is the difference between sites-available and sites-enabled?

sites-available is where available configuration files are kept; sites-enabled includes active configurations. Typically, a symbolic link is created in sites-enabled pointing to the sites-available file. This method makes enabling and disabling sites more organized.

What if the wrong site opens?

The most common causes include DNS pointing to the wrong IP, an incorrect server_name value, the default Nginx block capturing the request, or a wrong SSL block running on the 443 side. First, check the DNS records, then review the nginx -t output, the active sites-enabled links, and the relevant access_log file.