Chrome 第三方 Cookie 淘汰在即：OSS 静态资源跨站 Cookie 问题排查与修复指南

一、问题回顾：一张图片引发的 Cookie 警告

典型场景复现

你的网站 weguiding.com 使用了阿里云 OSS 存放图片，图片 URL 类似：

https://blogweguiding.oss-cn-qingdao.aliyuncs.com/xxx.png?x-oss-process=image/resize,w_700,limit_1/format,webp

当 Chrome 加载这张图片时，DevTools Issues 面板检测到：

关键问题：当前网站是 weguiding.com，而 Cookie 属于 aliyuncs.com，两者不同源。Chrome 将这类 Cookie 视为 第三方 Cookie。

为什么会这样？

阿里云 OSS 在特定情况下（如通过某些 CDN 或自定义域名回源配置不当）可能会：

• 将客户端请求中的 Cookie 头转发到 OSS

• OSS 或中间代理意外设置了 Set-Cookie 响应头

• 浏览器之前访问其他阿里系站点时留下的 Cookie 被自动携带到 OSS 请求中

对于公开的静态资源（如图片、字体、样式表），Cookie 是完全没有必要的，它们不需要鉴权，也不需要跟踪用户状态。

二、为什么要重视这个问题？

1. Chrome 第三方 Cookie 淘汰时间线

Google 已明确推进 Privacy Sandbox 计划：

届时，任何跨站请求携带的 Cookie 都将被 Chrome 默认阻止。

2. 对你网站的实际影响

• 图片/静态资源加载失败：如果 OSS 资源依赖 Cookie 做鉴权或重定向，将直接 403/404

• 用户追踪数据丢失：第三方 Cookie 被拦截后，跨站追踪无法工作

• SEO 排名受损：搜索引擎（尤其是 Google）会评估网站的技术健康度

• 用户体验下降：控制台报错、图片加载失败，影响品牌形象

三、如何排查：定位你网站上的第三方 Cookie 问题

步骤 1：打开 Chrome DevTools

按 F12 或右键“检查”。

步骤 2：切换到 Issues 面板

点击 >> 展开更多标签，找到 Issues。

步骤 3：查看具体警告

展开 Cookie 类型的问题，会列出：

• 哪些请求携带了第三方 Cookie

• 涉及的具体 Cookie 名称

• 请求的完整 URL

步骤 4：验证 Cookie 来源

在 Application → Cookies 中，按域名查看所有 Cookie，确认哪些是阿里系（aliyuncs.com、taobao.com 等）留下的。

步骤 5：检查请求头

在 Network 面板中找到对应的资源请求，查看：

• Request Headers 中是否带有 Cookie 字段

• Response Headers 中是否带有 Set-Cookie

四、优化方案：彻底解决 OSS 资源第三方 Cookie 问题

方案一：CDN/反向代理层去除 Cookie（推荐 ★★★★★）

如果你使用了 CDN（如阿里云 CDN、CloudFlare、CloudFront），可以在 CDN 配置中主动移除请求头和响应头中的 Cookie。

阿里云 CDN 示例配置：

1. 进入 CDN 域名管理

2. 找到 回源请求头配置

3. 添加规则：删除 Cookie 请求头

4. 在 响应头配置 中：删除 Set-Cookie 响应头

CloudFlare 规则示例：

移除请求头: Cookie
移除响应头: Set-Cookie

Nginx 反向代理配置（如自建 CDN）：

location /static/ {
    proxy_pass https://your-oss-bucket.oss-cn-qingdao.aliyuncs.com/;
    proxy_set_header Cookie "";
    proxy_hide_header Set-Cookie;
}

方案二：OSS 公开资源使用独立域名并关闭 Cookie

1. 为 OSS 绑定一个独立的自定义域名（如 cdn.weguiding.com）

2. 确保该域名不与主站共享 Cookie（即主站的 Cookie 域不包含 .weguiding.com）

3. 在 OSS 控制台将该 Bucket 设置为公共读

4. 确认回源链路中没有 Set-Cookie 产生

方案三：使用主站同源反向代理（最彻底）

将 OSS 资源通过主站 weguiding.com 的同源路径代理：

https://weguiding.com/static/xxx.png?x-oss-process=image/resize,w_700,limit_1/format,webp → 内部转发到 OSS

Nginx 配置示例：

location /static/ {
    proxy_pass https://blogweguiding.oss-cn-qingdao.aliyuncs.com/;
    proxy_set_header Host blogweguiding.oss-cn-qingdao.aliyuncs.com;
    proxy_set_header Cookie "";
    proxy_hide_header Set-Cookie;
    proxy_hide_header Access-Control-Allow-Origin;
    add_header Cache-Control "public, max-age=31536000";
}

优点：

• Cookie 变为第一方，不受第三方限制

• 统一域名，便于管理和 SEO

方案四：设置 SameSite 属性（临时方案）

如果短期内无法更改架构，可以尝试将 Cookie 设置为：

Set-Cookie: name=value; SameSite=None; Secure

注意：

• 需要同时设置 Secure（仅 HTTPS）

• 用户仍可在 Chrome 中完全禁用第三方 Cookie

• 不是长期解决方案

五、验证优化效果

修复后，按以下步骤验证：

1. 清除浏览器缓存和 Cookie

2. 重新访问网站

3. 打开 DevTools → Issues，确认没有第三方 Cookie 警告

4. 在 Network 面板中随机检查几个静态资源请求，确认 Request Headers 中没有 Cookie 字段

六、补充建议：Issues 面板其他问题的排查

除了第三方 Cookie，Issues 面板还可能提示：

建议定期检查 Issues 面板，保持面板干净无报错。

七、总结：核心行动清单

记住一句话：公开的静态资源不应该携带任何 Cookie。这不仅是兼容 Chrome 淘汰第三方 Cookie 的需要，更是 Web 安全和性能优化的最佳实践。