Django错误：无效的HTTP#u主机头：u'/run/myprojectname/gunicorn.sock:&x27；

我知道有很多这样的问题，但是没有一个能回答我的问题

我知道Django的

ALLOWED_HOSTS

值阻止了对我IP上端口

80

的任何请求，这些请求没有相应的

主机：

值，并且当请求没有正确的值时，Django会给我发送电子邮件。我也知道解决这个问题的方法，但我正试图了解这样一个请求的性质，并确定这是否是我需要担心的安全问题

像这样的请求很有意义：

[Django] ERROR: Invalid HTTP_HOST header: '203.0.113.1'.  You may need to add u'203.0.113.1' to ALLOWED_HOSTS.

但这一点让我很害怕：

[Django] ERROR: Invalid HTTP_HOST header: u'/run/my_project_name/gunicorn.sock:'.

这是否意味着请求者向服务器发送了

Host:/run/my\u project\u name/gunicorn.sock

？如果是，他们如何获得我的

.sock

文件的路径名？我的服务器是否泄漏了这些信息

此外，由于我正在运行Django 1.6.5，我完全不明白为什么我会收到这些电子邮件，因为这些邮件已经标记为修复了一段时间

有人能解释一下我错过了什么吗

这是我的

设置。记录
变量：

{
    'disable_existing_loggers': False,
    'filters': {
        'require_debug_false': {'()': 'django.utils.log.RequireDebugFalse'}
    },
    'formatters': {
        'simple': {'format': '%(levelname)s %(message)s'},
        'verbose': {'format': '%(levelname)s %(asctime)s %(module)s %(process)d %(thread)d %(message)s'}
    },
    'handlers': {
        'console': {
            'class': 'logging.StreamHandler',
            'formatter': 'verbose',
            'level': 'DEBUG'
        },
        'mail_admins': {
            'class': 'django.utils.log.AdminEmailHandler',
            'filters': ['require_debug_false'],
            'level': 'ERROR'
        }
    },
    'loggers': {
        'django.request': {
            'handlers': ['mail_admins'],
            'level': 'ERROR',
            'propagate': True
        },
        'my_project_name': {
            'handlers': ['console'], 
            'level': 'DEBUG'
        }
    },
    'version': 1
}

这是我的nginx配置：

worker_processes 1;
pid /run/nginx.pid;
error_log /var/log/myprojectname/nginx.error.log debug;
events {
}
http {
  include mime.types;
  default_type application/octet-stream;
  access_log /var/log/myprojectname/nginx.access.log combined;
  sendfile on;
  gzip on;
  gzip_http_version 1.0;
  gzip_proxied any;
  gzip_min_length 500;
  gzip_disable "MSIE [1-6]\.";
  gzip_types text/plain text/html text/xml text/css
             text/comma-separated-values
             text/javascript application/x-javascript
             application/atom+xml;
  upstream app_server {
    server unix:/run/myprojectname/gunicorn.sock fail_timeout=0;
  }
  server {
    listen 80 default;
    listen [::]:80 default;
    client_max_body_size 4G;
    server_name myprojectname.mydomain.tld;
    keepalive_timeout 5;
    root /var/www/myprojectname;
    location / {
      try_files $uri @proxy_to_app;
    }
    location @proxy_to_app {
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $host;
      proxy_redirect off;
      proxy_pass http://app_server;
    }
    error_page 500 502 503 504 /500.html;
    location = /500.html {
      root /tmp;
    }
  }
}

server {
    listen 80 default_server;
    return 444;
}

最后，我在我的nginx访问日志中找到了这个。它对应于通过电子邮件抱怨/run/myprojectname/gunicorn.sock是无效的HTTP_主机头*

当然，这都是一句话：

2014/09/05 20:38:56 [info] 12501#0: *513 epoll_wait() reported that client
prematurely closed connection, so upstream connection is closed too while sending
request to upstream, client: 54.84.192.68, server: myproject.mydomain.tld, request:
"HEAD / HTTP/1.0", upstream: "http://unix:/run/myprojectname/gunicorn.sock:/"

