Docker-Compose更新文件失效，DEBUG=True不生效及CSRF问题求助

一、DEBUG=True不生效的原因及解决方法 #

原因 #

• 你的docker-compose.yml中server服务挂载了命名卷server:/server/，容器启动时会用卷内的持久化内容覆盖镜像构建阶段生成的/server/目录。你通过vi修改的是容器内临时文件，但卷的内容未更新，重建容器时仍会加载卷里的旧配置。
• docker system prune -af仅删除未被使用的卷，若该卷曾被容器使用过（即便容器已删除），卷会被保留，旧配置因此不会被清除。

解决方法 #

1. 修正本地宿主机的配置文件：确保AWS服务器上项目目录（📦server下的📂server/appserver/settings/deploy.py）内DEBUG=True配置正确。
2. 删除旧卷并重新构建：
   • 停止容器并删除关联卷：docker-compose down -v
   • 重新构建镜像并启动服务：docker-compose up --build
3. 优化卷挂载策略（可选）：若无需持久化整个/server/目录，仅挂载需要保留的文件（如db.sqlite3），避免覆盖代码文件。修改docker-compose.yml中server服务的volumes：

   volumes:
       - ./server/db.sqlite3:/server/db.sqlite3
       - tmp:/tmp/
   

   后续修改本地代码后，重新构建镜像即可直接生效。

二、仅django-admin出现CSRF 403 Forbidden的原因及解决方法 #

原因 #

1. CSRF_TRUSTED_ORIGINS配置无效：你配置的['http://-', 'https://-']是占位符，未填写实际访问的域名或EC2公网IP，导致Django无法识别合法请求来源。
2. CSRF_COOKIE_SECURE与当前协议不匹配：你设置了CSRF_COOKIE_SECURE=True，但当前使用HTTP协议（nginx映射80端口），浏览器会拒绝将带Secure标记的Cookie发送到HTTP站点，导致django-admin无法获取CSRF Token，验证失败。而API使用JWT认证无需CSRF验证，因此不受影响。

解决方法 #

1. 修正CSRF_TRUSTED_ORIGINS：替换为实际访问地址，例如：

   CSRF_TRUSTED_ORIGINS = ['http://你的EC2公网IP', 'http://你的域名']
   

2. 调整CSRF_COOKIE_SECURE配置：
   • 若用HTTP测试，将CSRF_COOKIE_SECURE=False；
   • 若启用HTTPS，配置nginx映射443端口并部署SSL证书，确保访问使用HTTPS协议。
3. 检查nginx请求头配置：确保nginx.conf包含以下内容，让Django能正确识别请求来源：

   location / {
       proxy_pass http://unix:/tmp/gunicorn.sock;
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
   }
   

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