部署AWS Fargate后Django Admin CSRF失败：Nginx与Django配置方案

这种情况我之前在部署Django到AWS Fargate时也碰到过，核心问题就是负载均衡器和Nginx没把用户真实的请求信息（协议、主机、端口）正确传递给Django，导致Django生成的CSRF校验信息和实际请求不匹配，自然就报错了。下面分两步调整配置就能解决：

一、修改Nginx配置，传递真实请求信息 #

在你的Nginx配置文件（比如/etc/nginx/conf.d/default.conf）的server块里，给location /添加以下请求头配置，确保把负载均衡器过来的真实请求参数转发给Gunicorn：

server {
    listen 80;
    server_name your-domain.com; # 替换成你的实际域名

    location / {
        proxy_pass http://gunicorn:8000; # 这里对应你docker-compose里Gunicorn的服务地址，按需调整
        # 关键配置：传递真实的请求来源信息
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Port $server_port;
        # 确保Host头正确传递，避免Django识别错误
        proxy_set_header Host $host;
    }
}

这些X-Forwarded-*头的作用是告诉Django：用户实际访问的协议（HTTP/HTTPS）、主机名、端口是什么，而不是容器内部的本地地址。

二、修改Django的settings.py配置 #

接下来要让Django信任这些转发过来的请求头，并基于这些信息生成正确的CSRF校验内容：

1. 配置代理信任与协议识别 #

在settings.py中添加或修改以下配置：

# 允许访问的主机，添加你的域名和负载均衡器地址
ALLOWED_HOSTS = ['your-domain.com', 'load-balancer-xxx.elb.amazonaws.com']

# 开启对X-Forwarded-*头的支持
USE_X_FORWARDED_HOST = True
# 告诉Django通过X-Forwarded-Proto头判断请求是否为HTTPS（如果负载均衡器做了HTTPS终止）
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

# 如果你的负载均衡器用的是HTTPS，建议开启这两个选项，提升安全性
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True

2. 配置CSRF信任来源（Django 3.2+版本必填） #

对于Django 3.2及以上版本，需要明确配置CSRF_TRUSTED_ORIGINS，把用户实际访问的域名（带协议）加进去：

CSRF_TRUSTED_ORIGINS = ['https://your-domain.com', 'https://load-balancer-xxx.elb.amazonaws.com']

注意这里的协议要和用户实际访问的一致，如果负载均衡器用的是HTTP（不建议生产环境），就改成http://开头。

配置完成后，重新构建并推送你的容器到Fargate，再测试Django Admin登录，应该就不会再出现CSRF失败的异常了。

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