浏览器自动化采集中的身份伪装与流量拦截实践

一、问题的由来：为什么自动化浏览器会被识别

在数据采集类项目中，登录态的获取往往是整个链路的第一道门槛。无论是电商价格监控、本地生活信息聚合，还是评论数据归集，都需要先完成用户登录，拿到有效的会话凭证（Cookie、Token 等），后续的请求才能被服务端正常受理。

而登录环节本身已经充满挑战：滑块验证、行为轨迹校验、滚动加载、验证码等反自动化手段层层叠加。很多开发者借助浏览器自动化驱动（如 WebDriver 协议实现）来模拟真实用户的点击与输入，从而绕过这些交互式校验。这一步通常可以奏效，因为滑块与轨迹校验更多依赖的是浏览器环境本身的真实性。

但真正棘手的问题出现在更底层：大型平台的前端安全团队会在页面中注入检测脚本，通过 JavaScript 主动探测当前浏览器环境是否带有自动化特征。一旦命中，脚本会向服务端上报异常标记，或者直接篡改响应内容、阻断关键接口。此时即便你的操作行为再像真人，环境指纹已经暴露，登录流程依然会失败。

因此，问题的本质从“如何模拟人”转变为“如何让检测脚本失效”。这不是对抗服务端的风控策略，而是让浏览器环境在特征层面回归普通用户状态。需要强调的是，任何采集行为都应当遵守目标站点的服务条款与相关法律法规，本文讨论的技术仅用于授权测试与合规场景下的环境调试。

二、检测的常见技术路径

要设计干扰方案，先要理解检测脚本通常关注什么。业界常见的探测点大致可分为三类：

第一类：全局对象属性探测。 自动化驱动在注入页面上下文时，往往会在 window 或 navigator 上留下可枚举的痕迹。检测脚本通过遍历特定属性名，判断其是否存在。这类属性名的命名有一定规律，通常与驱动实现、调试协议、异步执行器等概念相关。

第二类：函数行为特征。 例如某些 API 在被自动化环境调用时，其 toString() 结果、函数长度、原型链结构会与原生实现存在差异。检测脚本通过比对函数字符串来识别异常。

第三类：时序与事件特征。 自动化驱动的指令执行往往带有固定的节奏特征，例如鼠标事件的 isTrusted 属性、事件触发的间隔分布等。这类检测更难通过简单的文本替换绕过。

其中第一类和第二类最容易通过流量层拦截来消解，因为它们最终都体现为某个 JavaScript 文件的文本内容。只要在脚本到达浏览器之前修改其内容，探测逻辑就会失效。

三、拦截思路：在流量层做响应改写

最直接的想法是：找到负责检测的那个 JS 文件，把它里面的检测逻辑“抹掉”。但我们不能修改服务端，也不能永久篡改本地缓存，最优雅的位置是浏览器与服务器之间的中间人。

这里引入代理拦截工具的角色。通过在本地启动一个 HTTP/HTTPS 代理，让浏览器的全部流量都经过它，我们就可以在响应返回浏览器的瞬间对指定 URL 的响应体做文本替换。整个链路的顺序是：

1. 浏览器发起请求 → 2. 本地代理接收 → 3. 代理转发到目标服务器 → 4. 服务器返回响应 → 5. 代理改写响应体 → 6. 浏览器收到被“净化”的脚本。

这样浏览器拿到的 JS 已经不含检测关键字，而服务端对此一无所知。相比修改浏览器二进制、注入扩展或打补丁的方式，流量层改写具有非侵入、可热更新、易回滚的优点。

四、实施步骤详解

4.1 环境准备与代理配置

首先安装代理工具（Python 生态中常见的中间人代理实现即可），通过包管理器完成安装后，需要将操作系统的网络代理指向本地回环地址的指定端口（例如 127.0.0.1:8001）。这一步的目的是让浏览器的所有出站请求都经过代理，否则改写逻辑不会生效。配置方式因操作系统而异，通常在系统网络设置或浏览器启动参数中指定即可。

需要注意的是，HTTPS 流量需要代理工具生成并信任根证书，否则浏览器会因证书不匹配而拒绝连接。首次运行时按工具提示安装证书到系统信任库即可。

4.2 定位检测脚本

