View Feed
Coffee Room
Discuss anything here - everything that you wish to discuss with fellow engineers.
12890 Members
Join this group to post and comment.
Kaustubh Katdare
Kaustubh Katdare • Jul 29, 2018

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;


  # 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


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

  return 301$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)

Kaustubh Katdare
Kaustubh Katdare • Jul 30, 2018

@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.

Kaustubh Katdare
Kaustubh Katdare • Jul 30, 2018

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. 

Ankita Katdare
Ankita Katdare • Jul 30, 2018

Yes, I checked once again. The MI Browser redirects to in less than a second.

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

Kaustubh Katdare
Kaustubh Katdare • Jul 31, 2018

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!

Share this content on your social channels -