你大概用过浏览器的隐私模式以为关掉窗口之后过去的自己就消失了。可现实是一个叫“浏览器指纹”的东西比 Cookie 更执着。Cookie 会被清掉指纹不会。它藏在你屏幕尺寸、显卡渲染、字体列表和时区设置里你每次打开网页都在无意识地把身份证复印件交给对方。我最近在折腾的camofox-browser项目做的就是一件事让这张“身份证”变成假的。名字拆开看camo是迷彩伪装fox指的是 Firefox组合起来就是一个“伪装成其他浏览器样子的 Firefox”。很多人第一时间会联想到改个 User-Agent 就完事但真正做进去会发现指纹是一个互相咬合的系统牵一发而动全身。这篇文章把我从零搭到基本可用的完整思路写下来包括指纹向量拆解、配置落地、检测工具交叉验证以及我在调试过程中踩过的几类坑。如果你想做一个类似的隐私浏览器项目或者只是想把自己的 Firefox 调成“大众脸”应该能直接抄到不少作业。1. 为什么隐私浏览救不了你从 Cookie 到指纹追踪1.1 被低估的追踪手段广告联盟和网站风控最早依赖的是第一方 Cookie 和第三方 Cookie。第三方 Cookie 被浏览器逐步封禁后追踪方并没有偃旗息鼓而是把重心转移到“设备指纹”上。原因是设备指纹不需要在用户硬盘上落任何东西只要网页里有一段 JavaScript就能在页面加载时收集几十项环境信息。这些信息本身看起来无关痛痒显示器分辨率、操作系统语言、装了哪几种字体、显卡型号、CPU 核心数、是否有触控屏。但如果把这些字段组合起来任意一个普通用户的指纹在几百万样本里的唯一性都高得吓人。安全研究领域经常引用这样一个结论仅屏幕尺寸、时区、字体和 User-Agent 四个字段就已经能区分出绝大多数访问者。隐私模式能挡住什么它挡不住指纹。打开隐私窗口后Cookies 是空的但浏览器还是会完整暴露 canvas 渲染结果、WebGL 参数、AudioContext 波形特征。这些内容不依赖存储而是在每次请求时重新计算。1.2 Camofox 的设计立场伪装而不是隐藏camofox-browser没有走“彻底屏蔽指纹采集”的路线因为这条路在现实中不可行。把所有 JavaScript API 全禁掉网站确实读不到指纹但网站也会把你当机器人处理验证码、登录拦截、支付风控一个都不会少。用户体验会差到没法用。所以我给这个项目的定位是“伪装者”让指纹采集方每次都拿到一份看起来正常、但无法持续追踪你的数据。这里有两个选择。第一个选择是“随机化”每次访问都换一个完全不同的指纹让追踪方无法把多次访问关联到同一个人。第二个选择是“大众化”让指纹尽量贴近某个通用配置让采集方觉得你只是一个普通访客。Camofox 默认结合了两种策略在会话内部保持指纹稳定在会话边界彻底切换身份。这听起来不复杂但实践时几乎每一步都在跟“一致性”作斗争。指纹不是孤立字段而是一张互相耦合的网。User-Agent 写了 Windows 11但navigator.platform返回 Linux这种自相矛盾的信息比什么都显眼。2. 一张“身份证”是怎么拼出来的指纹向量拆解2.1 常见指纹向量与采集方式做反指纹之前首先得知道对手在采集什么。我把常见的指纹向量整理成了一张表这也是 Camofox 项目早期做威胁建模时的底稿。指纹向量采集方式伪装难度User-AgentHTTP 请求头浏览器直接暴露低Accept-LanguageHTTP 请求头暴露语言偏好低屏幕分辨率/色深screen.width、screen.colorDepth中时区Date.getTimezoneOffset()中Canvas绘制文字和图形后读取像素数据高WebGL获取显卡厂商、渲染器、扩展列表高AudioContext分析音频处理链的微小差异高字体列表测量不同字体渲染宽度来枚举中CPU/内存navigator.hardwareConcurrency、deviceMemory低电池 API电量与充电状态变化中触控和输入设备navigator.maxTouchPoints等低大部分字段都是页面里的 JavaScript 直接读出来的不需要服务器端配合。所以反指纹要做的事就是在这些 JavaScript API 返回值的层面做干预。2.2 单点信息不重要组合起来才有杀伤力很多人一开始会犯一个错误只改了 User-Agent然后去检测网站看结果发现分数降下来了就以为成功了。实际上检测网站通常会把几十项特征放在同一个模型里算相似度。User-Agent 改了但时区还是东八区字体还是那 36 种中文加英文的混合列表Canvas 渲染结果跟 UA 对应的浏览器版本对不上这个指纹照样会被关联。我常把这个过程类比成拼图。单块拼图颜色再奇怪也说明不了什么可当追踪方手里的拼图越来越多、彼此吻合度越来越高时你在他眼里就从一个匿名访客变成了一个“疑似已知用户”。更麻烦的是某些字段是“联动”的。UA 声称是 Win11 上的 Chrome 120系统字体列表里就应该有 Segoe UI 系列和微软雅黑UA 声称是 macOSCanvas 渲染抗锯齿结果就应该符合苹果设备的子像素渲染逻辑。任何一项与其余特征矛盾都会成为风控模型的加分项——注意是“风险分”的加分项。2.3 优先级排序先解决可控性强的字段Camofox 项目第一阶段没有全部硬啃而是按可控性排了优先级。最容易改的是 User-Agent、语言、时区、屏幕参数这些都可以通过 Firefox 的about:config和 JS 前置脚本干预。中等难度是字体枚举需要在系统层面和内容脚本层面双重处理。最难的是 Canvas、WebGL 和 AudioContext它们涉及真实计算过程不是简单改一个返回值就能圆过去的。我们的目标也不是做到 100% 无法识别那在理论上基本不可能。只要把一个普通用户的指纹伪装成“批量生产的大众配置”让追踪方无法用这个指纹把你从人群中单独拎出来就算是合格。3. Camofox 伪装层落地user.js 与扩展的配合3.1 第一层Firefox 自带的反指纹开关Camofox 选择 Firefox 而不是 Chrome 做基底除了名字里的fox之外更现实的原因是 Firefox 对反指纹的原生支持比 Chromium 系更完整。最核心的就是privacy.resistFingerprinting这个开关它不是一个字段的修改而是一整套 API 返回值规范化机制。开启这个开关后Firefox 会把 Canvas 读取到的像素数据做一轮无规律扰动让不同用户拿到的结果不完全一致会把时区强制对齐到一个统一的基准而不是返回真实时区还会对screen相关 API 做尺寸修正配合 letterboxing 让窗口尺寸信息无法被精确读取。我在 Camofox 的user.js里保留了这样一组核心配置user_pref(privacy.resistFingerprinting, true); user_pref(privacy.resistFingerprinting.letterboxing, true); user_pref(privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts, true); user_pref(webgl.disabled, true); user_pref(media.peerconnection.ice.default_address_only, true); user_pref(geo.enabled, false); user_pref(javascript.use_us_english_locale, true);这里webgl.disabled我一开始是设成true的因为 WebGL 暴露的显卡信息太直接几乎是所有风控模型最看重的特征之一。但后来发现很多 3D 可视化网站会因为 WebGL 被禁而直接拒绝渲染所以我改成默认开启 WebGL、再通过扩展覆盖渲染器字符串的方式折中。3.2 第二层User-Agent 与 HTTP 头的自洽改造Firefox 的 RFP 会把 UA 改成一个通用版本但通用 UA 不代表“隐蔽”它只是把真实身份藏起来了还会让网站认为你是一个“非标准用户”。Camofox 的做法是手动指定一个主流浏览器的 UA比如当前最流行的 Chrome on Windowsuser_pref(general.useragent.override, Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36);只改 UA 是不够的因为请求头里还有Accept-Language。UA 是 Chrome 120语言列表却只有zh-CN,zh;q0.9这在中文环境下不突兀可如果我们的“人设”是海外访客那语言偏中就是最大的破绽。Camofox 在扩展层同时修改请求头里的多个字段保持 UA、Accept-Language、Sec-CH-UA 这三个头描述同一个身份。Firefox 的 WebExtension 可以通过webRequest.onBeforeSendHeaders实现browser.webRequest.onBeforeSendHeaders.addListener( (details) { let headers details.requestHeaders.filter( (h) ![user-agent, accept-language].includes(h.name.toLowerCase()) ); headers.push({ name: User-Agent, value: UA_CHROME_WIN }); headers.push({ name: Accept-Language, value: en-US,en;q0.9 }); return { requestHeaders: headers }; }, { urls: [all_urls] }, [blocking, requestHeaders] );需要注意Chrome 从某个版本开始加入了Sec-CH-UA客户端提示头直白地告诉服务器浏览器品牌和版本。如果 UA 写着 Chrome 120但Sec-CH-UA暴露了 Firefox那这种矛盾会直接拉高风险分。所以 Camofox 的扩展里还做了Sec-CH-UA的同步覆盖或删除保证整套 HTTP 层描述同一个“人设”。3.3 第三层Canvas、字体与时区的细节欺骗HTTP 层解决之后真正的硬骨头在 JavaScript API 层。Canvas 指纹的核心原理是网页把一段文字和一个图形画到一个canvas上然后调用toDataURL()读取像素。不同浏览器的字体渲染、抗锯齿算法、显卡驱动会导致图像有细微差异这些差异稳定且长期不变所以是极好的标识符。Firefox RFP 对这个问题的处理方式是给 canvas 像素加噪声。每次读取结果都有一定随机扰动让同一个用户两次读取的结果不完全一样追踪方看到的就是一个“不稳定”的指纹。这个方案虽然有效但它会让截图和在线绘图工具出现画面噪点部分场景下影响体验。字体枚举比 Canvas 更容易被人忽略。网页可以创建一个隐藏的span遍历几千个字体名逐个测量渲染宽度从而判断系统里装了哪些字体。这个信息几乎是无法通过简单 API 覆盖来隐藏的因为字体列表是真实渲染引擎的一部分。Camofox 的折中方案是在系统层减少非常见字体只保留一个通用字体集合让字体枚举结果落入绝大多数用户的重合区间。这个方法很笨但效果比在 JS 层伪造字体列表可靠得多。时区的处理也有讲究。把时区直接改成 UTC 看似安全但追踪方只要对比Date.getTimezoneOffset()和你访问地理位置的 IP 归属地就能发现异常。Camofox 默认不强行改时区而是让浏览器返回一个与当前“人设”对应的常用时区比如人设是欧洲访客就返回柏林时间。这个策略更贴近真实用户。4. 伪装可信度检查我踩了四类坑4.1 指纹一致性一次会话只能有一个“人设”项目做到中段我发现最大的问题不是伪装不够而是伪装过头。有一次我在同一个浏览器实例里同时开着两个身份配置一会儿用 Windows Chrome 人设一会儿切到 macOS Safari 人设结果被某个站点直接判成高风险。原因很好理解同一个 IP、同一组 Cookie但指纹在人设切换时完全变了这种“跳跃式变化”比一直保持某个指纹要异常得多。所以 Camofox 现在把“人设”绑定到会话粒度。一个浏览器 profile 只能有一个完整人设切换人设就切换整个 profileCookies、LocalStorage、IndexedDB 全部跟着换。宁可让每个身份停留时间短一点也不能在同一身份里频繁换脸。4.2 特征联动UA、语言、时区必须自洽踩过的第二个坑是特征联动。我最早只改了 UA 和语言头没管时区结果检测页面上清清楚楚列出“系统时区Asia/Shanghai系统语言en-US”这种组合一出现风控基本直接拉黑。后来我做了个检查清单每次改完人设之后逐项核对UA 品牌与操作系统版本是否匹配语言列表和 Accept-Language 是否一致时区与语言对应的地理区域是否合理字体列表与操作系统类型是否吻合屏幕分辨率是否符合该设备的常见规格Canvas 渲染结果的抗锯齿风格是否与浏览器品牌一致六个项目里只要有一项对不上我就会放弃这个人设换一个更自然的组合。宁可选用一个“普通得毫不起眼”的配置也不要造出一个不存在的超级混合体。4.3 检测绕过用多个指纹检测站点交叉验证配置完一套人设之后需要验证能不能过检测。我常用的检测站点包括fingerprintjs.com的 Demo、browserleaks.com、amiunique.org、deviceinfo.me。这些站点虽然不能代表所有风控系统但至少能提供一套通用的特征视角。交叉验证的方法很简单在同一个浏览器实例里开多个检测页面反复刷新看两次结果是否一致。如果结果出现频繁变化说明 RFP 的噪声机制在生效这能防关联但并不可靠。如果结果显示“You are unique among N samples”说明伪装还不够大众化需要继续调整特征。我建议记录每次检测的关键字段做成一个小的变更日志。比如第一次测试发现字体列表爆出了 80 多种字体我就去系统里卸载了那些不常用的字体第二次发现 WebGL 显卡信息显示了真实型号我就通过扩展把 vendor 和 renderer 替换成 Intel UHD 系列这个最大众的结果。4.4 兼容性与可用性的平衡第三个坑是网页兼容性。很多网站会直接用navigator.userAgent做设备适配UA 被手动改了之后网页给出的下载链接可能是错的或者把桌面浏览器识别成移动端。更棘手的是登录风控。银行、支付、社交平台基本都会同时使用指纹、IP、设备历史和账号行为数据。Camofox 只解决“设备指纹”这一块没法解决“这个账号本身已经在一台设备上长时间登录过”这种历史问题。所以我的项目边界很明确它适用于新账号注册、企业侦查、多人共用的实验室环境等场景不适合拿来给一个已经被风控标记过的老账号续命。如果某些站点必须要真实 WebGL 才能正常显示我会在配置里单独建立一个“例外清单”对这些域名临时放开限制。但例外清单本身要很小且每个例外都单独评估不能因为一两个站点把整体伪装层全拆掉。5. 伪装技术不是终点面临的下一个对抗方向5.1 行为指纹与 AI 检测静态指纹伪装到一定程度后追踪方也在升级。现在越来越多风控系统开始采集“行为指纹”——鼠标移动轨迹、键盘输入速度、停留时长分布、滚动模式。这些特征很难靠浏览器配置去伪装因为它们本质上是人的行为模式。Camofox 能做的是降低行为指纹的辨识度。比如避免像机器人一样过于规律的点击间隔不要长时间无操作后突然快速填写表单。这些属于使用习惯层面的调整工具只能提供辅助。另外AI 模型开始把多个维度的信息放一起做联合判断。它们不再只看某一个字段是否异常而是看“异常的组合方式”。所以反指纹项目的未来方向不是一个个字段地打补丁而是建立一套完整的人设生成器把 UA、语言、时区、字体、Canvas、行为模拟甚至联网后的 IP 归属信息全部编入同一个“人设模板”。5.2 保持伪装层的可维护性浏览器版本全年都在更新指纹采集手段也不会停在某个版本。Camofox 把配置全部收敛在一个仓库里每次 Firefox 升级后我都会重新跑一遍检测流程观察有哪些字段发生了变化。维护这个项目的最大体会是反指纹不是一次性的配置项目而是需要长期追踪、反复校准的对抗性工程。我现在每次更新版本都会做三件事。第一把user.js里的废弃配置清理干净新版 Firefox 有时会改变默认行为。第二用浏览器内置的about:config对照官方文档确认 RFP 相关的每一项开关语义没有变化。第三在实际目标站点上做人工回归测试确认登录、搜索、下单这些核心流程没有被误判成机器人。这套维护流程看起来繁琐但恰恰是它能持续有效的原因。指纹对抗没有一劳永逸的银弹只有不断观察、不断调整才能让“伪装”这件事保持可信。我在实际使用中发现最值得投入精力的不是追着新检测技术跑而是把基础人设的自洽性做到极致。一个字段对不上可能只是被标记两个字段对不上基本就进黑名单了。Camofox 后续的扩展方向之一是增加更细粒度的人设模板库让每个用户都能一键生成和自己真实使用习惯相近然而又无关的伪装身份把“伪装”这个过程本身也变成一件足够简单、足够自然的事。