ECS上Django迁移异常：Admin登录提示user_user关系不存在

一、处理“relation user_user does not exist”错误 #

1. 验证migrate的数据库环境一致性 #

• 检查部署脚本中的DATABASES配置，确认是否指向目标RDS实例。很多时候脚本会默认使用本地SQLite，导致migrate操作的数据库和创建超级用户的RDS不是同一个，最终RDS中缺失user表。
• 在ECS服务器上执行python manage.py showmigrations auth（如果用了自定义User模型，替换为对应app名称），查看auth相关迁移是否已标记为[X]（已应用）。若存在未应用的迁移，手动执行python manage.py migrate auth补全。
• 确认创建超级用户的命令（python manage.py createsuperuser）和migrate命令使用的是同一虚拟环境、同一项目目录，避免环境隔离导致操作的数据库不一致。

2. 排查自定义User模型的迁移异常 #

• 若使用了自定义User模型，检查项目根目录下对应app的migrations文件，确认是否包含创建user_user表的完整逻辑。如果迁移文件缺失或损坏，可删除RDS中django_migrations表内该app的迁移记录，然后重新执行python manage.py makemigrations和python manage.py migrate（操作前务必备份数据库）。

二、解决ELB域名无法登录的问题 #

1. 配置HTTPS代理识别 #

• 若ELB启用了HTTPS，而ECS上的Django服务监听HTTP，需在settings.py中添加：

  SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
  

  让Django识别ELB传递的HTTPS请求，避免重定向循环或会话丢失。

2. 修复会话与CSRF配置 #

• 设置SESSION_COOKIE_DOMAIN为ELB域名或泛域名（如.yourdomain.com），确保会话Cookie能在ELB域名下正常生效：

  SESSION_COOKIE_DOMAIN = 'your-elb-domain.com'
  

• 将ELB域名加入CSRF_TRUSTED_ORIGINS，避免CSRF验证失败导致登录被拒绝：

  CSRF_TRUSTED_ORIGINS = ['https://your-elb-domain.com']
  

3. 检查请求路由配置 #

• 确认ELB的监听规则是否正确将请求转发到ECS的Django服务端口（默认8000）。若使用Nginx作为反向代理，检查Nginx配置是否正确转发Admin路径的请求，避免静态文件或登录请求被拦截。

内容的提问来源于stack exchange，提问作者Rohan Abraham