thermoptic

“我不相信，热光学迷彩！”

这是什么？

这是一个 HTTP 代理，旨在绕过使用 JA4+ 等指纹识别技术来阻止某些 HTTP 客户端的服务。使用此代理，你可以继续使用你偏好的 HTTP 客户端（如 curl），同时拥有与真实（Chrome/Chromium）网页浏览器神奇地无法区分的指纹。thermoptic 还附带了一些有趣的功能，用于缓解基于 JavaScript 的指纹识别。它还使得同时使用网页浏览器和底层 HTTP 客户端进行混合抓取变得容易。

即使你不熟悉 JA4+ 指纹识别，如果你做过任何抓取工作，你很可能之前就被它阻止过。像 Cloudflare 这样的流行服务使用此类技术（以及其他技巧）来检测“非人类”HTTP 客户端的使用，从而阻止请求。这些服务还可以使用这种指纹识别来检测你是否用真实浏览器开始会话，然后稍后切换到像 curl 这样的底层客户端。thermoptic 通过为所有抓取请求呈现统一的“真实”浏览器指纹，解决了所有这些问题。

示例

以下是不使用代理时 curl 的 JA4H（HTTP）指纹示例：

$ curl https://ja4db.com/id/ja4h/
ge11nn090000_b6a016211e8a_000000000000_e3b0c44298fc

这与直接访问该 URL 时 Chrome 生成的指纹截然不同：

ge11cn19enus_f2808f0d04cf_9a10d4221160_7068f58def6e

然而，当我们使用代理发起请求时，我们的 JA4H 指纹神奇地变得完全一致：

$ curl --proxy http://thermoptic:1234 https://ja4db.com/id/ja4h/
ge11cn19enus_f2808f0d04cf_9a10d4221160_7068f58def6e

（我们的 JA4 TLS 指纹同样如此，等等）。

设置

要在 Ubuntu 22.04 上启动一个通过容器化 Chrome 实例伪装流量的 thermoptic 代理：

常规 Docker 设置（适用于没有 GPU 运行时的主机）：

docker compose up --build

就是这样，现在你可以通过它代理流量了：

curl --proxy http://127.0.0.1:1234 --insecure https://ja4db.com/id/ja4h/

重要说明：

• 默认情况下，代理运行时无需身份验证。如果您计划将代理暴露到外部，请务必使用环境变量 PROXY_USERNAME 和 PROXY_PASSWORD 设置身份验证。
• 如果您不想使用 ---insecure，则需要使用位于 ./ssl/rootCA.crt 的生成的 CA 文件。该文件在您首次运行 thermoptic 时生成。
• 您可以将 thermoptic 连接到任何使用 --remote-debugging-port 标志启动的 Chrome/Chromium 实例。这一点至关重要，因为您会希望在更常用的环境中设置和代理，以尽可能保持您的指纹低调（例如 Windows 上的 Chrome）。
• GPU compose 覆盖文件适用于已安装 Docker NVIDIA 运行时/工具包的 NVIDIA 主机。它会预留 GPU 设备、挂载 /dev/dri，并让捆绑的 Chrome 容器切换到 NVIDIA/Vulkan 渲染路径。要使用此功能，请运行 docker compose -f docker-compose.yml -f docker-compose.gpu.yml up --build。

功能特性

• 🕵️ 浏览器对等代理，通过真实的 Chrome 会话重放请求，以逐字节匹配 JA4 指纹。
• 🤝 几乎无需自定义代码即可将您的 HTTP 客户端（例如 curl、requests 等）与 thermoptic 集成，只需设置代理，您的指纹就会被处理好。
• 🪝 钩子框架，用于请求前/请求后/启动时自动化，以便您可以驱动整个浏览器来解决挑战或捕获产物。
  • 📘 一个 Cloudflare turnstile 解决钩子示例可在 ./hooks/onstart.js 中查看。
