Guide : How to configure NGINX to redirect from non-www to www with https?

Here's a quick guide for anyone who's struggling to configure NGINX web server on uBuntu to have the following configuration.

First, the problem I faced was this:-

The non-www to www redirects worked very well in Chrome on both mobile and desktop. However, Firefox and Safari refused to redirect the user to proper URLs when they tried to access 'non-www' version of the site; often throwing 'Page Not Secure' error. 

My goal was to achieve the following -

• Redirect All non-www traffic  to www
• Redirect All http traffic to https

I'll quickly explain the logic so that it'll be easier for you to understand what's going on.

1. Case I

Someone enters or links to 'http' instead of 'https' version of your website. In this case - following things need to happen:

• The server first must acknowledge a valid 'secure' request. This means, even if your server wants to server 'www' version, it must have a valid SSL certificate for 'non-www' version. Otherwise, browser will throw 'not secure' error, and the connection will be terminated even before the server can redirect to the proper 'https' url
• Once the server acknowledges proper request, it must will redirect the user to the correct 'https' + 'www' version of the url

2. Case II

Someone enters or links to 'non-www' version of your site. In this case, following things need to happen:

• The server must first accept the incoming request as a secure request. As mentioned above, we must have 'non-www' domain certificate for our domain. 
• Then the server must redirect the user to the proper URL (https + www)

This means, in our NGINX configuration, we need a check on what kind of request is being made. 

Take look at how to achieve it -

server {

  listen 443 ssl;

  listen [::]:443 ssl ipv6only=on;

  root /site/root;

  index index.php index.html;

   server_name www.mysite.com;

  # Other configuration parameters go here

  ....

  ....

  # SSL Certificate for 'www' version goes below

}

Now, the real magic happens (redirects and all) happens in the code block below -

server {

  listen 80;

  listen [::]:80;

  listen 443 ssl;

  liten [::]:443 ssl;

  # server_name should be non www

  server_name mysite.com;

  #we permanently aka 301 redirect them to https + www version

  return 301 https://www.mysite.com$request_uri;

# Include SSL certificate for 'non-www' version of the site below

}

Did you notice what happened in the second block? It took my several hours to arrive at this solution that is logical and works as expected. We're not only listening on both 80 and 440 ports, but for any request that comes to second 'server block', it gets redirected (301, permanent redirect) to the proper URL. You can test the server response in your Chrome or Firefox's Network inspector. 

Do not forget to include the SSL certificate for both the server blocks. Because if the request doesn't find a matching SSL certificate, it won't redirect the user properly. 

I hope this helps. If you have questions post them below. I'll try my best to answer them.

Whats currently happening is- when you type in < > in firefox, it still shows a blank page for few seconds and the browser name will be 'crazyengineers' with , and after few seconds say 5-6 we can see the https version. So is the lag expected? or  can it be reduced?

Happening in firefox version - 52.5.3 (32-bit)

@saandeep - I had to remove the links in order to prevent internal incorrect linking.

Looks like you'll have to update your browser. We checked on Window 10 and it's working as expected. In any case, redirect should take a few microseconds. 

Could you test this again? 

@Kaustubh  I am on windows 10 , but I cant update my firefox browser , will check at home and get back to you. I tested this on Edge browser (If anyone uses it ) and it works perfectly fine.

I double-checked with Safari, Chrome and Firefox on MacOS. Seems to be working absolutely fine. Could you confirm that redirect actually takes time when on older version of Firefox in Windows 10? It'd be awesome if you could check http -> https redirect.

If it does, I'd rather think that it's a browser issue than anything we could tweak on the server side. 

Redirects are the first things checked by our server and should be completed within shortest period of time. For delayed redirects, my guess would be a temporary network issue. 

@Ankita - could you test on MI browser? Please confirm that redirect issue doesn't exist and http->https, non-www to www happens in a fraction of a second. 

Yes, I checked once again. The MI Browser redirects to https://www.crazyengineers.com/threads/latest in less than a second.

I checked from home last night and its working well. If I see any issues I will report.

Thank you, Saandeep. Did the redirect take long time? It should be done within milliseconds. 

Sorry for the delay for the response, but fortunately there is no delay in response from the server! Its pretty quick!