Sec-GPC 请求头如今无处不在：面向分析的服务端检测
Global Privacy Control 以 Sec-GPC 请求头的形式随每个请求发送。本文讲解如何在边缘读取它，并在无 Cookie 的分析管道中予以尊重。
Global Privacy Control（GPC）常被当作一种法律信号来讨论，但对工程师而言，它首先是一个 HTTP 请求头。来自启用了 GPC 的浏览器或扩展的每个请求都会带上 Sec-GPC: 1，同一偏好也通过 navigator.globalPrivacyControl 暴露给客户端 JavaScript。如果你在边缘运行分析，这个请求头就是更干净的集成点——你可以在任何测量逻辑运行之前就据此行动，而无需下发一个字节的追踪代码。
这个信号究竟是什么样子
GPC 规范定义了一个请求头字段 Sec-GPC，其唯一有意义的值是 1，表示用户不同意出售或共享自己的个人数据。请求头缺失意味着用户没有表达任何偏好——这明确不等同于一个肯定的 0。规范还定义了一个位于 /.well-known/gpc.json 的知名资源，站点可以发布它来声明自己尊重该信号。
由于 Sec-GPC 使用 Sec- 前缀，它属于被禁止的请求头名称：无法通过 fetch() 或 XMLHttpRequest 设置或覆盖，因此比自定义请求头更难从页面脚本伪造。它在导航请求和子资源请求中都会发送，所以边缘 Worker 在第一次访问时就能看到它。
在 Cloudflare 边缘读取它
在 Cloudflare Worker 中，这项检查只需一行，并且在你决定是否记录任何内容之前就会执行：
export default {
async fetch(request) {
const gpc = request.headers.get('Sec-GPC') === '1';
// gpc === true -> 用户拒绝了数据的出售/共享
// 据此仅记录对隐私安全的聚合信号
return handle(request, { gpc });
}
};
对 Monoid 来说，这与产品既有的工作方式直接对应。Monoid 不存储 Cookie、不使用 localStorage，也不推导任何指纹，因此根本不存在需要抑制的跨站画像。GPC 是对个人数据出售与共享的一种法律层面的拒绝——而隐私优先、无 Cookie 的设计从来不会涉及这类行为。因此，检测 Sec-GPC 成为一项纵深防御措施，以及偏好确已被遵守的可审计记录，而不是一个改变哪些数据离开浏览器的开关。
简要说明法律上的意义
GPC 的可执行性并非纸上谈兵。2022 年加州总检察长与 Sephora 达成的和解明确表明，CCPA 要求企业将 GPC 视为有效的拒绝出售表示，而《加州隐私权法案》（CPRA）的实施细则要求尊重拒绝偏好信号。科罗拉多州和其他美国州级法规也采纳了类似的通用拒绝机制要求。在服务端读取请求头，为你提供了一个确定的、可记录的合规发生点——远比依赖标签管理器触发某条规则来得可靠。
发布知名资源
如果你尊重 GPC，就把它声明出来。用一个很小的文档提供 /.well-known/gpc.json：
{ "gpc": true, "lastUpdate": "2026-07-19" }
这是一个静态文件，你可以在边缘路由中以 Content-Type: application/json 返回。它向浏览器、扩展和审计方表明该偏好受到尊重，而维护成本为零。
分析管道的实用建议
- 在测量之前检查请求头，而不是之后。 在边缘行动意味着决策发生在任何下游处理之前。
- 不要把缺失当作同意。 没有
Sec-GPC请求头只意味着没有表达偏好；请与你现有的合法性基础结合判断。 - 保留最小化的审计记录。 记录某个请求带有
Sec-GPC: 1——且不将其与任何标识符关联——即可证明善意，又不会形成画像。 - 做门控时优先用请求头而非 JS API。
navigator.globalPrivacyControl属性对客户端界面很有用，但请求头让你在代码运行之前就能做出决定。
更普遍的启示是：隐私信号正日益成为传输层的事实，而非应用层的怪癖。Sec-GPC 与 DNT（已弃用）、Permissions-Policy 请求头和 Referrer-Policy 并列，都属于分析系统应当读取而非忽略的东西。对于无 Cookie 的产品而言，改动之所以很小，正是因为其架构本就在最小化数据——而这正是从一开始就这样构建的意义所在。
Comments
Loading comments…