启动代理后，打开浏览器的开发者工具，切换到网络面板，刷新目标页面，观察加载的脚本列表。重点排查那些体积不大、命名带有安全或风控语义的文件。通常可以在 Sources 面板中搜索关键字，例如搜索 webdriver、navigator、cdc 等词，快速定位到包含检测逻辑的文件。

实践中，检测代码往往被混淆压缩，关键字可能被拆分成字符串拼接或十六进制编码。此时可以在网络面板中查看响应体，结合格式化工具还原可读结构，确认该文件确实承担了环境探测职责。

4.3 编写响应改写脚本

定位到目标文件后，编写一个拦截脚本，在响应阶段对 URL 匹配的请求做文本替换。核心逻辑是维护一份“特征词清单”，遍历清单并对响应体执行字符串替换，把敏感属性名替换为无害占位符。

import re
from mitmproxy import ctx
# 需要抹除的特征标识清单
SENSITIVE_KEYS = [
    "webdriver",
    "__driver_evaluate",
    "__webdriver_evaluate",
    "__selenium_evaluate",
    "__driver_unwrapped",
    "__webdriver_unwrapped",
    "_Selenium_IDE_Recorder",
    "_selenium",
    "calledSelenium",
    "_WEBDRIVER_ELEM_CACHE",
    "driver-evaluate",
    "webdriver-evaluate",
    "selenium-evaluate",
    "webdriverCommand",
    "__webdriverFunc",
    "__$webdriverAsyncExecutor",
    "$chrome_asyncScriptInfo",
]
def response(flow):
    # 仅处理目标检测脚本
    if "/js/security-probe." not in flow.request.url:
        return
    body = flow.response.text
    for key in SENSITIVE_KEYS:
        if key in body:
            ctx.log.info("strip key: %s" % key)
            body = body.replace('"%s"' % key, '"__removed__"')
    # 处理属性访问形式的特征
    body = body.replace("t.webdriver", "false")
    body = body.replace("ChromeDriver", "")
    flow.response.text = body

这段脚本的关键点有三个：一是 URL 匹配要精确，避免误伤业务脚本导致页面功能异常；二是替换时保留引号结构，防止 JS 语法被破坏；三是替换目标尽量替换为语义中性的字符串，而不是直接删除，否则可能引发解析错误。

4.4 启动与验证

退出交互式界面，以脚本模式重新启动代理并加载改写脚本，监听指定端口。随后在浏览器中重新访问目标页面，观察代理日志是否打印出命中记录，再回到控制台检查相关全局属性是否仍然存在。若页面功能正常且检测标记消失，说明改写生效。

验证时建议分两步：先确认脚本本身被替换（可在网络面板查看响应内容），再确认业务行为正常（登录流程可走通、关键接口有正常返回）。两步都通过才算真正成功。

五、工程化与稳定性建议

单次改写容易，长期稳定运行则需要考虑更多细节：

清单维护机制。 检测方会定期更新特征词，因此特征清单应当配置化、可热加载，避免每次改动都重启服务。可以将清单放在外部文件中，脚本启动时读取并监听变更。

匹配规则精细化。 不要对全站 JS 一刀切替换，否则极易破坏业务逻辑。建议按 URL 前缀、文件哈希或内容特征做多级匹配，并记录每次改写前后的差异日志便于回溯。

多层防御叠加。 流量改写只能解决文本层面的检测，对于行为时序、事件可信度等检测无能为力。完整的方案还应包括：使用真实用户配置的浏览器实例、控制操作节奏、避免高频重复访问、合理设置请求间隔等。这些措施共同降低整体特征暴露面。

合规与边界。 采集行为应严格限定在授权范围内，遵守 robots 协议与站点条款，控制请求频率，不对目标服务造成额外负载。技术手段的正当性依赖于使用场景的正当性，这一点应当在团队规范中明确。

六、小结

浏览器自动化被检测的核心矛盾在于环境指纹与真实用户之间的差异。流量层响应改写提供了一种非侵入的消解思路：通过本地代理拦截检测脚本，在到达浏览器前抹除特征标识，从而让环境回归普通状态。配合精确的 URL 匹配、可维护的特征清单以及行为层的节奏控制，可以显著提升采集链路的稳定性。工程实践中应始终把合规性放在首位，让技术方案服务于合法、可控的数据获取需求。