Django修改SESSION_COOKIE_NAME后仅生产环境无法登录Admin的排查求助

结合你已完成的排查动作和观察到的现象（普通用户复用同一认证逻辑登录正常、新名称Cookie可正常下发、改回原配置即恢复登录、问题仅在生产环境复现），按排查优先级排序的方向如下：

一、定位Admin流程与普通用户认证的逻辑差异 #

全局认证链路对普通用户生效，问题必然出在Admin专属的独立分支逻辑中：

• 排查项目内引入的第三方Admin扩展（自定义权限组件、Admin安全加固插件、日志审计插件）是否存在硬编码读取旧SESSION_COOKIE_NAME的逻辑：这类插件通常在初始化阶段固化全局配置值，不会跟随动态配置更新，且仅对Admin路径的请求生效，不会影响普通业务用户的认证流程
• 排查针对/admin/路径配置的自定义中间件、登录装饰器：部分自定义校验逻辑会直接从request.COOKIES中按硬编码的旧会话名取值做合法性校验，没有走框架默认的request.session读取流程，普通用户请求不经过这段逻辑因此不受影响
• 排查反向代理层（Nginx）是否存在路径维度的Cookie处理规则：很多历史配置会专门为/admin/路径单独设置proxy_cookie_name替换、Cookie字段过滤规则，全局SESSION_COOKIE_NAME更新后，这类路径级规则仍会将新会话名替换为旧名下发，造成Cookie名称和校验逻辑不匹配

二、逐环节对比生产与本地/测试环境的配置差异 #

问题仅在生产复现，核心是定位生产独有的环境配置偏差：

• 验证多实例集群的配置一致性：检查是否存在部分应用节点仍加载旧的SESSION_COOKIE_NAME配置未更新，由于负载均衡策略，普通用户请求会散落到全量节点表现正常，而Admin登录的POST请求刚好命中未更新配置的旧节点，造成下发、校验Cookie名不匹配。可在每个节点的请求日志中打印当前生效的实际会话名配置，和请求携带的Cookie值做交叉对比
• 检查WAF、CDN的规则白名单：确认新的会话名是否在WAF的Cookie允许列表中，部分WAF规则会对/admin/路径的请求做严格的Cookie字段校验，不在白名单内的Cookie会被直接从请求头中剔除，导致应用读不到有效会话；普通业务路径的请求未触发该校验规则因此表现正常
• 检查Session存储层的读写逻辑：确认生产环境的Session存储（Redis/数据库）是否为Admin模块配置了独立的key前缀、读写库，这类独立配置是否仍绑定旧的会话名作为key生成规则，造成新Cookie写入的会话key和读取校验的key规则不匹配

三、全链路最小化验证定位问题点 #

在不影响线上业务的前提下，用最小成本锁定异常环节：

• 抓取全链路请求日志：从浏览器发起的Admin登录请求开始，逐环节记录Nginx转发的请求头、应用收到的Cookie值、应用返回的Set-Cookie头、应用查询Session存储时使用的key值，逐环节和预期值做对比
• 临时在Admin登录接口增加调试输出：跳过完整登录流程，直接将当前请求携带的全量Cookie、当前生效的SESSION_COOKIE_NAME配置值返回给前端，快速区分是代理层修改了Cookie、应用配置未生效、还是校验逻辑读取Cookie时取错了字段名
• 临时增加旧会话名的白名单适配：将旧的会话名加入应用可识别的Cookie列表，测试Admin是否可正常登录，若可登录则可确认存在某处逻辑强制读取旧会话名的值做校验

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