{"id":506,"date":"2016-01-25T11:56:35","date_gmt":"2016-01-25T09:56:35","guid":{"rendered":"http:\/\/www.systemcodegeeks.com\/?p=506"},"modified":"2018-06-08T11:06:42","modified_gmt":"2018-06-08T08:06:42","slug":"nginx-configuration-guide","status":"publish","type":"post","link":"https:\/\/www.systemcodegeeks.com\/web-servers\/nginx\/nginx-configuration-guide\/","title":{"rendered":"Nginx Configuration Guide (Ubuntu 12.04 LTS)"},"content":{"rendered":"

In this post, we feature a comprehensive Nginx Configuration Guide. This article is part of our Academy Course titled Introduction to Nginx<\/a>.<\/em><\/p>\n

This course will introduce you to the magic of nginx. You will learn to install and configure nginx for a variety of software platforms and how to integrate it with Apache. Additionally, you will get involved with more advanced concepts like Load Balancing, SSL configuration and Websockets proxying. Check it out here<\/a>!
\n 
\n 
\n 
\n 
\n 
\n[ulp id=’O5wwlXQPIiCQp2ED’]<\/p>\n

\n

Table Of Contents<\/h4>\n
\n
1. Configuration file syntax<\/a><\/dt>\n
2. Configuration directives<\/a><\/dt>\n
3. Organization and inclusions<\/a><\/dt>\n
4. Base modules<\/a><\/dt>\n
5. The HTTP Server<\/a><\/dt>\n
6. Mail server proxy<\/a><\/dt>\n
7. Virtual hosts<\/a><\/dt>\n<\/dl>\n<\/div>\n

<\/a>1. Configuration file syntax<\/h2>\n

According to Merriam-Websters online dictionary, the word syntax represents \u201cthe way in which words are put together to form phrases, clauses, or sentences\u201d. Of course that definition, as it is taken from a dictionary, is aimed at English (or actually any other language) students. So what about IT people coming from all backgrounds, languages, and countries? The change in context does not alter the meaning of the term very significantly. In particular, the syntax of a configuration file must be correct, as seen by the program that will parse it, in order for it to work efficiently.<\/p>\n

We will learn to understand and how to write (and \/ or modify) a configuration file for Nginx under Ubuntu 12.04 LTS. That will be accomplished by specifying a set of values that will define the behavior of the web server.<\/p>\n

<\/a>2. Configuration directives<\/h2>\n

By default, the behavior of Nginx is defined by its main configuration file, which is located (as seen before and unless we have modified this setting) at \/usr\/local\/nginx\/conf\/nginx.conf<\/code>. This file is composed of a list of directives organized in a logical structure that is very easy to follow and understand (see Fig. 1).<\/p>\n

\"Nginx<\/a>
Figure 1: Nginx main configuration file (nginx.conf)<\/figcaption><\/figure>\n

The lines that begin with \u201c#\u201d are comments, or in other words, strings of text that are not interpreted by the program during execution. You can comment out entire lines or add brief comments after a line to clarify what it is supposed to do.<\/p>\n

The next line shows a directive, in this case worker_processes<\/code>, which represents a setting to which we will append one or more values, depending on its syntax. Actually, the worker_processes<\/code> directive only accepts one argument, which needs to be a numerical value. Another example of a directive is user<\/code> (which is commented out in the previous line). The user<\/code> directive lets us add up to 2 text strings \u2013 the first one is required and indicates the user account Nginx will run as, and the second one is optional (user group). We will need to remember, right from the start, that each directive has its own meaning and defines a particular feature of the application.<\/p>\n

Each module that is part of Nginx has a specific set of directives. When a new module is activated, its specific set of directives becomes available, and directive blocks may also be enabled.<\/p>\n

Directive blocks are precisely that: a block of text that lets us specify a logical construction of the configuration and allows us to use inheritance, which means that configuration found in a certain block is passed on to its children blocks as well. However, inside a children block you can still change the value of a directive that was defined in its parent block.<\/p>\n

In Fig. 2a and 2b we see that all access to the root directory of the site (\/) is saved to \/home\/gacanepa\/nginx-1.5.6\/html\/access_log<\/code> except for the access to the directory named restricted (notice the directive access_log off<\/code>) in the corresponding directive block.<\/p>\n

\"Nginx<\/a>
Figure 2a: Nested directive blocks<\/figcaption><\/figure>\n
\"Nginx<\/a>
Figure 2b: Access logs<><\/figcaption><\/figure>\n

<\/a>3. Organization and inclusions<\/h2>\n

Let\u2019s focus on line 17. There is a special directive there: include<\/code>. This directive is used to insert the contents of the specified file at this exact location. The name of the file can be specified either by an absolute path or a relative path to the current directory (as it is in this case). We can see that there\u2019s a file named mime.types<\/code> in the same directory as nginx.conf<\/code> (see Fig. 3).<\/p>\n

\"Nginx<\/a>
Figure 3<\/figcaption><\/figure>\n

The end result is the same that would be accomplished by actually inserting the contents of mime.types<\/code> into the nginx.conf<\/code> file. Of course, if we do that, the main configuration file would soon become a nightmare to read. This way the include directive helps us to ensure that the nginx.conf<\/code> file remains easy to read and understand. As a plus, it works recursively in that an included file can reference another file and so on, and it also supports filename globbing<\/code>, which means it recognizes and expands the standard wild card characters (* and ?) and character lists in square brackets, for example. This way we can add multiple configuration files such as 20131030.conf<\/code>, 20131031.conf<\/code>, and 20131101.conf<\/code>. If we only want to include the files that begin with 201310, we must add the following line to the nginx.conf<\/code> file (see Fig. 4):<\/p>\n

\"Nginx<\/a>
Figure 4: Including files using wildcards<\/figcaption><\/figure>\n

However, if we add a specific file (not by filename globbing<\/code>) that doesn\u2019t exist, Nginx will not start properly (see Fig. 5a). Otherwise, we will be presented with a \u201ctest is successful\u201d message (see Fig. 5b):<\/p>\n

\"Nginx<\/a>
Figure 5a: Nginx fails to restart due to a missing include file<\/figcaption><\/figure>\n
\"Nginx<\/a>
Figure 5b: The syntax test of the configuration file has completed successfully<\/figcaption><\/figure>\n

<\/a>4. Base modules<\/h2>\n

The base modules allow us to define the basic parameters and configuration of Nginx. They are built-in into Nginx automatically during compile time. Their directives and blocks are always available. There are three types of base modules:<\/p>\n