配置Nginx default_server后仍频繁出现Django Invalid HTTP_HOST错误，求助排查原因

我来帮你梳理几个实用的排查方向，这种情况大概率是有请求没被你的default_server正确拦截，才会跑到Django那里触发错误：

• 先确认Nginx配置是否真正生效
  先跑一遍nginx -t检查配置语法有没有错误，再执行nginx -s reload（或者你之前用的restart）确认配置重载成功。另外可以查看Nginx的error.log（一般路径是/var/log/nginx/error.log），看看启动或重载时有没有报错——有时候配置语法没问题，但实际加载时会出现端口冲突、证书路径错误之类的问题，导致default_server没正常工作。

• 查看Django错误日志里的具体无效HOST值
  Django的错误信息里会明确显示触发错误的HTTP_HOST内容，比如是服务器IP、某个未配置的域名，还是带端口的地址？知道这个能精准定位问题：

  • 如果是IP地址：检查你的default_server的listen指令有没有覆盖所有IP（默认是0.0.0.0，但如果手动指定了某个IP，可能漏掉其他网卡的IP）；另外看看有没有其他server块监听了服务器的具体IP，优先拦截了IP请求。
  • 如果是某个未配置的域名：排查所有sites-available里的配置，看看有没有server块用了server_name _;（下划线是特殊匹配规则，会接收所有Host的请求），或者用了通配符（比如*.example.com）刚好匹配了这个无效域名，导致请求没走到default_server。

• 核对Nginx的server块匹配优先级
  Nginx匹配server的规则是：精确匹配 > 最长通配符前缀 > 最长通配符后缀 > 正则表达式（按定义顺序），而default_server是当请求的Host不匹配任何server_name时才会触发的兜底选项。如果有其他server块的server_name能匹配到那些无效Host的请求，default_server就不会生效。你可以把所有站点配置过一遍，排查这种情况。

• 确认端口监听和占用情况
  用netstat -tulpn | grep :80和netstat -tulpn | grep :443检查这两个端口是不是只有Nginx在监听。如果有其他服务（比如Apache、其他进程）也在监听，部分请求会绕过Nginx直接到Django，自然会触发错误。

• 检查正常站点的proxy配置
  虽然你说正常站点能工作，但可以看看它的proxy_pass相关配置有没有设置proxy_set_header Host $server_name;或者proxy_set_header Host $host;？如果没设置Host头，Nginx可能会把原始请求的Host（哪怕是无效的）传给Django——要是你的正常站点用了泛域名server_name，刚好匹配了无效Host，就会导致这种问题。

• 检查HTTP请求的处理逻辑
  你的default_server监听了80端口返回444，但看看有没有其他server块也监听了80端口？如果有的话，那些HTTP请求会被对应的server块处理，甚至proxy到Django，若请求的Host是无效的，就会触发Django的错误。确保所有未匹配的HTTP请求都走到default_server的80端口。

备注：内容来源于stack exchange，提问作者lessness