server {
    listen        80;
    server_name   nginx.org  www.nginx.org;
    root          /data/www;

    location / {
        index     index.html  index.php;
    }

    location ~* \.(gif|jpg|png)$ {
        expires   30d;
    }

    location ~ \.php$ {
        fastcgi_pass   localhost:9000;
        fastcgi_param  SCRIPT_FILENAME
                       $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
}

nginx first searches for the most specific location given by literal strings regardless of the listed order. In the configuration above the only literal location is “/” and since it matches any request it will be used as a last resort. Then nginx checks locations given by regular expression in the order listed in the configuration file. The first matching expression stops the search and nginx will use this location. If no regular expression matches a request, then nginx uses the most specific literal location found earlier.

File excerpt: nginx.conf location directives

location / { }
location /images/ { }
location /blog/ { }
location /planet/ { }
location /planet/blog/ { }

location ~ IndexPage\.php$ { }
location ~ ^/BlogPlanet(/|/index\.php)$ { }

location ~* \.(pl|cgi|perl|prl)$ { }
location ~* \.(md|mdwn|txt|mkdn)$ { }

location ^~ /images/IndexPage/ { }
location ^~ /blog/BlogPlanet/ { }

location = / { }

The first five examples are “literal string” matches, and match the beginning part of the request following the host portion. In a hypothetical request for http://ducklington.org/, assuming that there is a server_name for ducklington.org, the “location /” directive will catch this request. Nginx will always fulfill a request with most specific match. A request for http://ducklington.org/planet/blog/ and http://ducklington.org/planet/blog/about/ will be fulfilled by the “location /planet/blog/” even though “location /planet/” also fills this request.

When a location directive is followed by a tilde (e.g. ~) as in the fourth group of examples, nginx performs a regular expression match. These matches are always case sensitive, so in the first example requests ending in IndexPage.php would match, but indexpage.php would not. In the second the regular expression ^/BlogPlanet(/|index\.php)$ will match requests for /BlogPlanet/ and /BlogPlanet/index.php, but not /BlogPlanet, /blogplanet/, or /blogplanet/index.php. Nginx uses Perl Compatible Regular Expressions (PCRE).

Using a tilde-asterisk (e.g. ~*) as an argument to a location directive, as in the third group of examples, removes case sensitivity from the matches. These examples all specify how nginx should process requests that end in a particular file extension. In the first example, any file ending in: .pl, .PL, .cgi, .CGI, .perl, .Perl, .prl, and .PrL (among others) will match the request.

In the next group of examples, the caret-tilde argument (e.g. ^~) to location functions like the literal string matches of the first group. However, when used, they force nginx to stop searching for more specific matches. So in these examples, the location directives for “^~ /images/IndexPage/” and “^~ /blog/BlogPlanet/” would be used even though the request matches another location directive. See below for more information about the order and priority of location directive processing.

Finally, using the equal sign (e.g. =) as an argument to location forces an exact match with the path requested and then stops searching for more specific matches. For instance, the final example will only match http://ducklington.org/ but not http://ducklington.org/index.html. Using exact matches can speed up request times slightly especially when some requests are particularly popular.

Directives are processed in the following manner:

• Exact string matches are processed first. If a match is found, nginx stops searching and fulfills the request.
• Remaining literal string directives are processed next. If the “^~” argument is used, then ngnix stops here and fulfills the request. Otherwise, nginx continues to process location directives.
• All location directives specified by regular expressions (with the ~ and ~* arguments) are processed. If a regular expression matches the request, nginx stops here and fulfills the request.
• When there are no regular expressions, or no regular expressions match, the most specific literal string match is used.

It is incumbent upon the administrator to ensure that possible location directives will match for every resource nginx is to provide for a given domain within the server block. Additionally, while nginx’s configuration parser is capable of reading nested location blocks, using location directives in this manner is not a supported behavior.

location / {
    root   html;
    index  index.html index.htm;
}

location / {
    root   /srv/www/ducklington.org/public_html;
    index  index.html index.htm;
}

location ~ \.pl$ {
    gzip off;
    include /etc/nginx/fastcgi_params;
    fastcgi_pass  127.0.0.1:8999;
    fastcgi_index index.pl;
    fastcgi_param  SCRIPT_FILENAME  /srv/www/ducklington.org/public_html$fastcgi_script_name;
}

Reference:

nginx.conf.zip

http://nginx.org/en/docs/http/request_processing.html

http://library.linode.com/web-servers/nginx/configuration/basic#location_configuration

http://articles.slicehost.com/2009/3/5/ubuntu-intrepid-nginx-configuration

http://blog.rackcorp.com/?p=31