Next.js+Express项目本地正常生产环境Cookie设置失效排查

AI 小北

2026-8-26

生产环境Cookie写入失败根因

本地localhost环境能正常设置Cookie、生产环境失效，本质是浏览器对localhost和普通公网域名的安全校验规则、格式容错度完全不同，结合贴出的代码，问题基本集中在以下几点：

手动给Cookie值拼接了非法分号：代码里写的result.token + ';'、result.username + ';'属于典型的格式错误。Express的res.cookie方法会自动按照HTTP规范拼接Cookie的属性分隔符，手动在value末尾加的分号会直接破坏Set-Cookie头的语法结构。本地环境因为浏览器对localhost域的Cookie格式校验宽松，会自动忽略非法字符正常写入；公网环境下严格遵循RFC规范，遇到格式非法的Set-Cookie头会直接丢弃，不会写入存储。
Secure属性的环境差异：给Cookie配置了secure: true，这个属性要求Cookie只能在HTTPS加密上下文下传输、写入。现代浏览器默认给localhost做了安全豁免，哪怕本地用HTTP访问，secure:true的Cookie也能正常存；公网域名下如果服务没配HTTPS、或者页面/接口混用HTTP请求，浏览器会直接拦截所有带secure标记的Cookie，不会写入。
CORS配置不匹配：前后端同域名不同端口在浏览器同源规则里属于跨源请求，前端虽然开了withCredentials: true，如果后端CORS中间件没有同步配置credentials: true、或者origin配置成了通配符*，浏览器会在跨域校验阶段直接拦截Set-Cookie头，不会执行写入操作。本地开发时多数场景会用Next.js的rewrite做接口代理，绕开了跨域校验，所以不会触发这个问题。
反向代理配置干扰：在DigitalOcean部署如果用了Nginx之类的反向代理分发两个端口的流量，要检查代理规则有没有自动覆盖、修改Set-Cookie头的属性，比如错误的路径重写、Secure属性剥离，都会导致Cookie最终格式不符合浏览器要求。

修复步骤

第一步先删掉Cookie值里多余的分号拼接，直接传原始值即可，记得显式加上path配置避免路径匹配问题，修正后的代码片段：

res.cookie("auth-token", result.token, {
    secure: true,
    httpOnly: true,
    expires: new Date(new Date().getTime() + (1000 * 60 * 60 * 24 * 7)),
    sameSite: "none",
    domain: ".xxxx.com",
    path: "/"
}).cookie("username", result.username, {
    secure: true,
    httpOnly: true,
    expires: new Date(new Date().getTime() + (1000 * 60 * 60 * 24 * 7)),
    sameSite: "none",
    domain: ".xxxx.com",
    path: "/"
}).send(new BaseResponse(result, true));

确认生产环境全站配置有效HTTPS，前端页面、接口请求全部走https://协议，禁止HTTP/HTTPS混合访问。如果临时测试没有HTTPS，可以把secure暂时设为false，但正式环境必须开启，配合HTTPS避免Cookie被窃听。
检查后端CORS配置，禁止把origin设为通配符*，必须明确指定前端的实际访问源，同时开启credentials允许携带凭证，参考配置：

const cors = require('cors');
app.use(cors({
  origin: "https://你的前端访问完整域名",
  credentials: true
}))

打开浏览器DevTools的Network面板，找到登录接口的响应头，查看原始Set-Cookie内容，确认没有多余字符、所有属性拼写正确，SameSite=None必须和Secure属性同时出现，缺一个浏览器都会拒绝存储。
如果用了Nginx反向代理，检查是否有错误的头修改规则，必要时可以加显式配置透传后端返回的Set-Cookie头，不要做额外修改。

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