通过网页界面实现 ChatGPT 和 Claude 的自动化：防机器人保护与反检测浏览器的工作原理

您想以折扣价体验 Octo Browser 吗？
使用优惠码 OCTOBLOG 即可享受任何订阅的 30% 优惠。此优惠仅对新用户有效。

既然有 API，为什么还要对 Web 界面进行自动化？

OpenAI 和 Anthropic 提供了带有详细文档的官方 API。那为什么还要构建复杂的基础设施并应对安全检查呢？原因有三点。

1. 规模化成本节约。使用 API 时，您需要为处理的每一段文本付费。在批量生成内容、翻译大型数据库或运行智能体（agent）时，账单可能会高达数千美元。ChatGPT Plus 和 Claude Pro 订阅费用均为每月 20 美元；更高级别的计划中，ChatGPT Pro 为 200 美元，Claude Max 起售价为 100 美元。即使存在消息数量限制，使用网页版也可能会便宜数倍。

2. API 中不可用的功能。AI 网站是它们的核心旗舰产品。网络搜索、代码执行以及某些特定模型和工具，要么无法通过 API 使用，要么推出较晚或受到限制。

3. 非官方 API。许多灰色市场产品都是基于 AI 网站构建的非官方 API。开发者运行数百个浏览器会话，将网站转化为熟悉的 REST API，并以官方套餐十分之一的价格出售访问权限。例如，许多无需 VPN 即可访问 AI 模型的 Telegram 机器人就是这样运作的。

一个典型场景：您有一张包含数千行的电子表格，每行都需要模型的回复。手动操作既不现实也几乎不可能，而使用 API 成本太高，或者您需要的模型根本不可用。正是在这种情况下，网站自动化开始展现出其价值。

为什么不直接使用 Selenium 或 Puppeteer 编写一个简单的脚本呢？问题在于 AI 公司也必须控制成本。他们不仅希望出售订阅，还希望将企业客户转化为付费 API 用户。因此，AI 网站拥有强大的防护机制，在无头浏览器中运行的简单脚本根本无法完成任务。事实上，如今这类脚本在很多网站上都步履维艰。

为什么标准自动化工具不起作用

在探讨解决方案之前，我们先来看看问题所在。如果您使用简单的脚本直接访问 ChatGPT 或 Claude 网站会发生什么？

现代防护措施远远超出了 IP 地址封锁的范畴。它在多个层面对请求进行检查，并在三种主要情况下阻止自动化。

第 1 层。连接：无浏览器脚本（requests、axios）

理论上，来自普通脚本的请求在数据交换开始之前就应该被拒绝（返回 403 或 429 错误）。安全系统会检查客户端建立安全连接的方式，即其 TLS 指纹。每个浏览器都有一个可识别的特征签名：在第一个数据包（Client Hello）中发送给服务器的参数集及其顺序。这就是 JA3 和 JA4 指纹的基础。诸如 OpenSSL 或 urllib 等网络库具有不同的签名。如果一个脚本伪装成桌面版 Chrome，却像普通库一样建立连接，服务器将检测到这种不匹配并可能终止连接。

实际上，这种防护更为隐蔽。如果 IP 地址不在黑名单中，服务器可能会返回 200 OK，但呈现的是空白页面或 Cloudflare 质询页面，而不是正常运行的网站。若要继续，脚本需要运行经过混淆的 JavaScript 代码。没有浏览器的脚本缺乏 JS 引擎，因此自动化就此止步。

简单脚本运行示例

第 2 层。浏览器：未作修改的 Puppeteer 或 Selenium

由于需要执行 JavaScript，顺理成章的下一步就是使用无头浏览器（即没有用户界面的浏览器）。它可以建立连接、加载页面并执行脚本，但会卡在隐形的 Cloudflare Turnstile 检查中。从外部看，这表现为“稍等片刻…”页面或一个不断旋转的复选框。

查看网络请求，可以看到浏览器向质询平台端点发送遥测数据并接收响应，但系统始终无法颁发授予网站访问权限的 cf_clearance cookie 令牌。

问题不在于脚本如何点击——我们甚至还没到点击这一步。浏览器本身就向安全系统暴露了自动化的痕迹：

• 自动化标记。受脚本控制的浏览器会通过 navigator.webdriver = true 属性标记自己。Selenium 通过 WebDriver 工作，而 Puppeteer 使用 CDP 协议，但两者启动浏览器时都会设置此标记。安全系统可以轻松检测到它，即使您尝试通过简单的 JavaScript 注入来隐藏它也是如此。

• 无 GPU 的图形渲染（WebGL/Canvas）。服务器或 Docker 容器没有 GPU，因此浏览器使用 CPU 渲染图形。安全系统会请求有关图形设置的信息，并在 WebGL Renderer 中看到典型的服务器端软件渲染——基于 SwiftShader 的 ANGLE。它还会在隐藏的 Canvas 元素中静默绘制图像，并将其哈希值与预期值进行比对。

当系统检测到自动化标记以及无 GPU 的图形渲染时，它就会识别出面对的是一个服务器端机器人。

您不会被直接封锁；相反，您会被引导进入无休止的检查中，永远无法访问 AI 模型。

第 3 层。行为：响应被截断

主要的困难接踵而至。模型的响应是通过与服务器的持久连接（Server-Sent Events (SSE) 或 WebSocket）分块到达的。在此过程中，系统会持续评估会话状态。

