本质是浏览器拒绝存储或发送cookie，需同步验证响应头是否含secure/httponly/samesite、https上下文是否全程可信（证书有效、x-forwarded-proto透传）、samesite值是否匹配业务场景（lax适单域、none须配secure且仅限https）。
HTTPS状态下Cookie丢失或SameSite配置错误，本质是浏览器拒绝存储或发送Cookie，不是后端没发，而是前端环境“不认”。排查要从响应头、协议一致性、浏览器策略三方面同步验证。
看响应头是否真正生效
打开浏览器开发者工具 → Network → 找到登录或设置会话的请求 → 点击响应 → 查看Response Headers里的Set-Cookie字段：
- 必须看到Secure、HttpOnly、SameSite=xxx（Lax/Strict/None）完整出现在同一行；
- 如果只看到Path=/; Expires=...等基础属性，说明Nginx未成功注入安全参数；
- 若出现SameSite=None但没有Secure，Chrome会直接标黄警告并丢弃该Cookie；
- 注意：add_header Set-Cookie仅对Nginx自身生成的响应头有效，对后端返回的Set-Cookie无效——此时必须用proxy_cookie_path或proxy_cookie_flags。
确认HTTPS上下文是否全程可信
哪怕页面地址栏显示https://，也不代表浏览器认为这是“安全上下文”：
- 检查地址栏是否有锁形图标，点击查看证书是否有效（自签名证书需手动信任，否则浏览器不认可Secure）；
- 确保Nginx配置中listen 443 ssl开启，并正确加载了证书和私钥；
- 验证X-Forwarded-Proto头是否被正确透传：如果Nginx前还有CDN或WAF，需确保它们把X-Forwarded-Proto: https带过来，否则后端可能误判为HTTP而不敢加Secure；
- 本地开发用https://localhost时，不能依赖自签名证书+HTTP混合访问——任何一次HTTP跳转（如重定向、资源加载）都可能导致Secure Cookie被浏览器拒绝写入。
比对SameSite值与业务场景是否匹配
SameSite不是越严格越好，选错会导致功能异常：
- SameSite=Lax：适合大多数单域名应用。用户从外部链接点击进入首页（GET导航）能携带Cookie，但表单提交（POST）、iframe嵌入、AJAX跨域请求不会带。登录后跳转首页不失效，但跨子域API调用会失败；
- SameSite=Strict：几乎禁止所有跨站交互。用户从微信点击链接进网站，首次请求就拿不到登录态，体验极差；
- SameSite=None：唯一支持跨域携带Cookie的选项，但强制要求搭配Secure且只能用于HTTPS。前后端分离部署（如前端a.com、后端api.b.com）、OAuth跳转、嵌入式微应用必须用这个；
- 特别注意：Chrome 80+对未声明SameSite的Cookie默认按Lax处理，所以即使后端没设，也可能因隐式策略被拦截——务必显式声明，不要依赖默认。
快速验证是否修复成功
改完Nginx配置后，别只信日志或curl，用真实浏览器验证：
- 清空浏览器所有相关Cookie和缓存；
- 重新登录，立即在Application → Cookies里检查目标域名下是否存在对应Cookie，并确认其属性列明确显示Secure、HttpOnly、SameSite值；
- 刷新页面，观察Network中后续请求的Request Headers是否自动带上Cookie；
- 尝试跨站操作（如新开Tab访问另一个域名再跳回来），看会话是否持续；
- 用curl -I模拟请求时，注意它不解析SameSite逻辑，不能代替浏览器验证。
