Nginx Server Blocks on Debian VPS: Setup Guide

This guide walks you through setting up Nginx server blocks (also known as virtual hosts) on a Debian VPS. Server blocks let you host multiple websites on a single server, each with its own domain name, document root, and configuration. By the end, you’ll have a working multi-site setup with proper directory structure and permissions.

What You’ll Need

A Debian VPS (10, 11, or 12) with root or sudo access
A domain name pointing to your server’s public IP (for production use; you can test with a placeholder)
Nginx installed (if not, run sudo apt update && sudo apt install nginx)
Basic familiarity with the command line and text editors (nano or vim)

Step-by-Step

Create the directory structure for your site. Use a naming convention like /var/www/example.com/html. For example: sudo mkdir -p /var/www/example.com/html. Repeat for each site you plan to host.
Set ownership and permissions. Assign the directory to your user (or www-data if you prefer) so you can manage files without sudo. For a typical setup: sudo chown -R $USER:$USER /var/www/example.com/html and sudo chmod -R 755 /var/www/example.com. This gives you write access while keeping the directory readable by Nginx.
Create a test HTML file. Add a simple page to verify the server block works: echo 'Hello from example.com!' | sudo tee /var/www/example.com/html/index.html. You can replace this with your actual site files later.
Copy the default server block file. Nginx ships with a default configuration at /etc/nginx/sites-available/default. Copy it to create a new one: sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/example.com. This preserves the default file for reference.
Edit the new server block file. Open it with sudo nano /etc/nginx/sites-available/example.com. Replace the contents with a minimal configuration:
```
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/example.com/html;
    index index.html index.htm index.nginx-debian.html;
}
```
Adjust server_name and root to match your domain and directory.
Enable the server block. Create a symbolic link from sites-available to sites-enabled (which Nginx reads on startup): sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/. If you’re using the default site as a placeholder, you may want to disable it by removing its symlink: sudo rm /etc/nginx/sites-enabled/default.
Test the Nginx configuration. Run sudo nginx -t to check for syntax errors. You should see output like syntax is ok and test is successful. If there are errors, fix them before proceeding.
Reload Nginx. Apply the changes without dropping connections: sudo systemctl reload nginx. This is safer than restarting, which would briefly interrupt service.
Verify the site is live. Visit http://example.com in a browser, or use curl http://example.com from your local machine. You should see the test page. If you’re testing without a domain, you can add an entry to your local /etc/hosts file pointing the domain to your server’s IP.
Repeat for additional sites. For each new site, repeat steps 1-9 with a different domain and directory. Each site needs its own server block file.

Common Mistakes

Forgetting to enable the site: Creating a file in sites-available does nothing until you symlink it into sites-enabled. Missing this step is the most frequent cause of “site not found” errors.
Wrong directory permissions: If Nginx can’t read your files, you’ll get a 403 Forbidden error. Ensure the directory and files are readable by the www-data user (or the user Nginx runs as). The 755 permission on directories and 644 on files is a safe baseline.
Typo in server_name: A misspelled domain means Nginx won’t match the request to your block, and you’ll see the default site instead. Double-check the spelling and include both the bare domain and www subdomain if needed.
Not testing before reload: Skipping nginx -t can lead to a broken configuration that prevents Nginx from starting at all. Always test first.
Leaving the default site enabled: If you keep the default server block active and it has a catch-all server_name _, it may intercept requests meant for your new site. Disable it when it’s not needed.

Tips

Use a consistent naming convention: Name server block files after the domain (e.g., example.com) to make it obvious which site each file belongs to.
Keep logs separate: Add access_log /var/log/nginx/example.com.access.log; and error_log /var/log/nginx/example.com.error.log; inside the server block. This makes debugging easier when you have multiple sites.
Use HTTPS early: Once the HTTP version works, consider setting up a free SSL certificate with Certbot. It’s a small addition that greatly improves security and trust.
Make a backup of the default config: The default file is a good template. Keep a copy at /etc/nginx/sites-available/default.bak for reference.
Test with curl: Use curl -H "Host: example.com" http://server_ip to test the server block without changing your local DNS or hosts file.

Troubleshooting

Site shows the default Nginx page: This usually means your server block isn’t being used. Check that the symlink exists in sites-enabled, that server_name matches the domain you’re visiting, and that the default site is disabled if it has a catch-all.
403 Forbidden: Nginx can’t access the files. Verify that the directory exists and has execute permissions (755), and that the index file exists and is readable (644). Also check that the root directive points to the correct path.
404 Not Found: The server block is active, but the requested file isn’t in the document root. Confirm the file exists and that the root path is correct. Also check for typos in the URL.
500 Internal Server Error: This often points to a misconfiguration in the server block, such as a missing closing brace or an invalid directive. Run sudo nginx -t to see the exact error.
Nginx won’t start after reload: If nginx -t fails, fix the reported syntax errors. If it passes but the service still fails, check the error log at /var/log/nginx/error.log for clues.
Domain resolves to the wrong site: If you have multiple server blocks, make sure each has a unique server_name. Nginx picks the first matching block; if two have the same name, the first one wins.

Frequently Asked Questions

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

sites-available holds all your server block configuration files, while sites-enabled contains symlinks to the ones you want active. This lets you keep disabled configs for later without deleting them.

Can I host multiple sites on one IP address?

Yes, that’s the main purpose of server blocks. Nginx uses the Host header in the HTTP request to route traffic to the correct site, so you can host many domains on a single IP.

Do I need to restart or reload Nginx after changes?

You need to reload Nginx (sudo systemctl reload nginx) to apply changes to server block files. A full restart is only necessary if you change the main configuration or add new modules.

How do I set up a server block for a subdomain like blog.example.com?

Create a new server block with server_name blog.example.com; and point its root to a separate directory. You’ll also need a DNS A record for the subdomain pointing to your server IP.

What should I do if I don’t have a domain name yet?

You can test server blocks by using the server’s IP address as the server_name, but this only works for one site. For multiple sites, edit your local /etc/hosts file to map fake domains (like test1.local) to your server IP.

Is it safe to delete the default server block?

It’s safe to disable it by removing the symlink from sites-enabled, but keep the file in sites-available as a template. Deleting it entirely is fine if you have other blocks, but you’ll lose a useful reference.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →