部署Django到AWS Fargate：添加本地IP至ALLOWED_HOSTS解决健康检查错误

我之前也碰到过一模一样的坑！当AWS Fargate里的Django应用收到ALB的健康检查请求时，ALB会用容器所在主机的本地私有IP（比如你日志里的172.31.86.159）发送请求，而这个IP是Fargate动态分配的，每次任务重启都会变——手动加肯定不现实，你尝试启动时获取IP的方法大概率因为容器网络初始化的延迟没生效，毕竟Fargate给容器分配IP需要几秒时间，可能脚本执行时IP还没到位。

下面给你几个靠谱的解决方案，按推荐程度排序：

方案1：利用ALB转发头信任合法请求（最省心安全） #

AWS ALB会把真实的请求Host头放到X-Forwarded-Host里，我们只需要让Django信任这个转发头，同时把对外的域名（或ALB域名）加到ALLOWED_HOSTS即可，完全不用管私有IP：

• 在settings.py里做以下配置：

  # 信任ALB所在VPC的IP段（生产环境建议写具体CIDR，比如你的VPC是172.31.0.0/16）
  TRUSTED_PROXIES = ['172.31.0.0/16']
  # 测试阶段可以临时用'*'，但生产环境一定要改回具体CIDR
  
  # 启用转发头支持
  USE_X_FORWARDED_HOST = True
  SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')  # 如果你用HTTPS的话
  
  # 只需要加对外的域名/ALB域名
  ALLOWED_HOSTS = ['your-public-domain.com', 'your-alb-xxxxxx.elb.amazonaws.com']
  
  # 中间件顺序要注意，确保SecurityMiddleware在前面
  MIDDLEWARE = [
      'django.middleware.security.SecurityMiddleware',
      'django.middleware.common.CommonMiddleware',
      # 其他中间件保持不变...
  ]
  

• 原理：Django会优先用X-Forwarded-Host来验证ALLOWED_HOSTS，而不是ALB发送请求的私有IP，完美绕过动态IP的问题。

方案2：动态获取容器IP并注入ALLOWED_HOSTS（适合特殊场景） #

如果因为某些限制必须让Django接受私有IP，那可以写个启动脚本，等容器IP分配完成后再启动应用：

• 先写一个start.sh启动脚本：

  # 等待容器IP分配完成
  CONTAINER_IP=""
  while [ -z "$CONTAINER_IP" ]; do
      sleep 1
      CONTAINER_IP=$(hostname -i)
  done
  
  # 把IP和固定域名一起注入环境变量
  export DJANGO_ALLOWED_HOSTS="your-public-domain.com,${CONTAINER_IP}"
  
  # 启动Django应用（这里用gunicorn举例，你可以换成自己的启动命令）
  gunicorn your_project.wsgi:application --bind 0.0.0.0:8000
  

• 然后在settings.py里读取环境变量：

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

• 注意：要确保你的Dockerfile里把这个脚本设为启动命令，而不是直接启动gunicorn。

方案3：修改ALB健康检查的Host头（快速测试方案） #

你也可以直接让ALB发送健康检查时用指定的Host头，这样Django只需要信任这个域名就行：

• 操作步骤：
  1. 打开AWS EC2控制台，找到你的ALB对应的目标组
  2. 点击「编辑健康检查」
  3. 拉到「高级健康检查设置」，添加自定义HTTP头：Host: your-public-domain.com
  4. 保存配置，等待健康检查更新

这样ALB发送健康检查请求时就会用你指定的Host头，不会再触发ALLOWED_HOSTS错误。

我个人最推荐方案1，因为它从根源上解决了问题，不需要处理动态IP的麻烦，也符合生产环境的安全规范。

内容的提问来源于stack exchange，提问作者AJ Venturella