Python django/nginx中无法解释的无效HTTP_主机错误

我经常在django中看到非常奇怪的无效_主机错误。网站域（从这里开始称为example.com）是nginx传递给django的唯一内容。example.com位于

django.conf.settings.ALLOWED\u HOSTS

中。其他一切都直接进入nginx的404。以下是我的配置中的相关行：

server { return 404; }
upstream django {
  server 127.0.0.1:3033;
}

server {
  listen      80;
  server_name classes.example.com;
  return 302 https://example.com/classes/;
}

server {
  listen      80;
  server_name *.example.com example.com;
  return 302 https://example.com$request_uri;
}

server {
  if ($host ~* "^classes.example.com$") {
    rewrite ^.*(?=\/)(.+)$ https://example.com/classes/ permanent;
    break;
  }

  listen   443;
  root /home/django/example.com;
  server_name *.example.com example.com;

  # here are static files/ irrelevant code

  location / {
    uwsgi_pass django;
    include uwsgi_params;
  }
}

对我来说，这意味着我永远不会看到下面的邮件发给我

可疑操作：无效的HTTP\u主机头（您可能需要设置允许的\u主机）：someotherdomainname.tld

然而，我每天通过标准的django错误记录器收到4到5个。

someotherdomain.tld

可以是*.example.com（我的服务器的通配符）、服务器的ip地址，或者像device-metrics-us-2.amazon.com:443或data.flurry.com这样的随机内容。为了让事情变得更加混乱，我可以转到server IP address或其他任何.example.com，我会看到nginx 404屏幕上没有错误电子邮件（预期行为）

---

我敢肯定，这是因为如果你在公司登录我们的公共wifi，该网站是供你作为客人登录的，然后它会将你重定向到我们的网站（令人恼火，但首席执行官坚持…）。这些错误是无害的，没有人报告在尝试访问amazon.com或类似网站时看到django错误页面。考虑到我的nginx配置，我很难理解它是如何实现的。

假设您正确配置了django（

允许的\u主机

）；那么可能有人只是在欺骗标题。主机欺骗是检查漏洞的常用策略

您可以完全通过拒绝除服务器负责之外的任何内容来防止这些问题：

if ($host !~* ^(example.com|classes.example.com|www.example.com)$) {
        return 444;
}