How to Configure a Website on Nginx and Linux - Tutorial

Nginx is becoming the new standard HTTP server for new websites and webapps, specially high traffic ones. It’s blazing fast, powerful, simple, and hopefully, secure. The more we use it, more secure it will be, as always (or almost always!). It can handle thousand of requests per second using only 512MB RAM.

If you want to know how to install Nginx on Linux please read How to Install Nginx – Tutorial.

Step 1. Creating Directories for Your Websites’ Configuration Files

Do not type the “$” character you see in the commands. It’s just an indicator that you should run the commands in your command line tool.

First, go to your Nginx directory. For Ubuntu and Debian, that’s /etc/nginx:

$ cd /etc/nginx

Now, check if the directories for the configuration files already exist by running:

$ ls -la

If you can see two directories named sites-available and sites-enabled you’re ok. Otherwise create them by running:

$ sudo mkdir sites-available && sudo mkdir sites-enabled

sites-available will contain configuration files for all websites you want to try at any time, preferably one file for each website / webapp. But files on this folder will not be enabled, i.e. it’ll not be loaded into Nginx, so you can safely create new files here. Then we’ll create a symbolic link into sites-enabled directory. That way, it’s very easy for you, as a sysadmin, to enable and disable websites without having to duplicate files for backup purposes when disabling websites. Don’t worry, that’s pretty easy to manage, as we’ll see next.

If those directories were already there, you should see a file named default into sites-available, and a symlink (symbolic link) to it into sites-enabled. You can take a look at that file if you want, it’s a template configuration file, anyway I’m going to provide you with a fully functional one.

Step 2. Creating your Website’s Configuration File

Now let’s create your website’s configuration file:
(Replace by your domain name. Make sure your file ends with “.conf”)

$ sudo nano sites-available/

Copy and paste the following content to your file:

