为什么Django 4.2版本部署到Nginx后丢Session_配置Python安全Cookie属性-Python教程-PHP中文网

必须配置 Nginx 透传 HTTPS 协议头并启用 Django 的 SECURE_PROXY_SSL_HEADER，否则 SESSION_COOKIE_SECURE=True 会导致 Cookie 不被设置；因 Django 收到的是 HTTP 请求，无法识别外部 HTTPS，从而静默跳过写入 sessionid。

为什么django 4.2版本部署到nginx后丢session_配置python安全cookie属性

因为 Django 4.2 默认启用 SAMESITE=Lax，而 Nginx 反向代理时若未透传 HTTPS 头、或前端域名与后端不一致，会导致浏览器拒绝发送 Session Cookie，从而“丢 session”。

为什么 `SESSION_COOKIE_SECURE=True` 在 Nginx 下必须配合真实 HTTPS

Django 4.2+ 要求：当 SESSION_COOKIE_SECURE=True 时，只有在 HTTPS 请求中才会设置和发送 Cookie。但很多部署场景里，Nginx 是 HTTPS 终结点（即用户走 HTTPS 访问 Nginx，Nginx 再以 HTTP 转发给 Django），此时 Django 收到的是纯 HTTP 请求 —— 它不知道外面是 HTTPS，于是直接跳过写入 sessionid Cookie。

必须在 Nginx 配置中显式传递协议信息：proxy_set_header X-Forwarded-Proto $scheme;
并在 Django settings.py 中启用信任：SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
漏掉任一环，SESSION_COOKIE_SECURE=True 就会静默失效，浏览器收不到 Cookie

`SESSION_COOKIE_SAMESITE` 设为 `None` 时的硬性要求

如果业务需要跨子域共享登录态（比如 app.example.com 和 api.example.com），你可能会设 SESSION_COOKIE_SAMESITE='None'。但 Chrome 80+、Firefox 79+、Safari 13.1+ 会强制拦截这种 Cookie，除非同时满足：

SESSION_COOKIE_SECURE=True（必须）
Nginx 确实终止了 HTTPS（不能只配 proxy_pass http://…）
SESSION_COOKIE_DOMAIN='.example.com'（注意开头的点，表示包含所有子域）
前端请求头中 credentials: 'include' 已启用（Fetch API）或 withCredentials=true（XMLHttpRequest）

任意一项缺失，浏览器控制台会报 Cookie “sessionid” has been rejected because it is in a cross-site context and its “SameSite” value is “None”。

`ALLOWED_HOSTS` 和 `SESSION_COOKIE_DOMAIN` 不匹配的连锁反应

常见误配：ALLOWED_HOSTS = ['example.com']，但 SESSION_COOKIE_DOMAIN = '.example.com'。这会导致：

361SCAN security check your skill python scripts

扫描并分析已安装技能，用于查看指定技能目录的名称、描述和详情，或列出所有已安装的技能。

下载

Django 接收请求时检查 Host 头，只认 example.com，拒绝 www.example.com 或 api.example.com
即使 Cookie 写进去了，后续请求因 Host 不在白名单而被 400 拦截，根本到不了 Session 中间件
更隐蔽的问题：Django 日志里可能只记 Bad Request (400)，不提示具体原因

建议统一用带点的通配：ALLOWED_HOSTS = ['.example.com']，并确保 DNS 解析和 Nginx server_name 也覆盖全部子域。

Nginx 缓存或代理头污染导致 Cookie 丢失

有些 Nginx 配置会无意中覆盖或清空关键响应头：

proxy_hide_header Set-Cookie; —— 这行会让 Nginx 直接吞掉 Django 返回的 Set-Cookie，Session 彻底不可见
proxy_buffering on; + 大响应体 —— 可能延迟甚至截断含 Set-Cookie 的响应头
未配置 proxy_cookie_path / "/"; 或 proxy_cookie_domain off; —— 当 Nginx 做路径重写（如把 /api/ 代理到后端根路径），Cookie 的 Path 可能被错写成 /api/，导致后续请求不携带

最简验证法：curl -I https://yourdomain.com/login，看响应头是否含 Set-Cookie: sessionid=...。没有？问题一定出在 Nginx 层。

真正容易被忽略的点是：Django 的 Session 依赖链比表面看起来长得多 —— 从 Nginx 的 SSL 终结、Header 透传、Host 白名单，到 Cookie 的 Domain/SameSite/Secure 三属性协同生效，缺一不可。任何一个环节松动，表现都是“没登录”“反复跳登录页”，但错误日志里往往空空如也。