• 🖥️ Web 浏览器控制 UI（位于 http://127.0.0.1:14111），用于控制 Docker 化的 Chrome 浏览器窗口。这对于手动登录网站，然后无缝地使用代理以您已登录的会话发出请求（以及用于调试）非常有用。
• 🔌 通过 docker-compose.yml 中的 UPSTREAM_PROXY 环境变量设置上游 HTTP 或 SOCKS 代理 URI。
• 🛡️ 内置健康检查和重启控制循环，以检测冻结的浏览器并自动恢复，无需操作员照看。
• ⚡ 支持 HTTP/1.1 和 HTTP/2，允许通过任一协议代理流量。（请注意，您可以对代理使用 HTTP/1.1 通信，而被操控的 Chrome 可能会通过不同的协议与终端站点协商。）

这种隐身技术究竟是如何工作的？

• 使用 HTTP 客户端（如 curl）发出 HTTP 请求，并将 thermoptic 设置为代理。
• thermoptic 分析请求，以最佳方式确定它应该是什么类型的浏览器请求（例如手动访问 URL？表单提交？fetch() 请求？）。
• thermoptic 使用 Chrome 调试协议 (CDP) 来操控浏览器，并设置一个页面，以完全模拟该请求在真实 Web 浏览器中通常发生的方式。
• thermoptic 通过模拟的上下文触发请求并捕获 HTTP 响应。
• thermoptic 将 HTTP 响应发送回客户端。

由于浏览器实际上是使用其完整技术栈发出请求的，因此生成的 JA4 指纹是完全相同的。

注意：由于许多 WAF 采用针对 Web 浏览器的 JavaScript 级别指纹识别，thermoptic 还暴露了钩子，以便在抓取过程的关键步骤中利用浏览器。有关更多信息，请参阅本节。

为什么这种方法优于其他解决方案？

直截了当地说：其他方法存在根本性缺陷，使其无法成为浏览器指纹识别问题的实用长期解决方案。

许多其他试图“击败”浏览器 JA4+ 指纹识别的尝试，都是通过重新实现浏览器技术栈的各个层来实现的。这种方法有许多严重缺点，例如：

• 需要非常小心地完美匹配“真实”浏览器实现的行为。因此，任何怪癖或差异都可能被用来将这些客户端与“真实”浏览器实现区分开来。
• 试图只在技术栈的某一层解决问题。Chrome 利用多种协议来提供 Web 浏览体验。因此，即使您已经制作了完美匹配的 TLS 层，如果您的 HTTP 层不是逐字节完美的，也可能暴露您。
• 由于“真实”浏览器会定期改变其行为，它们的指纹也会改变，因此这些工具需要不断进行更密集的开发工作来补偿。

相比之下，由于 thermoptic 使用浏览器本身来执行 HTTP 请求：

• TCP、TLS、HTTP 等技术栈的每一层都与真实浏览器无法区分，因为请求是使用真实浏览器以通常发生的方式发出的。
• 各层浏览器行为的变化带来的干扰最小，只需更新 thermoptic 控制的浏览器即可匹配最新的指纹集。

当然，没有解决方案是没有缺点的。请参阅 DOWNSIDES.md 文档，了解 thermoptic 方法缺点的完整列表。

常见问题

为什么叫 thermoptic？

“Thermoptic”（“thermoptic camouflage”的缩写）是对《攻壳机动队》（1995 年动画）中少佐使用的虚构伪装的引用。在电影中，这种伪装能够跨越多种探测频谱隐藏穿戴者，包括可见光和热辐射。类似地，此工具试图在多个通道（HTTP、TLS 等）中隐藏用户，使其免于被指纹识别。

JA4+ 是一套指纹！它伪装哪些指纹？

此工具会将以下 JA4 指纹伪装得与您连接的 Chrome/Chromium 浏览器完全一致：

• JA4（TLS 指纹）
• JA4H（HTTP 指纹）
• JA4X（X509 TLS 证书指纹）
• JA4T（TCP 指纹）

如果我想与此一起使用另一个上游 HTTP/SOCKS 代理怎么办？

thermoptic 现在通过内部 proxyrouter 服务路由受控的 Chrome 实例，因此您可以将 Chrome 指向上游 HTTP 或 SOCKS 代理（包括需要凭据的代理）。通过编辑 docker-compose.yml 中 proxyrouter 服务下的 UPSTREAM_PROXY 值来设置上游代理 URI。当您将其留空时，Chrome 会通过集群内未经身份验证的代理直接与互联网通信。