server {
  listen       80;
  rewrite ^/(.*)$1 permanent;

server {
  listen       80;

  root   /var/www/;

  error_log  /var/log/nginx/;
  access_log  /var/log/nginx/;

  location / {
      index  index.html index.htm;

  error_page  404              /404.html;

  # redirect server error pages to the static page /50x.html
  error_page   500 502 503 504  /50x.html;
  location = /50x.html {
      root   /var/www/;


Do not forget to replace all occurences of “” by your domain.

Save the changes by hitting Control-X, then Y, and then Enter.

Next you’ll understand a little bit about this configuration file.

Canonical URL

The first server block is there for SEO purposes. It’s a technique called canonical URL. Here we’re redirecting all requests coming to “” to just “”. If we don’t take care of that, SEO ranking factors get split between more than one URL showing the same content. Doing that (using the permanent keyword, which translates to HTTP 301 status code – “Moved Permanently”) we’re essentially communicating to search engines that they should always consider our canonical “” URL, and that’s great for SEO.

Note that you need to configure “www” in your DNS service (“www” is really a subdomain, like any other). You probably want to do that because you don’t want your users to see an error page if they type “”, right?

But if you’re creating a subdomain, you should remove this first server block entirely, as your users shouldn’t be typing, but just

Standard Port 80

This is the first line of the server block:

listen 80;

It defines that you’re exposing your website through port 80. Port 80 is the default HTTP port. When you use your browser to navigate the web, it’ll communicate to webservers through port 80. If you defined a different port, than you and your users would have to type the port ot access your website, like “”. That’s commonly used for applications to communicate with each other, but not for your end users.

Your Domain Name

The second line defines what’s the URL that it handles:


Root Directory

The next line defines the path for the root directory of your website:

root /var/www/;

Your’re going to create that directory in the next step.

Log Files

The next two lines defines where Nginx will create access and error log files. On Ubuntu and Debian, that directory is automatically created. So Nginx will be able to create log files there. You can take a look at those files to see how things are going on your website.

Default Index File

Next are the lines that define the index file (index.html and index.html). You can change that if you want to use a different one.

404 Error Page

Next is defined a custom 404 error page (404.html), located at the root of the website. You can change the path, but if you don’t have a custom error page, just comment out that line, putting the “#” character at the beginning of the line.

Internal Error Pages (50x Status Code)

The last block defines the same for 50x errors, indicating that the files will be in the root of the website.

Step 3. Creating your Website’s Root Directory

Now, let’s create your website’s root directory. But first an important detail: if you’re not logged in as root user and you plan to deploy your website / webapp using a different user, which I recommend in my How to Securely Set Up a VPS Server (Ubuntu / Debian) article, you’ll also have to run the “chown” command that you see next (so don’t forget to replace “deploy” by the username you’re going to use to deploy your website). But if you’re using your root user to login and you plan to use it to deploy, you should not run that command.

$ cd /var
$ sudo mkdir www
$ sudo chown deploy:deploy www
$ cd www
$ mkdir
$ cd
$ mkdir public

Now you just have to deploy your website to that public directory (i.e. put your index.html file in there).

You created your website’s configuration file inside sites-available directory. To make it available, we’re going to create a symlink for it. A symlink is a special type of file that contains a reference to another file. In some situations, like this one, it’s better than a simple copy / paste because you can change any file (the original one or the symlink) and both will keep in sync. But if you delete your symlink, nothing happens to the original file.

Let’s create your symlink now:

$ sudo ln -s /etc/nginx/sites-available/ /etc/nginx/sites-enabled/

Don’t forget to replace “” by your domain.

PS: In my tests, that didn’t work with relative paths, so make sure to use absolute ones.

That’s it. Now you should be able to see your symlink file into sites-enabled directory pointing to the original file, like this: -> /etc/nginx/sites-available/

If you want to disable any website configured like that, you just need to delete the symlink file and reload the Nginx’s configuration file (nginx.conf – see next steps). You don’t need to touch the files in sites-available. And if you need to get back a website, just create a new symlink again!

Step 5. Updating Nginx’s Configuration File

Now you have to make sure that Nginx will load all the configuration files in sites-enabled directory. To do that, first open your Nginx’s main configuration file:

$ sudo nano /etc/nginx/nginx.conf

Now copy and paste the following line (make it the last line of the http{} block):

include /etc/nginx/sites-enabled/*.conf;

Save the changes by hitting Control-X, then Y, and then Enter.

Step 6. Reloading Nginx’s Configuration File

After changing Nginx’s configuration file, you need to tell Nginx to reload it:

$ sudo /etc/init.d/nginx reload

You should see an output like this:

“[ ok ] Reloading nginx: nginx.”

If there’s an error in any configuration file, you’ll get an error message.

So that’s it. Now you can start serving your website using the ultra fast Nginx HTTP Server. If you have any problems or suggestions please let me know!

Following are some common configurations that you probably want to do.

Some Optimization

multi_accept is a configuration disabled by default. That means a worker process will accept only one new connection at a time. That’s a waste of power, so it’s useful to turn it on, then Nginx will accept as many connections as possible.

To do so, copy and paste the following line to your Nginx’s configuration file (/etc/nginx/nginx.conf), inside the events{} block, usually after the worker_connections 1024; line:

multi_accept on;

Allow Underscores in Client’s Request Header

Another useful configuration is to allow the use of underscores by clients on Request Headers. That’s disabled by default but is very simple to change, and will make it a little more flexible. To do that copy and paste the following line to your Nginx’s configuration file (/etc/nginx/nginx.conf), inside the http{} block, usually after the default_type application/octet-stream; line:

underscores_in_headers on;

Avoiding “increase server_names_hash_bucket_size error”

To avoid “increase server_names_hash_bucket_size error”, which occurs for long server_name values, add the following line to your Nginx’s configuration file (/etc/nginx/nginx.conf), inside the http{} block, usually after the underscores_in_headers on; line (if you added it):

server_names_hash_bucket_size 64;

Do not forget to reload Nginx’s configuration file after doing such changes.

That’s it. If you have any questions or problems please let me know.

How to Install Nginx – Tutorial (Ubuntu / Debian)
How to Password Protect a File or Directory on Nginx
How to Securely Set Up a VPS Server – Tutorial (Ubuntu / Debian)

Nginx – Wikipedia


“Virtual Private Server – Wikipedia” Wikipedia , n.d. Web. 06 May 2014 <>

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

comments powered by Disqus