Ubuntu Intrepid - Nginx Virtual Hosts #1

Now we have Nginx installed (whether via the package manager or from source) we are in a position to serve multiple domains using Virtual Hosts.

Do note the layout used in this article is explained here — feel free to use the directories of your choice.


Create the layout

Let's create the basic layout for each domain. In your home directory create a 'public_html' folder:

mkdir /home/demo/public_html

Now for each domain you want to host (I use the examples of domain1.com and domain2.com) create a folder with a standard set of sub-folders:

mkdir -p /home/demo/public_html/domain1.com/{public,private,log,backup}

and

mkdir -p /home/demo/public_html/domain2.com/{public,private,log,backup}

That will create the folders public, private, log and backup for each of our domains (domain1.com and domain2.com).

index.html

The content of the public folder is, naturally, up to you but for this example I am going to use a very simple html file so we can check the virtual hosts work.

So for each domain:

nano /home/demo/public_html/domain1.com/public/index.html

Enter something like this into the file:

<html>
  <head>
    <title>domain1.com</title>
  </head>
  <body>
    <h1>domain1.com</h1>
  </body>
</html>

Repeat the process so you have a similar file for domain2.com (don't forget to change the index.html content so it shows domain2.com and not domain1.com).

Virtual Hosts Layout

If you have been following the articles for the Nginx install, you will have a 'Debian' style layout (using 'sites-available' and 'sites-enabled' folders) whether you installed via the package manager or via source.

As such, we'll use that layout from now on when creating the virtual hosts.

Virtual Host

Let's go ahead and create the vhost file for domain1:

sudo nano /etc/nginx/sites-available/domain1.com

Remember to adjust the path according to your install. So installing from source would require:

sudo nano /usr/local/nginx/sites-available/domain1.com

The contents look like this:

server {

            listen   80;
            server_name  www.domain1.com;
            rewrite ^/(.*) http://domain1.com/$1 permanent;

           }


server {

            listen   80;
            server_name domain1.com;

            access_log /home/demo/public_html/domain1.com/log/access.log;
            error_log /home/demo/public_html/domain1.com/log/error.log;

            location / {

                        root   /home/demo/public_html/domain1.com/public/;
                        index  index.html;

                        }

            }

Note: This example vhost is pretty basic. However, the next article on Nginx virtual hosts will include details of many more settings that are available.

The first server module in the file is a simple rewrite rule that redirects visitors to domain1.com from www.domain1.com.

You can, of course, have this the other way around if you prefer.

The second server module has very basic information including the 'server_name' which is the domain name you want to serve.

It then defines the log locations for easy analysis and finally sets the server root and the index file.

As said, it's a very basic config at this stage.

sites-enabled

The last configuration step is to 'enable' our site.

This is done with a symlink in the 'sites-enabled' directory as follows:

sudo ln -s /etc/nginx/sites-available/domain1.com /etc/nginx/sites-enabled/domain1.com

Again, depending on how you installed Nginx, you may need to adjust the paths:

sudo ln -s /usr/local/nginx/sites-available/domain1.com /usr/local/nginx/sites-enabled/domain1.com

Restart Nginx

Although there is a restart option for the Nginx init script, it doesn't always work as expected and may not facilitate any changes you have made.

As such, I recommend a stop-and-start approach rather than a simple restart:

sudo /etc/init.d/nginx stop
...
sudo /etc/init.d/nginx start

Navigate

To test the domain without creating a DNS zone and record(s) on some Internet namserver(s), I've modified the '/etc/hosts' file on my local computer to include some entries mapping 'domain1.com', etc. to the demo slice's public IP:

127.0.0.1    localhost
...

# entries related to the demo slice
123.45.67.890   domain1.com
123.45.67.890   www.domain1.com
123.45.67.890   domain2.com
...

You can add similar entries in your own 'hosts' file, though it's location will vary depending on what OS is loaded on your local computer (try a Google search).

NOTE: entries in the 'hosts' file will need to be removed prior to testing and using live DNS zones and records created on Internet nameservers. Failure to remove them will likely lead to confusion on your part and inaccurate tests of new or modified public DNS records.

With such changes made for testing purposes, you can navigate to your site in a web browser on your local computer:

Nginx domain1.com

Nice.

Rinse and Repeat

All you need to do for your next virtual host (domain2.com in this example) is to repeat the process.

I know I mention it a lot, but do remember to adjust any paths to match your Nginx installation.

So create a virtual host file:

sudo nano /etc/nginx/sites-available/domain2.com

Enter the details as shown above but for domain2.com and then create a symlink in the 'sites-enabled' folder like this:

sudo ln -s /etc/nginx/sites-available/domain2.com /etc/nginx/sites-enabled/domain2.com

Restart Nginx:

sudo /etc/init.d/nginx stop
...
sudo /etc/init.d/nginx start

And away you go.

Logs

Remember we defined custom locations for the domain logs?

Well, let's have a check they are there:

ls /home/demo/public_html/domain1.com/log/
...
access.log  error.log

Excellent, everything is working as we expected and we have our domain logs in a nice and convenient location.

Summary

Setting up virtual hosts with Nginx is a simple process using the 'sites-available' and 'sites-enabled' folders.

Although the example here is quite basic, I hope you can see that getting to grips with Nginx syntax and configurations is not too difficult.

The next article will concentrate on some other settings for use in the virtual hosts file, thus allowing for more control and flexibility for your hosting needs.

Mike

Article Comments:

Gabriel.ar commented Thu Jun 25 02:11:10 UTC 2009:

Mike, you ROCK!

gordon commented Wed Jul 15 11:30:56 UTC 2009:

hi there your write ups are good and i like how you have put in headers to explain things.

I'm a programmer and have no admin "mojo". I am trying to set up Nginx to work with phpPgAdmin and squirrelmail under apache.

If you could cover them, it would be good.

Also, i have no idea how do we set up a url such as "mail.myexample.com" when i have already have a domain (ie. "www.myexample.com"). Sorry for the silly questions.

daily channels commented Tue Dec 21 17:40:29 UTC 2010:

woow... thanks for sharing.. great article..

Kevin commented Sun Jan 30 07:02:45 UTC 2011:

In virtual host section, the 3rd pic shows a typical Vhost file with one root option.

It could be useful to add a notice saying that the "root" option might be there more than one time and needs to be changed everywhere for the right directory. Mine had 6.

Hoped to contribute. Great article. Greetings.

Nayan commented Sun Apr 24 10:25:52 UTC 2011:

Superbbbbbbbbbbbb. Thanks a lot

Erik commented Thu Mar 08 21:19:59 UTC 2012:

restpect!

Pitfalls commented Tue Dec 11 22:28:04 UTC 2012:

Under the title "Virtual Host", you propose the following line of code in the domain config file (sites-available/domain1.com) to achieve a redirect from www.domain.com to domain.com:

rewrite ^/(.*) http://domain1.com/$1 permanent;

This is a known security pitfall, as described here: http://wiki.nginx.org/Pitfalls#Taxing_Rewrites

Jered commented Mon Dec 31 22:56:40 UTC 2012:

It's not so much a security pitfall, as described on the wiki, as a potentially unnecessary tax on server resources. The alternatives they list use the built-in "request_uri" variable to bypass the regular expression matching, cutting down on the work needed to perform the redirect.

It's certainly a good idea for nginx servers, though, and we'll look at incorporating that into the article.

Want to comment?


(not made public)

(optional)

(use plain text or Markdown syntax)