nginx redirects

gistfile1.txt

Overview
Content rot has a tendency to creep up on you as a website or application ages. The last thing your visitors want when they reach your site, after clicking a link to it, is to be face planted with a 404 error. To make matters worse, too many 404s will have an impact on your search engine site rankings.

We can battle 404s with redirect rules written in our Nginx configurations. The rules can either suggest to the web browser, search engine and anything that the content has permanently moved, or we suggest the content has only moved temporarily. Either way, you have a chance to guide the user to the new location of your content in a transparent manner.

Permanent Vs. Temporary
Two type of redirects exist. As you probably figured out from the heading, we can do either a permanent redirect (301) or a temporary redirect (302), depending on what our needs are. A permanent redirect tells user agents, including search engines, to update their indexes to replace the link with the new location, whereas temporary redirects instruct user agents to continue using the old one, but follow the request to a new path.

If you are unsure whether the redirect is going to be permanent or not, always start off with a temporary redirect. Undoing a permanent redirect may mean users will be unable to access your content or application for an extended period of time. For web client, that means after the caches are cleared. However, for a search engine, it could take several days or weeks to update.

Redirecting Domains
You may want to direct your users to a completely new domain, or maybe you want to enforce traffic to funnel through a single domain, such as to a ‘www’ address.

server {
     listen 80;
     server_name www.example.com
}
server {
     listen 80;
     server_name example.com
     return 301 http://www.example.com
}
We can also use a so-called wildcard domain to redirect all requests, except those going to a specific domain. In the example below, all traffic redirected to www.example.com, excluding any request going to directly to www.example.com and any going to www.myblog.com.

server {
     listen 80;
     server_name www.myblog.com
}
server {
     listen 80;
     server_name www.example.com
}
server {
     listen 80;
     server_name _;
     return 301 http://www.example.com
}
 

Redirect URI Matching
Within the server block of our application server, location blocks are used to match against a request URI that needs to be redirected.

server {
     listen 80;
     server_name example.com

     location = /post/learning-nginx-redirects {
          return 301 http://example.com/articles/nginx/how-to-do-redirects/
     }
}
 

Matching URLs
Sometimes you want to match against several URI’s based on a pattern using regex, other times you want to match against anything that starts with a particular string, and finally, you may want to match against an exact string.

Exact URI
When you want to match an exact URI, you would write the following rule.

location = /post/learning-nginx-redirects {
     return 301 http://example.com/articles/nginx/how-to-do-redirects/
}
Matching URI Path
There are times you may want to redirect anything under a specific path. The only difference between path matching and exact URI matching is the absence of the equals sign.

location /post {
     return 301 http://example.com/articles
}
Matching URI Patterns
location ~ ^/post/(.*) {
     rewrite ^ http://newexample.com/articles/$1;
}
 

Creating a Temporary Redirect
When using the return option, we use status code 302 to set the redirect as temporary.

location /post {
     return 302 http://example.com/articles
}
 

 

Creating a Permanent Redirect
When using the return option, we use status code 301 to set the redirect as permanent.

location /post {
     return 301 http://example.com/articles
}