设置上游 SOCKS 代理的示例：

  proxyrouter:
    environment:
      UPSTREAM_PROXY: "socks5://username:[email protected]:1080"

请注意，某些上游代理可能会改变底层指纹（例如 TCP 元数据），这可能会降低与住宅浏览器的相似度。

那 cookies 呢？

thermoptic 会使用你的客户端在 Cookie 头中指定的 cookies 来加载浏览器。请求在浏览器上下文中执行后，就会包含这些 cookies。这样做是为了确保服务器无法对 cookies 的顺序或任何其他类似的小伎俩进行指纹识别。

注意：这些 cookies 在请求之后也会保留。如果你想为 cookies 实现清理逻辑，请编写一个 thermoptic 钩子。

好吧，但是需要通过完整网页浏览器点击 X 提示才能通过人工验证！

是的，thermoptic 支持这种混合用法，请参阅本节了解更多信息。

我对请求 X 的指纹与浏览器指纹不匹配！

你需要确保正确设置了 X-Fetch-*、Origin 和 Referer 等头。如果你不把这些头告诉 thermoptic，它就无法以适当的隐蔽方式执行请求。

如果不设置上下文头，thermoptic 会设置默认值，这些值可能无法准确反映你的目标站点所期望的内容。例如，如果你不设置 Origin 头，它会将 Origin 设置为 null；如果你不设置 Referer 头，它根本不会发送 Referer。

包含这些上下文头对你最有利，这样你的请求才能尽可能隐蔽！thermoptic 无法读心，它只能读取你的请求 :)。

Chrome 调试协议本身是可被指纹识别的！

一般来说，这仅适用于 thermoptic 钩子临时利用完整网页浏览器来通过 JavaScript/浏览器级别检查的情况。在临时使用这些钩子和完整浏览器模式时，你必须注意不要被指纹识别为机器人（例如避免 Runtime.enable 之类的陷阱）。

为什么发布这个工具？你不在乎你所助长的恶意行为者吗？！

这里的伦理考量和复杂的博弈论超出了 README 所能回答的范围。不过，当你通过电子邮件/Twitter/Github 对我开喷时，欢迎反驳以下任何一个过度简化的观点：

• 我不认为抓取本质上是不道德的。相反，以抓取形式存在的信息自由流动，正是许多令人惊叹的项目得以诞生的关键。
• 由于其中的激励因素，网页抓取和网页机器人防范如今已变成一场无聊的资本消耗游戏。想防止抓取？花钱让某个服务替你做。想绕过这些同样的服务？花钱让某个服务替你做。抓取太重要了，不能只留给那些负担得起的人，我发布这个开源项目正是出于这一信念。
• 当前反机器人框架的范式由于其以指纹为核心而具有强烈的侵入性。高级浏览器指纹识别脚本在功能上与浏览器漏洞利用工具包几乎难以区分。我希望，但并不指望，抓取方会出现阶跃式提升，以帮助颠覆这种反馈循环，并鼓励替代方案。

关于抓取军备竞赛的更多调侃，我要求你至少先请我喝杯啤酒。说实话，我讨厌在 README 里写这些无聊的伦理文章，所以你可以随意把我想象成一个想让你的生活更艰难的邪恶书呆子。

使用 thermoptic 钩子处理浏览器 JavaScript 指纹识别

thermoptic 允许你配置自定义脚本，以便在以下情况下执行浏览器操作：

• 浏览器首次启动时（环境变量 ON_START_HOOK_FILE_PATH）
• 请求即将被代理时（环境变量 BEFORE_REQUEST_HOOK_FILE_PATH）
• 请求刚刚完成代理时（环境变量 AFTER_REQUEST_HOOK_FILE_PATH）

这允许你使用 Chrome 调试协议来点击操作，并为需要真实网页浏览器进行验证步骤的站点设置适当的 cookies。然后你可以使用 thermoptic 代理，通过同一个浏览器继续你的隐蔽会话。

为此，请使用你的自定义代码修改相应的钩子 JavaScript 文件，以便通过提供的 chrome-remote-interface 接口适当地编排浏览器：

// `cdp` is an instance of a connected browser, use it to run your browser actions
export async function hook(cdp) {
    console.log(`[STATUS] Browser start hook called successfully!`);
}