Site resolves to www in Firefox and without in Chrome

Question

I am guessing this is being caused by my nginx configuration, however I can not quite figure out how to troubleshoot in order to resolve.

I am using Ubuntu 20.04 with a LEMP stack to host a wordpress installation. Everything works fine except this quirk, which is that if I type in the site's URL into Chrome, the site will resolve to 'https://example.com' and everything on the site loads fine.

However, in Firefox if I type in the site's URL it will resolve to 'https://www.example.com', which would be fine except that certain icons on the site will now not load, are not show and are replaced by a square box.

Below is the nginx configuration I am using:

server {
listen       80;

server_name  www.{{ domain_name }}{{ tld }} {{ domain_name }}{{ tld }};
return 301 https://$server_name$request_uri;



}

server {
listen 443 ssl;
server_name  www.{{ domain_name }}{{ tld }};
ssl_certificate /etc/letsencrypt/certs/fullchain_{{ domain_name }};
ssl_certificate_key /etc/letsencrypt/keys/{{ domain_name }}.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM;
#    ssl_ecdh_curve secp521r1;
root   /home/{{ domain_name }}/public_html;
index index.php index.html index.htm;

location / {
    try_files $uri $uri/ /index.php?q=$uri&$args;
}
#    return 301 https://www.$server_name$request_uri;

location ~ \.php$ {
        # Basic
        try_files $uri =404;
        fastcgi_index index.php;

        # Create a no cache flag
        set $no_cache "";

        # Don't ever cache POSTs
        if ($request_method = POST) {
          set $no_cache 1;
        }

        # Admin stuff should not be cached
        if ($request_uri ~* "/(wp-admin/|wp-login.php)") {
          set $no_cache 1;
        }

        # WooCommerce stuff should not be cached
        if ($request_uri ~* "/store.*|/cart.*|/my-account.*|/checkout.*|/addons.*") {
          set $no_cache 1;
        }

        # If we are the admin, make sure nothing
        # gets cached, so no weird stuff will happen
        if ($http_cookie ~* "wordpress_logged_in_") {
          set $no_cache 1;
        }

        # Cache and cache bypass handling
        fastcgi_no_cache $no_cache;
        fastcgi_cache_bypass $no_cache;
        fastcgi_cache microcache;
        fastcgi_cache_key $scheme$request_method$server_name$request_uri$args;
        fastcgi_cache_valid 200 60m;
        fastcgi_cache_valid 404 10m;
        fastcgi_cache_use_stale updating;


        # General FastCGI handling
        fastcgi_pass unix:/var/run/php/{{ domain_name }}.sock;
        fastcgi_pass_header Set-Cookie;
        fastcgi_pass_header Cookie;
        fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_param SCRIPT_FILENAME $request_filename;
        fastcgi_intercept_errors on;
        include fastcgi_params;
}

location ~* \.(js|css|png|jpg|jpeg|gif|ico|woff|ttf|svg|otf)$ {
        expires 30d;
        add_header Pragma public;
        add_header Cache-Control "public";
        access_log off;
}

}

Answer 1

Everytime I've seen the thing you're describing it was due to the browser having the redirect cached.

I can't see any reason that different browsers would behave differently in this case. You may want to try a browser/machine you haven't used before to access this site as this will show you definitely what's happening.

You could also reply here with the domain and with a tool like wget/curl it's easy to see exactly what redirects are happening.

Answer 2

What you show in your question looks like some nginx template, not the real nginx config. Anyway, lets look how nginx would behave using your config assuming your domain is example.com.

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

This block will redirect plain HTTP requests (http://example.com/..., http://www.example.com/...) to https://www.example.com/..., the $server_name internal nginx variable would have a value of the first string given in server_name directive parameters, www.example.com in this case. Moreover, if it is the only defined server block listening on port 80, it would process any incoming request on this port and redirect it to https://www.example.com/... no matter what value has the Host HTTP header of this request (or if it present at all).

server {
    listen       443 ssl;
    server_name  www.example.com;
    ...
}

This block will process incoming requests for www.example.com domain on port 443, i.e. https://www.example.com/... requests, but as with previous block, if it is the only defined server block listening on port 443, it would process any incoming SSL request no matter what is the value has the Host HTTP header of the request. If you certificate issued for both example.com and www.example.com domains, it would process any https://example.com/... requests without any errors like Certificate mismatch or similar ones.

Summing up, it looks like you enter http://example.com in Firefox (and got a 301 https://www.example.com redirection) and https://example.com in Chrome (and got a reponse content without any redirections). It isn't explain why you got errors in Firefox, anyway, but describe nginx behavior with this configuration. Enter http://example.com in Chrome address bar and you'll be redirected to https://www.example.com. Enter https://example.com in Firefox address bar and you'll received site content without any redirections. Do it in incognito window to avoid possible cached redirections or contents.