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;

  • I think you mean 'redirect', not 'resolve'. When you type in foo.com and your browser then goes to www.foo.com, that's a redirect, it's nothing to do with DNS (although probably does require that your DNS is setup properly and working).
    – mozboz
    Jun 26, 2020 at 21:28

2 Answers 2


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.

  • I'm building the site with my 11 year old cousin. The site is (perfectfarts.com).
    – Gee_k
    Jun 27, 2020 at 22:51

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.

  • Your right, this is a template configuration. There is another nginx configuration file which above this one, The rules in that file direct nginx to look in this one for the custom configuration of this site.<br>
    – Gee_k
    Jun 27, 2020 at 22:41
  • @WannabeGeek You'd better have some unified redirection mechanism, e.g. http://example.com -> https://www.example.com, http://www.example.com -> https://www.example.com, https://example.com -> https://www.example.com (or the same thing without www in the main domain), it would be more SEO-friendly. To find out what happened with your current config and why some resources are not loaded you should look for any errors in the browser development tools. Jun 27, 2020 at 22:53
  • Any browser tools you recommend using to in this case?
    – Gee_k
    Jun 29, 2020 at 8:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.