React生产构建后与HTTP Express API的Cookie交互异常问题

核心触发根因 #

• 现代浏览器跨站Cookie强制规则和你的纯HTTP跨IP部署场景完全不兼容
  Chrome 80之后上线的跨站Cookie安全规则，对非同源场景的Cookie设置了硬性拦截要求：
  • 只要判定为跨站请求，后端下发的Cookie必须显式配置sameSite: 'None'
  • 一旦设置sameSite: 'None'，所有现代浏览器强制要求该Cookie必须同时开启secure: true属性，也就是必须走HTTPS加密传输才会被接受
    你的部署链路是纯HTTP的IP访问，根本不满足secure: true的前置要求，只要触发跨站判定，浏览器会直接丢弃后端返回的Set-Cookie响应头，既不存储Cookie，后续请求也不会自动携带。

  这也是为什么开发环境功能完全正常：React dev server默认跑在localhost源下，浏览器对localhost地址存在特殊的安全规则豁免，不会将其判定为跨站，默认的sameSite: Lax配置可以正常跑通鉴权流程。但生产构建后如果前端托管在非localhost源（比如本地静态服务、file协议直接打开文件、其他独立IP源），就会被判定为跨站，直接触发上述拦截逻辑。

• 后端Cookie下发逻辑缺失必要配置
  你当前的res.cookie('auth', {token: token, name: user.name}).send('OK')没有传入任何配置项，在跨源生产场景下会踩中多个拦截点：
  • 未显式指定domain属性：浏览器会默认将Cookie的作用域绑定到后端IP源，跨源场景下如果出现IP/域名不匹配，会直接判定Cookie非法并丢弃
  • 未匹配跨源场景的sameSite配置：默认的Lax属性在跨站请求下，既不允许跨源下发Cookie，也不允许后续请求自动携带
  • 未显式设置httpOnly属性：虽然不会直接阻止Cookie下发，但如果Cookie可被前端JS直接篡改，部分浏览器的安全策略会将其标记为非可信内容拦截。

次级触发根因 #

• CORS动态配置在生产场景失效
  你配置的cors({origin: true, credentials: true})逻辑是将请求头中的Origin值原样返回，这种配置在生产场景下存在明显漏洞：
  • 如果前端是通过file://协议直接打开构建后的静态文件，请求的Origin值为null，动态返回的Origin会变成null，而带凭证的CORS流程明确不允许返回Access-Control-Allow-Origin: null，会直接触发CORS拦截，浏览器会无视所有后端返回的响应内容，自然也不会保存Cookie
  • 如果Express服务前面套了Nginx等反向代理，代理默认会过滤掉Access-Control-Allow-Credentials响应头，导致浏览器判定为不允许跨源携带凭证，直接中断Cookie流程。
• 生产构建过程的配置覆盖
  部分项目的生产构建流程会通过环境变量动态修改axios配置，如果出现配置漏写，会直接将withCredentials设置为false，导致请求即使有已存储的Cookie也不会自动携带。

可落地的排查步骤 #

• 打开浏览器开发者工具的网络面板，定位登录接口的响应内容做逐类排查：
  • 如果响应头中完全找不到Set-Cookie字段：先检查Express运行日志，确认res.cookie的调用逻辑是否正常执行，再排查反向代理层是否意外过滤了响应头
  • 如果存在Set-Cookie字段，但浏览器「应用-存储-Cookie」面板中没有对应记录：100%是浏览器跨站Cookie规则拦截，你的纯HTTP跨IP部署场景本来就满足不了跨站Cookie的HTTPS强制要求，要么给后端配置域名开启HTTPS，要么把前端和API部署在同一个源下，通过反向代理转发接口请求，从根源上消除跨站判定
  • 如果Cookie可以正常存储，但后续接口请求没有携带：先检查生产构建后的axios配置，确认withCredentials是否被正确设置为true，再核对CORS响应头是否正确返回Access-Control-Allow-Credentials: true

纯HTTP、非同源跨IP的场景，在当前的浏览器安全规则下，本来就不支持跨域Cookie鉴权，这也是开发环境和生产环境表现差异巨大的核心原因。

内容的提问来源于stack exchange，提问作者Taner Tunçer