全部文章

2026年为什么 headless 浏览器会泄露更多特征

2026年,检测机制扩大了 headless 与正常浏览器会话之间的差异。如果在生产环境中运行 Puppeteer 或 Playwright,请提前规划应对检测成本。

Headless 不再隐蔽

七天前,cside 发布了关于 2026 年 headless 浏览器检测的技术分析。主线是:检测器现在能在像素级别捕获 headless 会话。相同的名义浏览器,相同的操作系统,不同的 WebGL 输出。不同的 AudioContext 计时。不同的字体枚举。虽然信号微弱,但足以一致地进行评分。

这篇文章发表于 WebDecoy 的 Browser Fingerprinting 2026 总结之后一周,后者通过不同的途径得出了相同的结论。Browserless (今年早些时候发布) 的 State of Web Scraping 2026 明确指出:headless 浏览器比用户驱动的浏览器更容易被标记,而且差距不断扩大。

如果你在生产环境中运行 Puppeteer 或 Playwright,这将改变你的成本曲线。

实际发生了什么变化

关于 headless 检测的旧说法是 navigator.webdriver === true、空的 plugins 数组以及 User-Agent 中的 HeadlessChrome。从 2020 年起的所有 stealth 插件都修补了这些问题。因此,检测器向下移动了技术栈。

软件渲染是一个重要因素。用户的浏览器会使用 GPU。在容器中运行的 headless 环境通常会回退到软件光栅化器。WebGL renderer 字符串读取结果不同。在相同的名义输入下,像素输出不同。Canvas 指纹在完全相同的输入下产生分歧。这些都不会触发布尔值检查,而是提供概率评分。

AudioContext 是第二个因素。当页面实例化音频上下文并请求采样率或通道数时,headless 环境的响应值与普通桌面会话有微妙的不同。相同操作的计时会发生可预测的漂移。

字体枚举是第三个因素。用户机器上有根据历史安装的字体。容器镜像只有精选的(且数量很少的)集合。当 fingerprinting 脚本测量 50 种字体中 100 个常见字符串的宽度时,缺失字体的模式就具有诊断意义。

其中任何一个都是微弱的信号。但结合起来,再加上检测器仍在检查的旧信号,它们汇总得出的分数足以高置信度地区分自动化会话和用户会话并采取行动。

为什么检测器现在增加投入

因为数据终于证明了研发预算的合理性。

F5 的 2026 Advanced Persistent Bot Report 指出,在应用了现有的 bot 缓解措施后,scraper 流量仍占全球网络流量的 10.2%。这就是残余量:防御者无法用现有工具将其降至零的份额。该份额的每一个增量点都值得去消除。

Cloudflare于7月13日发布了Precursor。Precursor持续收集客户端行为信号(指针移动,键盘计时,焦点,可见性)并将其输入到一个持续的bot评分中,该评分在页面刷新时保持不变。我们两周前写过这个话题:现在对会话行为的评分方式与一年前对指纹的评分方式相同。

Precursor和这一波针对headless的信号并不是孤立的举措。它们是同一套策略。停止孤立地对单个request进行评分。在你能测量的每个维度上,对整个会话进行评分。

你实际支付的两种税

在内部运行headless在纸面上总是很便宜。框架是免费的,浏览器是免费的,容器也很便宜。但2026年增加了两项未在账单上显示的条目。

维护税是人们会注意到的。Puppeteer-extra-stealth过去能在补丁之间争取数月的缓冲期。在2026年任何有实质防御的网站上,它只能争取几周。在headless更新,浏览器更新,防御更新和隐身插件更新之间,一名工程师每月可能要消耗整整一周时间来保持技术栈的对齐。没有人会把这放在路线图上。它只会吞噬路线图。

检测税是人们不会注意到的,因为它隐藏在成功率图表中。受保护目标的封锁率缓慢上升。重试次数增加。每次成功抓取的成本也随之增加。你将其归咎于"网站变难了"然后继续前进。其中一部分是真实的。另一部分是你的技术栈特征与普通浏览器特征之间日益扩大的差距。两者都呈相同趋势。

任何一种税都不会扼杀一个项目。它们加在一起,改变了自建与购买的算账方式。

这对数据团队意味着什么

并非每次抓取都需要浏览器。这一点没有改变。但值得重申,因为许多headless部署始于一个本可以通过纯HTTP调用解决的页面。

如果目标的数据来自XHR或JSON endpoint,请跳过浏览器。HTTP request更便宜,更快,并且从一开始就不携带任何这些指纹信号。7月份的okhlopkov文章给出了正确的优先级:优先使用API和XHR,其次是嵌入的JSON,只有在页面真正需要时才使用浏览器,在验证其他所有方法后才使用LLM提取。

对于确实需要浏览器的网站,问题在于防御级别。轻度保护(rate limit, User-Agent过滤, referer检查):配置良好的headless技术栈仍然有效,且成本很低。重度保护(采用完整会话评分的Cloudflare, PerimeterX, DataDome):成本是真实的,并且会不断累积。这就是权衡发生逆转的地方。

还有一个没人谈论的中间地带。网站不会直接封禁,而是悄悄降级服务。不同的价格,更少的列表,缺失图片,缺失评论。你的抓取工具报告成功。数据却在悄然出错。随着指纹评分成为内容决策而非封禁决策的输入,这种失败模式变得越来越常见。

如果你无法判断自己是否处于这个地带,那你很可能就在其中。

未来走向

headless是一种用了十年的手段,之所以有效是因为没人认真审查。过去两年改变了这一点。检测供应商最终认定剩余的抓取工具份额值得封锁,并且他们选择了最容易隔离自动化的层面。

下一轮对抗将不再是关于更智能的隐身插件。而是关于哪些网站认为检测精度值得在配置异常的合法用户(无障碍工具,旧GPUs,企业proxies,私有DNS)上产生误报率。他们提升的每一点headless检测准确率,都会牺牲极小部分真实用户。这种权衡才是军备竞赛的真正战场,而不是你的Puppeteer配置。

如果你已经在支付headless税,至少要去衡量它。否则,这只是你不知不觉中承担的代价。