Nginx HTTP Server FAQs


Nginx HTTP Server

Nginx HTTP Server

Adopt Nginx for your web applications to make the most of your infrastructure and serve pages faster than ever

        Read more about this book      

(For more resources on this subject, see here.)

Q: What is Nginx and how is it pronounced?
A: Nginx, is a lightweight HTTP server originating from Russia— pronounced as "engine X".

Q: From where can one download and find resources related to Nginx?
A: Although Nginx is a relatively new and growing project, there are already a good number of resources available on the World Wide Web (WWW) and an active community of administrators and developers. The official website, which is at, is rather simple and does not provide much information or documentation, other than links for downloading the latest versions. On the contrary, you will find a lot of interesting documentation and examples on the official wiki—

(Move the mouse over the image to enlarge it.)

Q: Which different versions are currently available?
A: There are currently three version branches on the project:

  • Stable version: This version is usually recommended, as it is approved by both developers and users, but is usually a little behind the development version above. The current latest stable version is 0.7.66, released on June 07, 2010.
  • Development version: This is the the latest version available for download. Although it is generally solid enough to be installed on production servers, you may run into the occasional bug. As such, the stable version is recommended, even though you do not get to use the latest features. The current latest development version is 0.8.40, released on June 07, 2010.
  • Legacy version: If for some reason you are interested in looking at the older versions, you will find two of them. There's a legacy version and a legacy stable version, respectively coming as 0.5.38 and 0.6.39 releases.

Q: Are the development versions stable enough to be used on production servers?
A: Cliff Wells, founder and maintainer of the wiki website and community, believes so—"I generally use and recommend the latest development version. It's only bit me once!". Early adopters rarely report critical problems. It is up to you to select the version you will be using on your server. The Nginx developers have decided to maintain backwards compatibility in new versions. You can find more information on version changes, new additions, and bug fixes in the dedicated change log page on the official website.

Q: How can one Upgrade Nginx without loosing a single connection?
A: There are many situations where you need to replace the Nginx binary, for example, when you compile a new version and wish to put it in production or simply after having enabled new modules and rebuilt the application. What most administrators would do in this situation is stop the server, copy the new binary over the old one, and start Nginx again. While this is not considered to be a problem for most websites, there may be some cases where uptime is critical and connection losses should be avoided at all costs. Fortunately, Nginx embeds a mechanism allowing you to switch binaries with uninterrupted uptime—zero percent request loss is guaranteed if you follow these steps carefully:

  1. Replace the old Nginx binary (by default, /usr/local/nginx/sbin/nginx) with the new one.
  2. Find the pid of the Nginx master process, for example, with ps x grep nginx | grep master| or by looking at the value found in the pid file.
  3. Send a USR2 (12) signal to the master process—kill –USR2 ***, replacing *** with the pid found in step 2. This will initiate the upgrade by renaming the old .pid file and running the new binary.
  4. Send a WINCH (28) signal to the old master process—kill –WINCH ***, replacing *** with the pid found in step 2. This will engage a graceful shutdown of the old worker processes.
  5. Make sure that all the old worker processes are terminated, and then send a QUIT signal to the old master process—kill –QUIT ***, replacing *** with the pid found in step 2.
        Read more about this book      

(For more resources on this subject, see here.)

Q: What are base modules?
A: The base modules offer directives that allow you to define parameters of the basic functionality of Nginx. They cannot be disabled at compile time; as a result, the directives and blocks they offer are always available. Three base modules are distinguished:

  1. Core module: Essential features and directives such as process management and security
  2. Events module: It lets you configure the inner mechanisms of the networking capabilities
  3. Configuration module: Enables the inclusion mechanism

Q: What is the HTTP Core module?
A: The HTTP Core module is the component that contains all the fundamental blocks, directives, and variables of the HTTP server. This module is the largest of all Nginx modules—it provides an impressive amount of directives and variables.
The HTTP module introduces three new logical blocks:

  • http: This block is inserted at the root of the configuration file. It allows you to start defining directives and blocks from all modules related to the HTTP facet of Nginx. Although there is no real purpose in doing so, the block can be inserted multiple times—in which case the directive values inserted in the last block will override the previous ones.
  • server: This block allows you to declare a website. In other words, make it so that a specific website (identified by a hostname, for example, becomes acknowledged by Nginx and let it have its own configuration. This block can only be used within the http block.
  • location: Lets you define a group of settings to be applied to a particular location on a website. The next part of this section provides more details about the location block. This block can be used within a server block or nested within another location block.

Q: How to authenticate users or restrict access to certain visitors?
A: The following modules allow you to regulate access to the documents of your websites—require users to authenticate, or simply restrict access to certain visitors.

  • Auth_basic module: The auth_basic module enables the basic authentication functionality. With the two directives that it reveals, you can make it so that a specific location of your website (or your server) is restricted to users that authenticate using a username and password.

    location /admin/ {
    auth_basic "Admin control panel";
    auth_basic_user_file access/password_file;

  • Access: Two important directives are brought up by this module: allow and deny. They let you allow or deny access to a resource for a specific IP address or IP address range.
    Both directives have the same syntax: allow IP CIDR | all|, where IP is an IP address, CIDR is an IP address range (CIDR syntax), and all specifies that the directive applies to all clients.

    location {
    allow; # allow local IP address
    deny all; # deny all other IP addresses

Q: How does one configure Nginx to use an SSL certificate for the website?
A: Although the SSL module offers a lot of possibilities, in most cases only a couple of directives are actually useful for setting up a secure website. This guide will help you configure Nginx to use an SSL certificate for your website (in the example, your website is identified by Before doing so, ensure that you already have the following elements at your disposal:

  • A .key file generated with the following command: openssl genrsa -out 1024 (other encryption levels work too)
  • A .csr file generated with the following command: openssl req -new -key -out
  • Your website certificate file, as issued by the Certificate Authority, for example, (Note: In order to obtain a certificate from the CA, you will need to provide your .csr file)
  • The CA certificate file as issued by the CA, for example, gd_bundle.crt if you purchased your certificate from

The first step is to merge your website certificate and the CA certificate together with the following command:

cat gd_bundle.crt > combined.crt

You are then ready to configure Nginx to serve secure content:

server {
listen 443;
ssl on;
ssl_certificate /path/to/combined.crt;
ssl_certificate_key /path/to/;

Q: Where can one find help in writing Nginx modules?
A: If you are interested in writing Nginx modules yourself, Evan Miller published an excellent walkthrough: Emiller's Guide to Nginx Module Development. The complete guide may be consulted from his personal website at


This article answered some frequently asked questions on Nginx.

Further resources on this subject:

You've been reading an excerpt of:

Nginx HTTP Server

Explore Title