• Nginx has 1 master process, and multiple worker processes.
    • The master's job is to read configuration files, and to manage the worker processes.
    • The worker processes handle the requests.
  • Nginx uses an event-based model to distribute requests among workers
  • The # of workers is specified in the config file, and may either be fixed, or adjustable based on how many cores the CPU has.

Config file

  • The nginx config file nginx.conf is stored either in /usr/local/nginx/conf, /etc/nginx, or /usr/local/etc/nginx.
  • nginx consists of modules which are controlled by directives specified in the configuration file
    • Directives can either be simple directives or block directives
      • simple ends with ;, block uses {}
  • If a directive can have other directives inside, it is called a Context
    • ex. events, http, server, location
  • If a directive is not placed within a Context, then it is considered to be in the Main Context.
    • The events and http directives reside in the Main Context, server in http, and location in server.


  • Nginx divides the configurations meant to serve different content into Blocks, which live in a hierarchical structure.
  • Each time a client request is made to the server, Nginx begins a process of determining which hierarchical block should be used to handle the request.

Server Block

  • Defines a virtual server used to handle requests of a defined type
    • each Server Block functions as a separate virtual web server instance
  • Based on the domain name, port and IP address requested, we can configure multiple server blocks to handle each combination.
  • The server_name and listen directives are used to determine which server block should be used to fulfill a request. They are used to bind to tcp sockets.
    • With listen, we can use a lone IP, a lone port, or a combo of the two. If we only specify one, then defaults are used
      • default port: 80
      • default IP:
    • the server_name directive is only evaluated when nginx needs to distinguish between server blocks that match to the same level of specificity in the listen directive. Put another way, it is a "specificity tie-breaker"
      • in other words, if is hosted on, a request will always be served by a server block that specifies listen, even if there is another server block that specifies server_name
    • Finally, if further specificity is needed, then the Host header from the request (which contains the URI that the client was trying to reach) is used.
      • When using wildcard matching, the longest match beginning with a wildcard is used
        • ex. if the request has a Host header of, and we have 3 server blocks with server_name of *, www.example.* and *.com, * would win out.
  • With server blocks, we can run more than one website on a single host
  • in Apache, called VirtualHost

Location Block

  • Lives within a Server Block (or nested in other location blocks).
  • Determine how Nginx should handle the part of the request that comes after IP:port (ie. the URI).
  • Similar to how Nginx has a specificity-based process for determining which server block will process the request, Nginx has an algorithm to determine which location block within the server should be used for handling requests.
  • Location blocks take the following form:
location <optional_modifier> <location_match> {
  • The location_match defines what Nginx should check the request URI against.
  • The optional_modifier affects the way Nginx will attempt to match the location block.
    • ex. check for prefix match (default), check for exact match (=), check for case-sensitive Regex (~)
  • The URI specified after location will be added to the path specified in the root directive
    • ex. if we specify root /var/www/ and the location block specifies /images/, then the path to the requested file on the local FS will be /var/www/images
  • ex. Imagine we had a server block:
server {
    location / {
        root /data/www;

    location /images/ {
        root /data;

in response to a request with URI starting with /images/, the server will send files from the /data/images directory.

Tasks of Nginx

Serving Static Content

  • Nginx can be configured to serve static content, such as HTML and images.
  • this involves setting up of a server block inside the http block with two location blocks.
    • multiple server blocks are able to be added, each specifying a different port.
http {
	server {

Reverse Proxy Server

  • When Nginx proxies a request, it sends the request to a specified proxied server, fetches the response, and sends it back to the client
    • it is possible to proxy requests to another HTTP server (eg. another Nginx server) or to a non-HTTP server (eg. express.js)
      • We use a specified protocol like FastCGI to do this
  • We can establish a proxy server by using the proxy_pass directive within a location block.
    • The value of proxy_pass is the address of the proxy server:
location /some/path/ {
  • In this config, all requests processed to /some/path/ to be sent to the proxy server at
    • ex. the request with the URI of /some/path/page.html will be proxied to
  • to pass a request to a non-HTTP server, the appropriate *_pass directive should be used
    • ex. fastcgi_pass


  • upon changing nginx.conf, we need to reload the nginx server with nginx -s reload.
  • logs are stored at either /usr/local/nginx/logs or /var/log/nginx


  • A root directive should occur outside of the location block. We can then use another root directive within a location block if we want to override it.
    • Conversely, if you were to add a root to every location block then a location block that isn’t matched will have no root. Therefore, it is important that a root directive occur prior to your location blocks, which can then override this directive if they need to.
  • source

  1. Conf