显然，我仍然不知道这意味着什么：-(


更新#1：添加了我的
设置。日志记录
更新#2：添加了我的nginx配置
更新#3：从我的nginx日志中添加了一行有趣的内容
更新#4：更新了我的nginx配置
似乎

proxy_set_header Host $http_host

到

和
server\u name
到用于访问服务器的地址。如果希望它包含所有内容，应使用
server\u name www.domainname.com”“
（）

我不确定，但我认为如果客户端不发送
主机：
头，您会看到什么。因为nginx没有收到
主机：
头，所以没有
主机：
头被传递给gunicorn。在这一点上，我认为gunicorn将
主机：
作为套接字路径填充，并告诉Django，因为这是连接已使用操作。使用
$host
并在nginx中设置
服务器名称应确保
主机：
正确传递给gunicorn并解决此问题

至于电子邮件，根据您链接的票证中的信息，似乎仍在为不允许的主机发送电子邮件。添加到文档中的还有：

我遇到一些评论，认为禁止电子邮件不是一个好主意，因为它不能直接解决这个问题。我发现的最有效的解决方案是在您的nginx设置中添加以下内容：

server {

    ...

    ## Deny illegal Host headers
    if ($host !~* ^(mydomain.com|www.mydomain.com)$ ) {
        return 444;
    }
}

有关更多信息：

这篇博文提到了这个问题。
我知道这是一个老问题，但今天我遇到了这个问题。建议的解决方案是在nginx配置中添加一个“全面”nginx服务器：

worker_processes 1;
pid /run/nginx.pid;
error_log /var/log/myprojectname/nginx.error.log debug;
events {
}
http {
  include mime.types;
  default_type application/octet-stream;
  access_log /var/log/myprojectname/nginx.access.log combined;
  sendfile on;
  gzip on;
  gzip_http_version 1.0;
  gzip_proxied any;
  gzip_min_length 500;
  gzip_disable "MSIE [1-6]\.";
  gzip_types text/plain text/html text/xml text/css
             text/comma-separated-values
             text/javascript application/x-javascript
             application/atom+xml;
  upstream app_server {
    server unix:/run/myprojectname/gunicorn.sock fail_timeout=0;
  }
  server {
    listen 80 default;
    listen [::]:80 default;
    client_max_body_size 4G;
    server_name myprojectname.mydomain.tld;
    keepalive_timeout 5;
    root /var/www/myprojectname;
    location / {
      try_files $uri @proxy_to_app;
    }
    location @proxy_to_app {
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $host;
      proxy_redirect off;
      proxy_pass http://app_server;
    }
    error_page 500 502 503 504 /500.html;
    location = /500.html {
      root /tmp;
    }
  }
}

server {
    listen 80 default_server;
    return 444;
}

他们推荐相同的解决方案，给出或接受一些语法细节

这样，请求就不会发送到django，当nginx收到一个格式错误的请求时，连接会立即关闭。
这听起来似乎有道理，但我想测试这样的请求，看看是否可以复制它。运行
curl 203.0.113.1
当前会导致一封电子邮件，声称203.0.113.1是无效的主机头，并且
curl 203.0.113.1-H“Host:”
结果是根本没有邮件。你能解释一下我如何重现给我那封gunicorn电子邮件的请求吗？至于问题的第二部分，为什么这些电子邮件会通过？如果允许的话，主机已经拒绝了它们，为什么Django会向我发送关于它的电子邮件？我设法重新创建了gunicorn通过使用telnet和发送
HEAD/HTTP/1.0
发送电子邮件。因此，我不再担心我的配置泄漏问题。但是，即使将
server\u name
设置为
myproject.mydomain.tld
并设置
proxy\u set\u header Host$Host
，电子邮件仍会源源不断地出现：-（我已经更新了nginx配置以显示新的值。@DanielQuinn是的，非常确定它没有泄漏外部的套接字路径……它是在内部某个地方传递的东西。那么您仍然看到类似于
[Django]的东西吗错误：无效的HTTP_主机头：u'/run/my_project\u name/gunicorn.sock:'。
？我本以为在根据上述内容更新设置后，它不会再显示该错误。此外，还更新了关于如何停止发送此错误的电子邮件的答案。感谢Django代码段。我不知道我需要显式支持ss这些类型的消息。你是对的，gunicorn的电子邮件已经停止了进来，尽管我找到了原因：现在向我的ip发出HEAD请求，请求
/
只返回我网站的首页HEAD数据。你可能会认为允许的主机也会拒绝拒绝拒绝不允许的主机的HEAD请求。这应该是可以接受的答案，尤其是ally，因为它引用了Django文档中的解决方案，比禁止电子邮件/日志更有意义。更新链接：我有“拒绝非法主机头”解决方案来自我的nginx配置，但仍然从gunicorn获得错误。此答案将其永久修复。使用这是我找到的最佳答案进行测试。谢谢。@Teekin我建议您查看此答案，因为它来自官方文档。我仍然更喜欢您的答案，因为它包含有问题的w文件中的解决方案ebsite本身，不考虑其环境。例如，它可以包含在模板中用于设置新实例。