Rewrites and redirects are used to direct the user to a different URI path. Redirects change the path of the URL on the user's browser while rewrites do not.

Redirects

When using a redirect, the user is redirected to a new URI and the URI changes in the browser.

Note: When the first parameter is a 300 series status code, the return directive accepts a URI as the second parameter.

location /logo {
    return 307 /thumb.png;
}

Rewrites

A rewrite sends the user to a new URI but changes the URI internally. The URI does not change for the user.

The rewrite directive is used for this. It accepts a regular expression as the 1st parameter and a URI as the 2nd parameter.

Rewrites are re-evaluated by NGINX as a completely new request, from the top down. This can consume little more system resources than a redirect.

A location block is needed for the new URI , like so:

    rewrite ^/user/\w+ /meet;

    location /meet {
      return 200 "Hello User";
    }

Here, \w+ is used to capture a word after /user/

So, /user/melvin will get rewritten to /meet. This will match the location block after it and display "Hello User".

We may also use regex capture groups to get the first word and pass it to the rewritten URI, like so:

    rewrite ^/user/(\w+) /meet/$1;

    location /meet {
      return 200 "Hello User";
    }

    location = /meet/john {
      return 200 "Hello John";
    }

Here, the URI /user/john will get rewritten to /meet/john and will match the exact match location as it has higher priority than the prefix match above.

the last flag

It is added at the end of a rewrite directive to make sure that it does not get rewritten again, even if there are other rewrite statements matching the new URI.

server {

    listen 80;
    server_name 167.99.93.26;

    root /sites/demo;

    rewrite ^/user/(\w+) /meet/$1 last;
    rewrite ^/meet/john /thumb.png;

    location /meet {

      return 200 "Hello User";
    }

    location = /meet/john {
      return 200 "Hello John";
    }
  }

Here, /user/john gets rewritten to /meet/john

There is a second rewrite directive that matches /meet/john and rewrites it to /thumb.png, but...

Since the last flag is added to the first rewrite, the second rewrite does not take effect. The user is served "Hello John".

try_files

The try_files directive can be used in a server context or in a location context. It is often used with variables.

location / {
    try_files $uri $uri/ /index.html;
}

In this example, when a request is made to Nginx, it will try to find a file that matches the requested URI ($uri). If the file exists, Nginx will serve it. If the file doesn't exist, Nginx will try to find a directory that matches the requested URI ($uri/). If a directory is found, Nginx will look for an index file within that directory (e.g., index.html) and serve it.

The last argument is evaluated as a rewrite. So it should be something that does not give an error.

try_files with named locations

server {

    listen 80;
    server_name www.melvincv.com;

    root /sites/mcv;

    try_files $uri /mouse.png /meet @friendly_404;

    location @friendly_404 {
      return 404 "Sorry, that file could not be found.";
    }

    location /meet {
      return 200 "Hello User";
    }

  }

In this example, the try_files directive will first try the URI, then mouse.png, then /meet and finally the named location @friendly404

Note: /meet is defined in a location block, but NGINX will only check if there is a meet folder relative to the site root.