Djangoallowed_hosts配置解决400错误

Django在生产环境（DEBUG=False）下会严格校验HTTP请求头中的Host字段，若其值未明确列在ALLOWED_HOSTS配置中，将直接返回400 Bad Request错误——连视图层都未进入，这并非bug而是关键的安全防护机制，旨在抵御Host头攻击；因此必须显式、精确地配置可信域名或IP（如['example.com', 'www.example.com']），禁用通配符（包括'*'和子域名通配符），并通过环境变量动态加载以适配不同部署环境，同时警惕反向代理、CDN或云服务对Host头的篡改，稍有疏忽（如遗漏www变体、残留localhost、硬编码未更新）就会导致整个站点对合法用户返回神秘400，掌握这一配置逻辑是保障Django应用稳定上线的必备技能。

allowed_hosts配置错误直接导致400 Bad Request

Django在DEBUG=False时会严格校验请求头里的Host字段，如果不在ALLOWED_HOSTS里，就直接返回400，连视图都不会进。这不是bug，是安全机制——防止HTTP Host头攻击。

生产环境必须显式写全可接受的域名或IP

常见错误是留空、只写['*']（开发可以，生产不行），或漏掉带www的变体。Django不支持通配符子域名（比如'*.example.com'无效）。

• ALLOWED_HOSTS = ['example.com', 'www.example.com'] —— 最稳妥
• ALLOWED_HOSTS = ['192.168.1.100', 'localhost'] —— 本地测试或内网部署用
• ALLOWED_HOSTS = ['127.0.0.1', '[::1]'] —— 仅限本地调试，别上生产
• 反向代理（如Nginx）后，确保Host头没被篡改；必要时在Nginx加proxy_set_header Host $host;

用环境变量动态配，避免硬编码

硬写死域名会导致配置随环境变化要改代码。推荐从环境变量读取并拆分：

import os
ALLOWED_HOSTS = os.environ.get('DJANGO_ALLOWED_HOSTS', 'localhost').split(',')

然后启动时传：DJANGO_ALLOWED_HOSTS=example.com,www.example.com gunicorn myproject.wsgi。注意：空格会被当host一部分，别加。

• 环境变量值里不能有空格，逗号分隔即可
• 如果用Docker，确保env_file或-e正确注入，运行printenv DJANGO_ALLOWED_HOSTS验证
• 检查settings.py是否被多处加载（比如有base.py和prod.py），改错文件就白配

调试400时先确认是不是allowed_hosts惹的祸

日志里看不到详细原因，但有迹可循：请求没进视图、log里没有INFO "GET /..."记录、且DEBUG=False，基本就是它。

• 临时把DEBUG=True跑一下，如果400消失，基本锁定ALLOWED_HOSTS
• 用curl -H "Host: wrong.com" http://your-site/复现，确认是否匹配失败
• 检查Nginx/Apache有没有重写Host头，或者CDN透传了原始Host
• 云服务（如AWS ALB、Cloudflare）可能默认改Host，需查文档看是否需额外配置

最常被忽略的是：上线后忘了删掉localhost或127.0.0.1，结果线上用户用域名访问，而域名不在列表里——400就来了。

以上就是《Djangoallowed_hosts配置解决400错误》的详细内容，更多关于的资料请关注golang学习网公众号！