Question

Trying to point domain to my VPS and getting a 400 error

Posted on March 7, 2017
Nginx Ubuntu 16.04 Django
Asked by easycompany80

I have a Django site on Nginx/Ubuntu here:

http://128.199.120.162/

I have a domain codego.co with Godaddy that I have already pointed towards the DigitalOcean name servers.

I have followed the DO tutorial for this and have setup the DNS records as follows:

CNAME - www.codego.co A - 128.199.120.162 NS - ns1.digitalocean.com. (and then ns2 etc etc)

in my Django sites’ settings file I have both the server ip and domain name setup in ‘Allowed hosts’ and also in the Nginx server block settings and yet Im getting a 400 bad request error at the domain…

any suggestions?

thanks

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

easycompany80 • March 8, 2017

Accepted Answer

OK, think I figures it out, it seems my settings.py didnt have the DEBUG = setting in at all, I must have deleted it by accident at one point, never knew it was so critical!

easycompany80 • March 8, 2017

thanks for the answers guys, to clarify what I have setup:

Django settings.py allowed hosts:

ALLOWED_HOSTS = [‘128.199.120.162’, ‘codego.co’, ‘www.codego.co’]

Nginx server setup in /etc/nginx/sites-available:

“”"

server {
    listen 80;
    server_name 128.199.120.162 codego.co www.codego.co;

    access_log on;

location = /favicon.ico { access_log off; log_not_found off; }
location /static/ {
    root /home/david/codegoblog;
}
location /media/ {
    root /home/david/codegoblog;
}

location / {

    include         uwsgi_params;
    uwsgi_pass      unix:/run/uwsgi/codegoblog.sock;
}

}

“”"

this is a sample output of Nginx error log:

1.157.96.109, server: 128.199.120.162, request: “GET http://www.so.com/?rands=_160219332017520361821316 HTTP/1.0”, upstream: “uwsgi://unix:/run/uwsgi/firstsite.sock:”, host: “www.so.com” 2017/03/08 03:49:16 [crit] 28812#28812: *978 connect() to unix:/run/uwsgi/firstsite.sock failed (2: No such file or directory) while connecting to upstream, client: 61.157.96.109, server: 128.199.120.162, request: “GET http://m.baidu.com/?rands=_1507898306026201794660928 HTTP/1.0”, upstream: “uwsgi://unix:/run/uwsgi/firstsite.sock:”, host: “m.baidu.com” 2017/03/08 03:49:17 [crit] 28812#28812: *980 connect() to unix:/run/uwsgi/firstsite.sock failed (2: No such file or directory) while connecting to upstream, client: 61.157.96.109, server: 128.199.120.162, request: “GET http://www.sogou.com/?rands=_414056450811964332892176 HTTP/1.0”, upstream: “uwsgi://unix:/run/uwsgi/firstsite.sock:”, host: “www.sogou.com” 2017/03/08 04:16:11 [crit] 28812#28812: *984 connect() to unix:/run/uwsgi/firstsite.sock failed (2: No such file or directory) while connecting to upstream, client: 163.172.168.251, server: 128.199.120.162, request: “GET http://www.bing.com HTTP/1.1”, upstream: “uwsgi://unix:/run/uwsgi/firstsite.sock:”, host: “www.bing.com”

as you can see I have uwsgi as well and this is the error log from that:

Thu Feb 16 07:32:03 2017 - received message 0 from emperor SIGINT/SIGQUIT received…killing workers… worker 1 buried after 1 seconds worker 2 buried after 1 seconds worker 3 buried after 1 seconds worker 4 buried after 1 seconds worker 5 buried after 1 seconds goodbye to uWSGI. chdir(): No such file or directory [core/uwsgi.c line 1610] VACUUM: unix socket /var/uwsgi/codego.sock removed.

so there appear to be errors in both the nginx and uwsgi logs but then why is the site running just fine at http://128.199.120.162/ ?

Ryan Quinn

DigitalOcean Employee

• March 7, 2017

This does not appear to be a DNS problem. The domain www.codego.co is resolving properly to the IP and the service is answering (though it is answering with an error). I would recommend reviewing your web server log files as there is likely more information to work from. If you can also share the configuration you’re using it would be helpful in identifying a source of the problem.