错误请求 (400) 在 ubuntu 上使用 Nginx 和 Django

Bad request (400) using nginx on ubuntu with Django

我为我的网络服务器做了自己的配置,如果我通过 IP 访问我的网站,一切都运行良好 - http://179.188.3.54

我还没有更改我的域,我像这样修改了我的 /etc/hosts 本地:

179.188.3.54     cinegloria.com

所以,当我尝试在我的浏览器上访问我的网站时,我收到错误请求 (400)。这是我的 nginx 配置:

server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;

root /usr/share/nginx/www;
index index.html index.htm;

access_log /var/log/nginx/domain-access.log;
error_log /var/log/nginx/error.log;

server_name cinegloria.com www.cinegloria.com;

location /static {
        alias /cinegloria/cinegloria/cinegloria/static/;
}

location / {
    proxy_pass_header Server;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_set_header X-Forwarded-For  $remote_addr;
    proxy_set_header X-Scheme $scheme;
    proxy_connect_timeout 10;
    proxy_read_timeout 10;
    proxy_pass http://0.0.0.0:8000/;
    fastcgi_split_path_info ^()(.*)$;
}
}

我不知道哪里出了问题,据我所知,我不需要更改任何其他内容。有什么想法吗?

proxy_pass http://0.0.0.0:8000/ 是什么意思?也许必须有 127.0.0.1 或 179.188.3.54

并在 proxy_pass

中检查您的端口
root@RDE-1.3:~# curl -I http://179.188.3.54
HTTP/1.1 200 OK
Server: nginx/1.1.19
Date: Tue, 24 Feb 2015 15:46:10 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
X-Frame-Options: SAMEORIGIN

root@RDE-1.3:~#
root@RDE-1.3:~#
root@RDE-1.3:~# curl -I http://179.188.3.54:8000


curl: (7) couldn't connect to host

PS: 您是否添加了 ALLOWED_HOSTS? 默认值:[](空列表)

ALLOWED_HOSTS = [
    '.example.com',  # Allow domain and subdomains
    '.example.com.',  # Also allow FQDN and subdomains
]

A list of strings representing the host/domain names that this Django site can serve. This is a security measure to prevent an attacker from poisoning caches and password reset emails with links to malicious hosts by submitting requests with a fake HTTP Host header, which is possible even under many seemingly-safe web server configurations.

Values in this list can be fully qualified names (e.g. 'www.example.com'), in which case they will be matched against the request’s Host header exactly (case-insensitive, not including port). A value beginning with a period can be used as a subdomain wildcard: '.example.com' will match example.com, www.example.com, and any other subdomain of example.com. A value of '*' will match anything; in this case you are responsible to provide your own validation of the Host header (perhaps in a middleware; if so this middleware must be listed first in MIDDLEWARE_CLASSES).

If the Host header (or X-Forwarded-Host if USE_X_FORWARDED_HOST is enabled) does not match any value in this list, the django.http.HttpRequest.get_host() method will raise SuspiciousOperation.

When DEBUG is True or when running tests, host validation is disabled; any host will be accepted. Thus it’s usually only necessary to set it in production.

This validation only applies via get_host(); if your code accesses the Host header directly from request.META you are bypassing this security protection.