Set up Django, Nginx and Ubuntu 18.04 - "welcome to nginx" landing page displays when www. prefix is loaded with domain. Works fine without.

October 6, 2018 2k views
Nginx Django
PC000
By:
PC000

Hello,

Warning - Complete newbie here.

I've followed the below guide "How To Set Up Django with Postgres, Nginx, and Gunicorn on Ubuntu 18.04" to set up my Django website.

https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-18-04

Everything works fine when i search for my website via "website.com", however when i search for "www.website.com" i get a welcome to nginx landing page.

I've attempted to fix this by adding the "www." prefix version of my domain to the server_name line in my server block as per below. 

server {
    listen 80;
    server_name website.com www.website.com;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/peter/websitedirectory;
    }

    location / {
        include proxy_params;
        proxy_pass http://unix:/run/gunicorn.sock;
    }
}

However when running sudo nginx - t on the above, i get a warning:

nginx: [warn] conflicting server name: "www.website.com" on 0.0.0.0:443, ignored

I'm not entirely sure what this means. I feel like this should be relatively simple to fix, can anyone help? Thanks!

Log In to Comment
4 Answers
unixynet October 6, 2018

What do you get when you search for www.website.com in the nginx directory?

grep "www.website.com" -r /etc/nginx

Reply
  • PC000 October 6, 2018

    Hello, i'm getting the below thanks:

    /etc/nginx/sites-available/default: servername www.website.com; # managed by Certbot
    /etc/nginx/sites-available/default: ssl    certificate /etc/letsencrypt/live/www.website.com/fullchain.pem; # managed by Certbot
    /etc/nginx/sites-available/default: sslcertificatekey /etc/letsencrypt/live/www.website.com/privkey.pem; # managed by Certbot
    /etc/nginx/sites-available/default: if ($host = www.website.com) {
    /etc/nginx/sites-available/default: servername www.website.com;
    /etc/nginx/sites-available/website: server    name website.com www.website.com;

    • PC000 October 6, 2018

      (For some reason the underscores were automatically removed)

    • unixynet October 7, 2018

      You have two places where you're (re)defining the domain. One in /etc/nginx/sites-available/default and the other in /etc/nginx/sites-available/website. This can cause conflict. So get rid of the one you don't need and restart Nginx.

      • PC000 October 8, 2018

        Hi, this might be a dumb question but how do i get rid of the one i don't need? I assume default is the one i don't need? Thanks

      • PC000 October 8, 2018

        I've removed code referencing the redefined domain from /etc/nginx/sites-available/default by hashing out all rows related to www.website.com.

        My new output from grep in the nginx directory is below:

        /etc/nginx/sites-available/default:## servername www.website.com; # managed by Certbot
        /etc/nginx/sites-available/default:## ssl        certificate /etc/letsencrypt/live/www.website.com/fullchain.pem; # managed by Certbot
        /etc/nginx/sites-available/default:## sslcertificatekey /etc/letsencrypt/live/www.website.com/privkey.pem; # managed by Certbot
        /etc/nginx/sites-available/default:## if ($host = www.website.com) {
        /etc/nginx/sites-available/default:## servername www.website.com;
        /etc/nginx/sites-available/website: server        name website.com www.website.com;

        After restarting nginx, i still have the same issue.

        • unixynet October 8, 2018

          Can you copy/paste the content of your vhost files here (ssl and non-ssl)?

          • PC000 October 9, 2018

            Thanks, is the code below what you're after?

            Just as a test, yesterday i also removed all reference to website.com and www.website.com placing a dummy domain under server_name in /etc/nginx/sites-available/website. I restarted nginx and tested my website.com and www.website.com domain. Everything was still the same (website.com leads to django landing page, www.website.com leads to "welcome to nginx" landing page. This seems unusual?

            /etc/nginx/sites-available/website:

            
server {
    server_name website.com www.website.com;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/peter/website;
    }

    location / {
        include proxy_params;
        proxy_pass http://unix:/run/gunicorn.sock;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/website.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/website.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 {
    if ($host = website.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    server_name website.com;
    return 404; # managed by Certbot


}

            /etc/nginx/sites-available/default:

            ##
# You should look at the following URL's in order to grasp a solid understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# https://www.nginx.com/resources/wiki/start/
# https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
# https://wiki.debian.org/Nginx/DirectoryStructure
#
# In most cases, administrators will remove this file from sites-enabled/ and
# leave it as reference inside of sites-available where it will continue to be
# updated by the nginx packaging team.
#
# This file will automatically load configuration files provided by other
# applications, such as Drupal or Wordpress. These applications will be made
# available underneath a path with that package name, such as /drupal8.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##

# Default server configuration
#
server {
        listen 80 default_server;
        listen [::]:80 default_server;

        # SSL configuration
        #
        # listen 443 ssl default_server;
        # listen [::]:443 ssl default_server;
        #
        # Note: You should disable gzip for SSL traffic.
        # See: https://bugs.debian.org/773332
        #
        # Read up on ssl_ciphers to ensure a secure configuration.
        # See: https://bugs.debian.org/765782
        #
        # Self signed certs generated by the ssl-cert package
        # Don't use them in a production server!
        #
        # include snippets/snakeoil.conf;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

        server_name _;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
        }

        # pass PHP scripts to FastCGI server
        #
        #location ~ \.php$ {
        #       include snippets/fastcgi-php.conf;
        #
        #       # With php-fpm (or other unix sockets):
        #       fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
        #       # With php-cgi (or other tcp sockets):
        #       fastcgi_pass 127.0.0.1:9000;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #       deny all;
        #}
}


# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink that
# to sites-enabled/ to enable it.
#
#server {
#       listen 80;
#       listen [::]:80;
#
#       server_name example.com;
#
#       root /var/www/example.com;
#       index index.html;
#
#       location / {
#               try_files $uri $uri/ =404;
#       }
#}

##server {

        # SSL configuration
        #
        # listen 443 ssl default_server;
        # listen [::]:443 ssl default_server;
        #
        # Note: You should disable gzip for SSL traffic.
        # See: https://bugs.debian.org/773332
        #
        # Read up on ssl_ciphers to ensure a secure configuration.
        # See: https://bugs.debian.org/765782
        #
        # Self signed certs generated by the ssl-cert package
        # Don't use them in a production server!
        #
        # include snippets/snakeoil.conf;

##      root /var/www/html;

        # Add index.php to the list if you are using PHP
##      index index.html index.htm index.nginx-debian.html;
##       server_name www.website.com; # managed by Certbot


##      location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
##              try_files $uri $uri/ =404;
##      }

        # pass PHP scripts to FastCGI server
        #
        #location ~ \.php$ {
        #       include snippets/fastcgi-php.conf;
        #
        #       # With php-fpm (or other unix sockets):
        #       fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
        #       # With php-cgi (or other tcp sockets):
        #       fastcgi_pass 127.0.0.1:9000;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #       deny all;
        #}


##   listen [::]:443 ssl ipv6only=on; # managed by Certbot
##   listen 443 ssl; # managed by Certbot
##   ssl_certificate /etc/letsencrypt/live/website.com/fullchain.pem; # managed by Certbot
##   ssl_certificate_key /etc/letsencrypt/live/www.website.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 {
##    if ($host = www.website.com) {
##        return 301 https://$host$request_uri;
#    } # managed by Certbot


##      listen 80 ;
##      listen [::]:80 ;
##    server_name www.website.com;
##    return 404; # managed by Certbot


##}
PC000 October 6, 2018
[deleted]
Reply
unixynet October 9, 2018

Your default file has server_name _; which will match any host (including what you're seeing with www.website.com). Just disable the "default" file completely. Also change this line:

 if ($host = website.com) {

To

 if ($host ~ "website.com") {

And change this line:

server_name website.com;

To:

server_name website.com www.website;

Then restart Nginx.

Reply
  • PC000 October 10, 2018

    Thanks! This seemed to do the job. When i access www.website.com via google chrome, i'll be brought to website.com.

    However, during testing with internet explorer i received the below warning when loading www.website.com:

    "
    There is a problem with this website’s security certificate.

    The security certificate presented by this website was issued for a different website's address.
    "

    I thought this may have been an issue with certbot on www.website.com so i ran the below:

    sudo certbot --nginx -d www.website.com

    No success though.

    Additionally, if i click on "Continue to this website (not recommended)", i'm brought to a DisallowedHost page for www.website.com. I've updated my ALLOWED_HOSTS under /website/website/settings.py but this didn't fix the issue.

    Thanks for the help!

adamwojt November 23, 2018

Hey,

I am not sure if you still need this but what worked for was to add below to /etc/nginx/sites-available/yourprojectname:

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

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

}

I didn't disable default file just added that- of course adjust to your domain.

Reply
Have another answer? Share your knowledge.

Related Questions