Redirect root to www nginx on HTTPS

Question

Here is the current status:

• http://example.com to https://www.example.com works
• http://www.example.com to https://www.example.com works
• https://example.com to https://www.example.com DOESN'T redirect - just resolves to https://example.com

Tried multiple configs and still comes up with the same results. Not sure if it is an order of elements in the config field of if I'm just misconfiguring completely.

Config file:

server {
    server_name www.example.com example.com 123.123.123.123;


    root /var/www/wdiu-new/web;
    location / {
        # try to serve file directly, fallback to app.php
        try_files $uri /app.php$is_args$args;
    }
    # DEV
    # This rule should only be placed on your development environment
    # In production, don't include this and don't deploy app_dev.php or config.php
    location ~ ^/(app_dev|config)\.php(/|$) {
        fastcgi_pass unix:/var/run/php/php7.1-fpm.sock;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        include fastcgi_params;
        # When you are using symlinks to link the document root to the
        # current version of your application, you should pass the real
        # application path instead of the path to the symlink to PHP
        # FPM.
        # Otherwise, PHP's OPcache may not properly detect changes to
        # your PHP files (see https://github.com/zendtech/ZendOptimizerPlus/issues/126
        # for more information).
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $realpath_root;
    }
    # PROD
    location ~ ^/app\.php(/|$) {
        fastcgi_pass unix:/var/run/php/php7.1-fpm.sock;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        include fastcgi_params;
        # When you are using symlinks to link the document root to the
        # current version of your application, you should pass the real
        # application path instead of the path to the symlink to PHP
        # FPM.
        # Otherwise, PHP's OPcache may not properly detect changes to
        # your PHP files (see https://github.com/zendtech/ZendOptimizerPlus/issues/126
        # for more information).
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $realpath_root;
        # Prevents URIs that include the front controller. This will 404:
        # http://domain.tld/app.php/some-path
        # Remove the internal directive to allow URIs like this
        internal;
    }

    # return 404 for all other php files not matching the front controller
    # this prevents access to other php files you don't want to be accessible.
    location ~ \.php$ {
        return 404;
    }

    error_log /var/log/nginx/project_error.log;
    access_log /var/log/nginx/project_access.log;
 # managed by Certbot

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/new.example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/new.example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

server {
    listen 80;
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}


server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/new.example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/new.example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    location / {
        return 301 https://www.example.com$request_uri;
    }
}


 server {

   if ($host = www.example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    server_name www.example.com 123.123.123.123;
    listen 80;
    return 404; # managed by Certbot
}

Answer 1

server {
    server_name www.example.com example.com 123.123.123.123;

Your first server block is handling HTTPS requests for example.com.

You should remove that hostname so that requests for example.com fall through to the following server block that contains the redirect.

(In fact remove the IP as well and move that to the redirect host, although you will likely get browser SSL warnings if you actually try and use https://<ip>)

Answer 2

I suppose that you are hoping that this block server { listen 80; server_name example.com; return 301 https://www.example.com$request_uri; } redirects https://example.com to https://www.example.com

but it won't work, since it is only listening on port 80.

Anyway, you do have lots of redundancy in your server {} blocks. I recommend you organize that better or you will keep having trouble.