部署Django至AWS EC2时反复出现DisallowedHost错误求助

一、排查DisallowedHost错误的核心原因 #

1. 确认settings.py的实际生效版本 #

你在GitHub修改settings.py后，执行git pull origin master确实能拉取更新到EC2，但必须确保操作的是当前运行的Django项目所在目录。很多新手会误在错误文件夹执行git命令，导致代码未更新。

• 验证方法：在EC2上直接查看项目的settings.py内容，执行cat /path/to/your/project/settings.py，确认ALLOWED_HOSTS是否为你设置的['3.17.142.65', 'localhost', '127.0.0.1']。如果不是，说明git pull未生效，检查当前目录是否正确，或是否存在本地修改冲突（git会主动提示冲突信息）。

2. 检查Gunicorn是否加载了正确的settings模块 #

如果启动Gunicorn时指定了settings文件（比如gunicorn --settings=myproject.settings ...），要确保路径正确；若未指定，默认会加载项目根目录的settings.py，但虚拟环境配置错误可能导致加载异常。

• 重启Gunicorn后，查看日志确认配置加载情况：执行journalctl -u gunicorn，或查看/var/log/gunicorn/下的日志文件，确认ALLOWED_HOSTS的实际生效值。

3. Nginx proxy_params配置检查 #

你的Nginx配置中使用了include proxy_params;，该文件通常位于/etc/nginx/proxy_params，其中必须包含proxy_set_header Host $http_host;或proxy_set_header Host $host;，否则无法正确将客户端请求的Host头传递给Django。

• 检查文件内容：执行cat /etc/nginx/proxy_params，若缺少上述配置，手动添加后重启Nginx。

4. 确认是否使用多环境配置文件 #

部分Django项目会拆分开发/生产配置（比如settings/prod.py），如果Gunicorn或WSGI配置指向的是prod.py而非你修改的主settings.py，那么修改主文件不会生效。

• 检查wsgi.py文件：查看其中的os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings.prod")语句，确认指向的是你修改的配置文件。

二、关于git pull的疑问 #

是的，在EC2的项目目录下执行git pull origin master会拉取GitHub上的最新代码，但需满足以下前提：

• 本地目录无未提交的修改（若有，git会拒绝拉取，需先执行git stash暂存或提交修改）。
• GitHub的master分支确实已更新为你修改后的版本（登录GitHub确认settings.py内容）。
• 拉取后必须重启Gunicorn（Django会缓存settings配置，重启才会加载新配置），你当前的操作步骤是正确的。

三、新手部署额外检查项 #

• 虚拟环境验证：确认Gunicorn运行时使用的是项目对应的虚拟环境，避免全局Django版本与虚拟环境版本不一致导致的配置加载异常。启动Gunicorn时可指定虚拟环境的Python路径，比如/home/ubuntu/venv/bin/gunicorn ...。
• 清理Django缓存：执行python manage.py clearcache（Django 4.2及以上版本），或删除项目根目录下的__pycache__文件夹，避免缓存旧的settings配置。

内容的提问来源于stack exchange，提问作者Rahul Verma