如果系统注意到光标是瞬间跳转到所需按钮，而不是像人类操作光标那样平滑移动、带有加速度和轻微抖动，响应可能会在生成过程中被切断。在 WebSocket 的情况下，连接会以代码 1006（异常关闭）断开。光标移动只是其中一个例子：安全系统分析的信号远不止这些。

在最糟糕的情况下，账号会被“隐形封禁”（shadowban）。您仍然保持登录状态，脚本也会发送包含提示词的 POST 请求，但收到的响应却是一个空的 JSON 对象或“临时生成错误”消息。

标准解决方案的死胡同

综合这三个层面，情况显而易见：没有 JS 引擎的 HTTP 客户端毫无用处，而标准的自动化工具又会通过 navigator.webdriver 标记、软件渲染的图形和合成输入事件暴露自己。

您可以选择阻力最小的途径：通过几次 JavaScript 注入来给 Selenium 或 Puppeteer 打补丁，并添加一个验证码解决服务。但一定要准备好预算，因为您会遇到大量的验证码，而且这依然无法使架构保持稳定。

还有另一种方法：构建一个用于与 LLM Web 界面交互的高可用系统。它需要满足三点要求：

1. 完整的浏览器环境。一个真正的浏览器引擎，能够像常规 Chrome 一样执行混淆检查。

2. 不可检测的控制。控制协议不得在 window 对象中留下任何痕迹——没有自动化标记，也没有 WebDriver 变量。

3. 与硬件保持一致。Canvas 和 WebGL 哈希值、字体集合及其他参数必须与声明的 GPU 和操作系统相匹配，而不是暴露虚拟服务器的特征。

在不亲自重写 Chromium 引擎的前提下，如何才能满足这些要求？

作为自动化架构基石的反检测浏览器

解决方案来自于联盟营销和多账号管理领域：反检测浏览器，例如 Octo Browser。它们与打补丁的 Puppeteer 的主要区别在于伪装指纹的层级。这并不是通过 JavaScript 脚本实现的，而是在 Chromium 引擎的源代码层面完成的。

需要理解的是，Puppeteer 同样使用 CDP 协议，因此差异不在于控制方式。差异在于脚本所连接的浏览器本身。它使用什么指纹以及是否包含自动化标记，才是关键所在。

在实践中这能带来什么？

• 逼真的 GPU 参数。浏览器不会通过 SwiftShader 进行软件渲染，而是展现与真实硬件（Nvidia、AMD 或 Apple Silicon）相对应的参数。Canvas 和 WebGL 哈希值与声明的 GPU 保持一致。

• 环境配置文件隔离。每个 ChatGPT 或 Claude 账号都在独立的加密配置文件中运行。每个配置文件都拥有独立的字体、WebRTC 设置和时区。

• 通过本地 API 和 CDP 进行控制。无需使用代码来配置环境。配置文件通过浏览器的本地 REST API 启动，脚本通过 CDP 端口连接到这些配置文件。

在这种架构下，Python 或 Node.js 脚本只负责处理逻辑。它获取源数据，构建提示词，将其发送到在反检测浏览器中运行的 AI Web 界面，并取回结果。预先准备好的环境则负责满足反欺诈系统的要求。

解决方案架构：保存的环境配置文件与 CDP 连接

最终，与 AI Web 界面的交互变成了一条稳定的流水线，其中反检测浏览器承担两个角色。

• 初始设置环境。您在常规环境配置文件窗口中打开一次界面，并像普通用户一样使用它：手动登录并在出现验证码时完成验证。浏览器会在隔离的环境配置文件中保存 cookie、缓存和身份验证令牌。在服务器看来，这就像一个普通人只是关闭了标签页。

• 基础设施节点。当您需要运行自动化时，脚本会通过本地 API 启动已经准备好的环境配置文件，并通过 CDP 连接到它。

由于该环境配置文件已经过身份验证，因此访问 chatgpt.com 或 claude.ai 会立即打开聊天界面。不需要重复登录或输入验证码：对于 Cloudflare 而言，这是在受信任设备上延续先前已验证的会话。您可以拥有多个这样的环境配置文件。

系统中的角色分工如下：反检测浏览器在内核级别伪装硬件参数、连接代理并存储 cookie；脚本发送提示词并获取回复；而 CDP 将二者连接起来。从本质上讲，浏览器发挥了其原本的作用，只不过是由代码代替人类进行控制。

结语

LLM Web 界面在三个层面上对客户端进行检查：客户端如何建立连接、运行环境以及在会话期间的行为。这就是为什么隐身插件、JavaScript 补丁或更换代理等孤立的修补措施充其量只能提供暂时的效果。它们往往只解决了一个问题，却让其他问题暴露无遗。

稳定可靠的自动化始于环境，而非脚本。具有内核级别一致指纹的浏览器、预先配置好的环境配置文件以及 CDP 控制，免去了代码进行伪装的负担。脚本只需完成其实际工作：发送提示词并处理回复。

与此同时，应当实事求是地评估这种架构的风险。防护系统在不断演进，通过自动化方式访问 Web 界面也违反了 OpenAI 和 Anthropic 的服务条款。任何此类架构都需要维护，理解所面对的防护机制的运作原理至关重要。