As modern frontend frameworks grow more and more complex, there is an alarming rise in the number of the so-called client-side redirects. Nginx has a great facility that will allow you to save some traffic and precious client waiting time on client redirects. First, let us briefly refresh your knowledge of those redirects.

All the HTTP responses are documents consisting of three principal parts:

There is a lot of good HTTP response codes documentation on the Internet (and also some hilarious pieces given at http://httpstatusdogs.com/)—the ones that are relevant to our discussion are in the fourth hundred, that is, between 300 and 399.

Responses with those codes are indications that a browser should immediately make another request instead of the original one. This is why they are called redirects. The semantic differences between various 3xx codes are less important here.

What is important is that many redirects are superfluous. HTTP clients (for example, browsers) spend time on redirects that serve no particular reason besides cleaning up the URL in the address bar. Does Yahoo really need to redirect me from yahoo.de to ru.yahoo.com, www.yahoo.com, and https://www.yahoo.com by making my browser issue three additional requests that could easily be avoided? If a website under your control does such things, you may address the question to the respective developers. You may also suggest an easy fix; see later in the text.

There is a cool, little web service that allows you to see the redirects chain as well as some other metainformation that may be useful for debugging. It may be referred to at https://httpstatus.io/.

You may go and check whether some of your websites make unneeded redirects, which may cost your slow mobile users' precious seconds before they actually get to the content of your site.

Nginx has a feature named "internal redirects". The idea is that all the intermediate HTTP request-response pairs are processed right inside the server. The client gets the content from the end of the chain in response to the original request. There are a number of methods to enable internal redirects in Nginx, but probably the most flexible is the X-Accel-Redirect response header that an upstream behind Nginx may generate.

For the internal redirects to work with this method, you will have to change the configuration of your upstream software. Instead of generating true redirects via HTTP 3xx response codes coupled with the Location: response header, you will have to generate the earlier-mentioned X-Accel-Redirect: header. This is literally the only change you will have to make. There are a number of places where you need to be careful; all of them concerning the security model of the browsers. The geographic redirects as shown with the Yahoo! example are actually quite rare nowadays, so optimizing them may not be worth the troubles you will get by issuing cookies on the wrong domain. But the example.com to www.example.com redirects are still very popular and look like perfect candidates for internal redirects.