1. 项目概述与核心挑战最近在搞一个数据采集项目目标站点用了瑞数6.5做前端防护直接把我给拦在了门外。常规的请求头修改、代理IP轮换这些手段基本都失效了核心问题就出在那个动态生成的cookie和sign上。这玩意儿每次请求都会变而且跟你的浏览器环境、鼠标轨迹、页面加载时间等一系列因素强相关单纯靠抓包复制粘贴根本行不通。这其实就是典型的“人机验证”对抗场景瑞数通过一套复杂的JavaScript混淆和虚拟机VM技术在前端实时计算出一个动态令牌服务端再用同样的逻辑去验证不匹配就直接拒绝。面对这种级别的防护传统的“硬刚”JavaScript逆向把几千行混淆代码一点点抠出来还原不仅耗时巨大而且对方一更新你就得重来维护成本太高。经过一番调研和实战我发现结合“环境补全”与“RPC远程过程调用”的思路是目前应对瑞数6.5这类动态加密方案比较高效且稳定的策略。简单来说就是用一个真实的浏览器环境通常是Chrome的无头模式去执行瑞数的加密逻辑然后通过RPC将这个加密能力“暴露”出来供我们的Python爬虫程序远程调用。这样加密的核心黑盒逻辑由浏览器自己搞定我们只需要关心如何稳定地启动这个环境并与之通信。这个方法的核心价值在于“解耦”和“复用”。我们将复杂的JS执行环境与爬虫业务逻辑分离爬虫程序无需关心瑞数代码的具体实现只需像调用本地函数一样请求加密结果。同时一个补好的浏览器环境可以服务多个爬虫任务大大提升了资源利用率和开发效率。接下来我就把这次实战中关于RPC调用架构设计、动态cookie sign的生成策略以及那些踩坑后总结出的关键技巧详细拆解一遍。2. 核心思路环境补全与RPC调用架构2.1 为什么选择“补环境RPC”这条路面对瑞数通常有几种思路一是纯算法还原二是使用自动化浏览器如Selenium、Playwright三是补环境配合RPC。纯算法还原对逆向能力要求极高且瑞数的代码混淆和VM保护机制非常强更新频繁这条路性价比太低。使用自动化浏览器如playwright模拟真人操作虽然简单直接但资源消耗大、速度慢不适合大规模并发采集且浏览器指纹容易被高级风控识别。“补环境RPC”则是一种折中且高效的方案。它的核心思想是在一个精心修补过的、能够骗过瑞数检测的Node.js或浏览器环境中运行瑞数的核心加密JS并将生成cookie和sign的函数封装成服务接口。外部爬虫程序通过HTTP、WebSocket等RPC协议来调用这个接口获取加密参数。这样做的好处显而易见逆向工作量最小化我们不需要完全理解瑞数的所有加密算法只需要确保执行环境能被瑞数代码认为是“真实的浏览器”即可。这主要靠补全各种浏览器特有的API和属性如window、document、navigator等。执行环境隔离且稳定加密逻辑在一个独立、可控的进程中运行即使崩溃也不会影响主爬虫。我们可以专门优化和维护这个“加密服务”。高性能与可扩展一个加密服务进程可以处理多个并发请求。当爬虫需要高并发时可以部署多个加密服务实例形成集群通过负载均衡来分配请求。便于更新和维护当瑞数更新其JS代码时我们通常只需要检查环境补全是否依然有效或者微调RPC服务端的逻辑而不需要改动爬虫的主体代码。2.2 整体架构设计我采用的是一种经典的三层架构具体组件和流程如下[爬虫客户端 (Python)] | | (HTTP/WebSocket RPC 请求携带URL等参数) V [RPC服务网关 (可选如Nginx)] -- 负载均衡 -- | V [加密服务集群 (Node.js Puppeteer/Playwright)] | | (在补全的浏览器环境中执行JS生成cookie sign) V [返回加密结果 (JSON)] | | (携带cookie/sign的HTTP响应) --第一层爬虫客户端。用Python的requests或aiohttp库编写。当需要访问受瑞数保护的页面时它不直接发起请求而是先向加密服务发起一个RPC调用。第二层RPC服务网关。如果部署了多个加密服务实例需要一个网关来做负载均衡和路由。简单的可以用Nginx的upstream配置复杂的可以用专门的服务网格。对于初期或小规模应用可以直接让爬虫连接固定的加密服务地址。第三层加密服务集群。这是最核心的部分。每个服务实例本质上是一个Node.js Web服务器常用Express或Koa框架它内部通过Puppeteer或Playwright启动并控制一个Chrome浏览器实例。在浏览器中我们注入补环境脚本并加载目标页面或直接执行核心JS将生成加密参数的函数暴露给Node.js端再由Node.js通过HTTP接口提供给外部调用。2.3 技术选型Puppeteer vs Playwright在Node.js端控制浏览器主流选择是Puppeteer谷歌官方和Playwright微软出品。我两者都深度使用过简单对比一下在这次场景下的选择Puppeteer更成熟社区资源丰富特别是关于瑞数补环境的文章和代码片段大多基于它。API相对稳定。缺点是只支持Chromium系浏览器。Playwright后起之秀支持Chromium、Firefox、WebKit三大引擎。API设计更现代、一致自动等待等机制更智能。在处理复杂页面交互时可能更有优势。对于瑞数6.5其检测逻辑主要针对Chrome/Chromium因此两者都能胜任。我最终选择了Playwright主要原因是其更清晰的异步API和更好的错误处理机制在编写长时间运行的服务时感觉更稳健。但以下内容的核心思路对两者完全通用。3. 加密服务端核心实现详解3.1 服务端基础框架搭建首先初始化一个Node.js项目安装依赖。npm init -y npm install express playwright创建一个基础的服务文件server.js。这里使用Express作为HTTP服务器。const express require(express); const { chromium } require(playwright); // 或 require(puppeteer) const app express(); const port 3000; // 中间件解析JSON格式的请求体 app.use(express.json()); // 核心路由处理生成cookie和sign的请求 app.post(/generate, async (req, res) { const { targetUrl } req.body; // 假设客户端传递目标URL if (!targetUrl) { return res.status(400).json({ error: Missing targetUrl }); } let browser null; try { // 1. 启动浏览器 browser await chromium.launch({ headless: true, // 无头模式生产环境建议为true args: [ --disable-blink-featuresAutomationControlled, // 关键隐藏自动化特征 --no-sandbox, --disable-setuid-sandbox ] }); // 2. 创建浏览器上下文和页面 const context await browser.newContext(); const page await context.newPage(); // 3. 注入补环境脚本在页面加载任何内容之前 await page.addInitScript({ content: // 这里是补环境代码的核心区域详见下一节 Object.defineProperty(navigator, webdriver, { get: () undefined }); window.chrome { runtime: {} }; // ... 更多补丁 }); // 4. 导航到目标页面触发瑞数JS执行 await page.goto(targetUrl, { waitUntil: networkidle, timeout: 30000 }); // 5. 从页面中提取加密结果 // 方法A如果瑞数将结果直接写入cookie或全局变量可以通过evaluate获取 const cookieSign await page.evaluate(() { // 这个函数在浏览器上下文内执行 // 假设瑞数生成的cookie名为FSSBBIl1UgzbN7N80T const cookie document.cookie.match(/FSSBBIl1UgzbN7N80T([^;])/); // 假设sign在window对象上 const sign window._rsaSign || ; return { cookie: cookie ? cookie[1] : null, sign }; }); // 方法B更可靠的是监听特定的网络请求或执行特定的JS函数来获取 // 这里以方法A为例 res.json({ success: true, data: cookieSign, timestamp: Date.now() }); } catch (error) { console.error(RPC服务处理失败:, error); res.status(500).json({ success: false, error: error.message }); } finally { // 6. 关闭浏览器释放资源 if (browser) { await browser.close(); } } }); app.listen(port, () { console.log(加密RPC服务运行在 http://localhost:${port}); });这是一个最简化的框架。它暴露了一个/generate的POST接口接收targetUrl启动浏览器访问该URL并在补环境后尝试提取cookie和sign。注意在生产环境中绝不能为每个请求都启动和关闭一个浏览器这太耗时了。正确的做法是复用浏览器实例或页面上下文。我们可以启动一个浏览器然后为每个请求创建一个新的“隐身上下文”incognito context或标签页。甚至可以使用browser.newPage()在同一个上下文中创建新页面但要注意cookie的隔离问题。最佳实践是使用一个“浏览器池”来管理多个浏览器实例以支持更高并发。下面会讨论优化策略。3.2 瑞数6.5环境补全关键点补环境是成败的关键。瑞数会检测大量的浏览器属性和行为。我们的目标不是补全所有Web API而是补全那些它用于检测自动化工具的关键点。以下是一些必须处理的“重灾区”1. Navigator 对象// 清除或覆盖webdriver属性 Object.defineProperty(navigator, webdriver, { get: () undefined, configurable: true, enumerable: true // 注意有些检测会遍历属性需要可枚举 }); // 补全plugins和mimeTypes Object.defineProperty(navigator, plugins, { get: () [1, 2, 3, 4, 5], // 模拟有插件 configurable: true }); Object.defineProperty(navigator, mimeTypes, { get: () [1, 2, 3, 4, 5], configurable: true }); // 覆盖language和languages Object.defineProperty(navigator, language, { get: () zh-CN }); Object.defineProperty(navigator, languages, { get: () [zh-CN, zh, en] });2. Window Document 对象// 定义chrome对象非Chrome浏览器也需要 if (!window.chrome) { window.chrome { runtime: {}, loadTimes: function() {}, csi: function() {}, app: { /* ... */ } }; } // 覆盖某些只读属性如document.hidden等 Object.defineProperty(document, hidden, { get: () false }); Object.defineProperty(document, visibilityState, { get: () visible }); // 补全document.createElement的原始方法防止被检测hook const originalCreateElement document.createElement; document.createElement function(tagName) { const element originalCreateElement.call(document, tagName); // 如果是canvas可以为其添加一些指纹干扰 if (tagName.toLowerCase() canvas) { const originalGetContext element.getContext; element.getContext function(contextType) { const context originalGetContext.call(this, contextType); if (contextType 2d) { // 对2d context进行一些细微的、非确定性的修改增加指纹随机性 context.fillText function(...args) { // 轻微修改不影响渲染但改变指纹 return originalFillText.apply(this, args); }; } return context; }; } return element; };3. 函数toString() 方法瑞数经常通过检查原生函数的toString()结果是否包含[native code]或是否被修改来检测环境。// 保护原生函数 const nativeFunctionToString Function.prototype.toString; Function.prototype.toString function() { // 对于某些特定函数返回固定的[native code]字符串 if (this window.alert || this window.prompt) { return function ${this.name}() { [native code] }; } // 其他函数返回原始的toString结果 return nativeFunctionToString.call(this); };4. 原型链污染检测瑞数可能会检查Object.prototype、Array.prototype等是否被添加了额外属性。// 确保原型链干净 delete Object.prototype.__defineGetter__; delete Object.prototype.__defineSetter__; // ... 清理其他可能被检测的属性5. 屏幕与视口属性// 覆盖屏幕属性使其看起来像普通桌面浏览器 Object.defineProperty(screen, width, { get: () 1920 }); Object.defineProperty(screen, height, { get: () 1080 }); Object.defineProperty(screen, availWidth, { get: () 1920 }); Object.defineProperty(screen, availHeight, { get: () 1040 }); Object.defineProperty(window, devicePixelRatio, { get: () 1 });6. WebGL 和 Canvas 指纹这是高级检测点。简单的补全可能不够需要更复杂的干扰。一个常见技巧是重写WebGLRenderingContext的getParameter和getExtension方法返回经过微调的值。// 示例干扰WebGL指纹 const originalGetParameter WebGLRenderingContext.prototype.getParameter; WebGLRenderingContext.prototype.getParameter function(parameter) { // 对UNMASKED_VENDOR_WEBGL等关键参数进行微调 if (parameter 37445) { // UNMASKED_VENDOR_WEBGL return Google Inc. (NVIDIA); // 模拟一个常见值 } if (parameter 37446) { // UNMASKED_RENDERER_WEBGL return ANGLE (NVIDIA, NVIDIA GeForce GTX 1060 6GB Direct3D11 vs_5_0 ps_5_0); } return originalGetParameter.call(this, parameter); };实操心得补环境是一个“猫鼠游戏”。没有一劳永逸的脚本。最好的方法是动态调试。你可以先用一个未补环境的浏览器打开目标网站在开发者工具控制台中运行一些常见的检测脚本网上可以找到记录下返回值。然后在你的补环境脚本中让这些检测返回与真实浏览器一致的值。另外瑞数6.5的检测是分阶段、按需加载的所以补环境脚本可能需要以“猴子补丁”的形式在页面加载初期就注入并持续监听和拦截后续的检测代码。3.3 RPC通信协议与接口设计我们的服务端需要提供一个稳定、明确的接口供客户端调用。上面例子中的/generate接口过于简单在实际生产中需要考虑更多因素。优化后的接口设计app.post(/api/v1/encrypt, async (req, res) { const { url, options } req.body; // options 可包含是否需要执行特定动作如点击、等待何种信号、自定义超时等 const taskId generateTaskId(); // 生成唯一任务ID // 立即响应告知任务已接收采用异步处理 res.json({ success: true, taskId, status: processing }); // 将任务推入队列由后台Worker处理 taskQueue.push({ taskId, url, options, resSocket }); // 假设通过WebSocket返回结果 }); // 或者保持同步但增加更多参数 app.post(/api/v1/encrypt/sync, async (req, res) { const { url, waitForSelector, execScript, timeout 30000 } req.body; // ... 处理逻辑 // 返回更详细的结果 res.json({ success: true, data: { cookies: { /* 提取到的所有相关cookies */ }, signs: { /* 可能多个sign */ }, userAgent: pageUA, pageTitle: await page.title(), // ... 其他可能有用的元数据 } }); });通信协议选择HTTP (RESTful API)最简单兼容性最好。对于请求-响应模式足够。缺点是如果生成过程很长30秒HTTP连接可能超时。WebSocket更适合长任务或需要服务端主动推送的场景。客户端发送请求后可以保持连接等待服务端处理完毕推送结果。这能避免HTTP超时问题。gRPC如果追求高性能和强类型接口定义可以考虑gRPC。但对于Python和Node.js的异构环境HTTP/JSON通常更简单。我建议初期使用HTTP长轮询或WebSocket。如果处理时间通常在几秒内用HTTP同步接口最简单。如果经常需要等待复杂交互或长时间执行就用WebSocket。4. 客户端调用与工程化实践4.1 Python客户端封装爬虫端需要调用上述的RPC服务。这里封装一个Python类。import aiohttp import asyncio import time import logging from typing import Dict, Optional, Any class RsEncryptRPCClient: def __init__(self, rpc_server_url: str http://localhost:3000): 初始化RPC客户端 :param rpc_server_url: 加密RPC服务的基础地址 self.base_url rpc_server_url.rstrip(/) self.session: Optional[aiohttp.ClientSession] None self.logger logging.getLogger(__name__) async def __aenter__(self): self.session aiohttp.ClientSession() return self async def __aexit__(self, exc_type, exc_val, exc_tb): if self.session: await self.session.close() async def get_cookie_and_sign(self, target_url: str, timeout: int 45) - Dict[str, Any]: 调用RPC服务获取指定URL的动态cookie和sign :param target_url: 目标网页URL :param timeout: 请求超时时间秒 :return: 包含cookie和sign的字典 if not self.session: self.session aiohttp.ClientSession() api_url f{self.base_url}/api/v1/encrypt/sync payload { url: target_url, timeout: timeout * 1000, # 毫秒 options: { waitUntil: networkidle, # 等待页面加载完成 # execScript: window.getSign(), # 如果需要执行特定JS # extraHeaders: {...} # 可以传递初始请求头 } } try: async with self.session.post(api_url, jsonpayload, timeouttimeout) as response: if response.status 200: result await response.json() if result.get(success): return result.get(data, {}) else: self.logger.error(fRPC服务返回错误: {result.get(error)}) raise Exception(fRPC Error: {result.get(error)}) else: text await response.text() self.logger.error(fHTTP {response.status}: {text}) raise Exception(fHTTP Error {response.status}) except asyncio.TimeoutError: self.logger.error(f获取加密参数超时URL: {target_url}) raise except aiohttp.ClientError as e: self.logger.error(f网络请求失败: {e}) raise # 使用示例 async def main(): async with RsEncryptRPCClient(http://your-encrypt-service:3000) as client: try: encrypt_data await client.get_cookie_and_sign(https://target-protected-site.com/page) # encrypt_data 可能包含 {cookies: {FSSBBIl1UgzbN7N80T: ...}, sign: abc123...} cookie_str fFSSBBIl1UgzbN7N80T{encrypt_data[cookies][FSSBBIl1UgzbN7N80T]} headers { Cookie: cookie_str, User-Agent: encrypt_data.get(userAgent, Mozilla/5.0 ...), # 通常sign会放在请求头或请求参数里根据实际观察决定 X-Sign: encrypt_data.get(sign, ) } # 然后用这个headers去发起真正的业务请求 async with aiohttp.ClientSession() as session: async with session.get(https://target-protected-site.com/api/data, headersheaders) as resp: data await resp.json() print(data) except Exception as e: print(f流程失败: {e}) if __name__ __main__: asyncio.run(main())4.2 服务端性能优化与稳定性直接为每个请求启动/关闭浏览器是不可行的。我们必须实现资源复用。1. 浏览器实例池Browser Pool创建一个管理多个浏览器实例的池子。当有加密请求到来时从池中取出一个空闲的浏览器或上下文来处理处理完毕后归还给池子而不是关闭。// 简化的浏览器池概念代码 class BrowserPool { constructor(maxBrowsers 5) { this.maxBrowsers maxBrowsers; this.browsers []; // 存放空闲浏览器实例 this.waitingQueue []; // 存放等待获取浏览器的请求 this.activeCount 0; } async acquire() { if (this.browsers.length 0) { return this.browsers.pop(); // 有空闲直接返回 } if (this.activeCount this.maxBrowsers) { // 没空闲但还没到上限创建新的 this.activeCount; return await this.createBrowser(); } // 已达上限排队等待 return new Promise((resolve) { this.waitingQueue.push(resolve); }); } release(browser) { if (this.waitingQueue.length 0) { // 有请求在等待直接把浏览器给下一个请求 const nextResolve this.waitingQueue.shift(); nextResolve(browser); } else { // 没有等待放回池子 this.browsers.push(browser); } } async createBrowser() { // 启动浏览器应用通用启动参数 return await chromium.launch({ headless: true, args: [--disable-blink-featuresAutomationControlled] }); } }在接口处理中app.post(/api/v1/encrypt/sync, async (req, res) { const browser await browserPool.acquire(); const context await browser.newContext(); // 为每个请求创建独立的上下文隔离cookie const page await context.newPage(); try { // ... 执行补环境和导航逻辑 res.json({ /* 结果 */ }); } finally { await context.close(); // 关闭上下文但浏览器实例还回池子 browserPool.release(browser); } });2. 页面/上下文复用与隔离更细粒度的复用是复用BrowserContext。每个上下文有自己的cookie和本地存储相互隔离比创建整个浏览器实例更快。你可以维护一个“上下文池”。但要注意一个上下文内打开过多页面可能会占用较多内存。3. 健康检查与自动重启浏览器实例或Playwright/Puppeteer连接可能因为内存泄漏、页面崩溃等原因变得不稳定。需要定期进行健康检查例如打开一个空白页看是否成功如果失败则销毁该实例并从池中移除然后创建新的实例补充。4. 请求队列与超时控制如果并发请求超过池容量必须有队列机制。同时每个请求必须设置合理的超时时间防止某个请求卡死长期占用浏览器资源。4.3 错误处理与重试机制在分布式环境下网络抖动、服务临时不可用、瑞数偶尔的随机检测失败都是常态。必须有健壮的错误处理和重试机制。客户端重试策略import tenacity from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type class RsEncryptRPCClient: # ... __init__ 等 ... retry( stopstop_after_attempt(3), # 最多重试3次 waitwait_exponential(multiplier1, min2, max10), # 指数退避等待 retryretry_if_exception_type((aiohttp.ClientError, asyncio.TimeoutError, Exception)), # 重试特定异常 reraiseTrue # 重试次数用尽后抛出原始异常 ) async def get_cookie_and_sign_with_retry(self, target_url: str, timeout: int 45) - Dict[str, Any]: 带重试的获取方法 return await self.get_cookie_and_sign(target_url, timeout)服务端容错服务端代码要有完善的try...catch捕获浏览器操作中的所有异常导航超时、选择器找不到、JS执行错误等并返回结构化的错误信息给客户端而不是让进程崩溃。5. 动态Cookie Sign生成策略深度解析通过RPC调用我们拿到了cookie和sign但理解它们的生成策略对于调试和应对变化至关重要。5.1 Cookie (FSSBBIl1UgzbN7N80T) 的构成瑞数的动态cookie通常是一长串编码字符串可能是Base64。解码后或通过调试观察其设置过程你会发现它通常包含以下信息时间戳cookie生成的时间。会话ID/指纹一个本次浏览器会话的唯一标识可能来源于Canvas指纹、WebGL指纹、浏览器特性哈希等。行为摘要可能记录了页面加载过程中的一些事件如鼠标移动、点击、滚动的哈希值。瑞数会注入监听器来收集这些数据。版本标识标识瑞数防护的版本如6.5。校验码对以上所有内容的一个签名防止篡改。在RPC环境中由于我们补全了环境并模拟了基本行为页面加载、可能的鼠标移动瑞数JS会基于这个“模拟环境”生成一个合法的cookie。关键在于这个环境在单次会话中需要保持一致性。如果你第一次用环境A生成cookie第二次请求却用了环境B即使补丁相同但某些动态属性如performance.timing不同生成的cookie就会失效。5.2 Sign参数的定位与生成Sign参数通常用于后续的API请求作为二次验证。它可能出现在请求头Header如X-Sign,Sign,Authorization等。URL查询参数Query如?signabc123。请求体Body尤其是POST请求的JSON或表单数据中。定位方法网络抓包在补好环境的浏览器中手动操作一次或通过自动化脚本使用开发者工具的Network面板查看向数据接口发起的请求仔细检查Headers、Payload、Query String。全局搜索在瑞数加载的JS文件中搜索关键词如sign、encrypt、encode、param等找到生成和添加sign的代码位置。Hook大法在补环境脚本中可以HookXMLHttpRequest.prototype.send和fetch函数在请求发出前打印出其参数从而捕获sign是如何被添加的。// 在补环境脚本中注入Hook (function() { const originalSend XMLHttpRequest.prototype.send; XMLHttpRequest.prototype.send function(body) { // 检查请求头或URL中是否有sign const headers this.getAllResponseHeaders?.(); // 注意获取请求头较复杂通常需hook setRequestHeader console.log(XHR发送:, this._url, Body:, body); return originalSend.call(this, body); }; const originalFetch window.fetch; window.fetch function(input, init) { console.log(Fetch调用:, input, Init:, init); return originalFetch.call(this, input, init); }; })();生成策略Sign通常是使用某种加密算法如AES、RSA、或自定义算法对一组特定参数可能包含时间戳、随机数、请求路径、cookie中的某个值等进行加密后得到的。通过RPC我们不需要逆向这个算法只需要让浏览器环境里的瑞数JS帮我们算好。我们的任务是确保触发sign计算的必要条件被满足。有时sign的计算依赖于页面中某个全局变量或某个特定函数被调用这就需要我们在RPC服务端在提取sign之前先执行一段JS代码来触发这个计算。// 在page.evaluate中可能需要在提取前执行某些操作 const sign await page.evaluate(async () { // 假设需要点击一个按钮或者调用一个全局函数来生成sign if (window.generateSignForAPI) { return await window.generateSignForAPI(/api/data/list); } // 或者监听网络请求从下一个请求中截取 return new Promise((resolve) { const originalFetch window.fetch; window.fetch function(...args) { if (args[0].includes(/api/data/list)) { console.log(捕获到API请求签名可能在Header:, args[1]?.headers); // 可以从args[1].headers里找到sign const sign args[1]?.headers?.[X-Sign]; if (sign) resolve(sign); } return originalFetch.apply(this, args); }; // 触发请求例如模拟点击 document.querySelector(#load-data-btn)?.click(); }); });5.3 应对瑞数升级与策略变动瑞数的JS代码和检测点会不定期更新。我们的RPC服务需要有感知和适应能力。监控与告警在爬虫客户端记录每次RPC调用获取cookie/sign的成功率。如果成功率在短时间内显著下降例如从99%跌至80%立即触发告警邮件、钉钉、Slack等提示可能瑞数已更新。动态补丁加载不要将补环境脚本硬编码在服务中。可以将其存放在外部文件或数据库中。服务启动时加载并支持热更新。当发现失败时可以快速更新补丁文件并重启服务或通过信号通知服务重新加载补丁。多版本环境备用有时瑞数会对不同地区或不同用户群分发不同版本的JS。你的RPC服务可以准备多套略有差异的补环境策略例如针对不同的userAgent或注入不同的补丁并在请求时根据某种规则如目标URL的域名选择使用哪一套。人工介入流程当自动更新补丁无法解决问题时需要人工进行逆向分析。此时拥有一个能够快速启动、并方便进行console.log调试的测试环境至关重要。可以写一个简单的调试脚本使用headless: false模式打开浏览器手动观察哪里出了问题。6. 常见问题排查与实战技巧6.1 问题速查表问题现象可能原因排查步骤与解决方案RPC服务返回cookie或sign为空1. 页面未加载成功。2. 补环境不充分瑞数JS执行失败或未执行。3. 提取结果的JS代码逻辑错误如选择器不对。1. 检查page.goto是否成功网络是否通畅目标URL是否可访问。2. 在服务端启动浏览器时设置headless: false并截图或录制视频查看页面是否正常渲染。3. 在page.evaluate中多打印一些调试信息例如console.log(document.cookie)查看浏览器控制台输出通过page.on(console, ...)监听。4. 逐步增加补环境脚本的强度对比与真实浏览器的差异。获取到的cookie/sign无效请求仍被拒1. cookie/sign已过期。2. 生成cookie/sign的环境与使用它的环境不一致如IP、User-Agent。3. sign对应的请求参数不匹配如时间戳、随机数。1.确保时效性cookie生成后应立即使用。检查瑞数cookie的有效期通常是会话级或很短时间。2.保持环境一致RPC服务返回的User-Agent等信息应在爬虫发起业务请求时原样使用。3.检查请求完整性使用Fiddler/Charles抓包对比通过RPC服务生成的请求和你手动在浏览器中操作的请求检查所有头信息、参数是否完全一致特别是Referer、Origin等。RPC服务超时或无响应1. 浏览器启动或页面加载太慢。2. 服务端代码有未处理的异常导致进程卡死。3. 浏览器池资源耗尽请求在队列中等待过久。1. 优化浏览器启动参数禁用不必要的功能如--disable-images。2. 为page.goto和page.evaluate等操作设置合理的超时时间并用try...catch包裹。3. 增加浏览器池容量或优化页面加载逻辑如直接跳转到核心JS执行页面而非首页。4. 实现服务端心跳检测和看门狗watchdog对僵死的浏览器进程进行强制回收。服务运行一段时间后内存泄漏1. 页面、上下文未正确关闭。2. 浏览器实例本身的内存泄漏。1.确保资源释放在finally块中务必调用await context.close()和await page.close()。2.定期重启为每个浏览器实例设置一个最大工作次数或最长生存时间达到阈值后强制重启该实例。3. 使用browser.process().pid监控浏览器进程内存超过阈值则重启。高并发下成功率下降1. 单个浏览器实例处理能力有限。2. 网站对同一IP的并发请求有频率限制。3. 服务器资源CPU、内存不足。1.横向扩展部署多个RPC服务实例客户端使用负载均衡。2.请求队列与限流在RPC服务端实现请求队列控制同时处理的请求数避免压垮浏览器。3.使用代理IP为不同的浏览器上下文配置不同的代理IP模拟不同用户。Playwright/Puppeteer可以通过context设置代理。6.2 独家避坑技巧“隐身模式”与用户数据目录启动浏览器时尽量使用无痕模式browser.newContext()而不是复用用户数据目录。这可以避免残留的cookie、缓存影响本次会话保证每次请求环境的“纯净”。同时禁用缓存也是一个好习惯await context.addInitScript(() { Object.defineProperty(navigator, storage, { get: () ({ estimate: () ({ usage: 0, quota: 0 }) }) }); })注意这只是简单示例实际需要更全面的补丁。鼠标移动与行为模拟瑞数6.5可能会检测页面上的鼠标移动事件。虽然补环境可以伪造一些属性但更逼真的做法是在page.goto后用page.mouse.move(x, y)模拟一段随机的鼠标移动轨迹。这能更好地欺骗基于行为分析的检测。优先使用page.addInitScript而非evaluate注入补丁addInitScript会在页面加载任何脚本之前执行确保我们的补丁在瑞数检测代码运行之前就位。而evaluate是在页面加载后执行可能为时已晚。监听页面错误和请求通过page.on(pageerror, ...)和page.on(requestfailed, ...)监听页面错误和失败请求。很多情况下瑞数检测失败会导致JS报错或加载特定资源失败这些日志是调试补环境是否成功的宝贵信息。准备一个“黄金标准”环境在本地维护一个永远能通过瑞数检测的浏览器环境可能是手动配置的、不自动更新的Chrome。当线上RPC服务失败时可以在这个“黄金环境”里手动操作对比两者在控制台输出、网络请求、Cookie设置等方面的差异快速定位补环境的缺失点。签名参数不一定只有一个仔细分析你可能发现除了sign还有ts时间戳、nonce随机数等参数一起发送。务必确保你的爬虫在发起业务请求时将这些参数全部、按原样带上缺一不可顺序最好也保持一致。这套“RPC调用动态环境补全”的方案经过多个高防护级别项目的实战检验在稳定性、可维护性和对抗升级能力上都远胜于传统的纯逆向或全浏览器自动化方案。它本质上是一种“以自动化对抗自动化”的策略将最复杂的识别与反识别对抗限制在一个专门化的服务内使得核心爬虫业务逻辑得以保持简洁和高效。
RPC调用与环境补全：高效破解瑞数6.5动态加密的工程实践
发布时间：2026/7/9 5:48:53
1. 项目概述与核心挑战最近在搞一个数据采集项目目标站点用了瑞数6.5做前端防护直接把我给拦在了门外。常规的请求头修改、代理IP轮换这些手段基本都失效了核心问题就出在那个动态生成的cookie和sign上。这玩意儿每次请求都会变而且跟你的浏览器环境、鼠标轨迹、页面加载时间等一系列因素强相关单纯靠抓包复制粘贴根本行不通。这其实就是典型的“人机验证”对抗场景瑞数通过一套复杂的JavaScript混淆和虚拟机VM技术在前端实时计算出一个动态令牌服务端再用同样的逻辑去验证不匹配就直接拒绝。面对这种级别的防护传统的“硬刚”JavaScript逆向把几千行混淆代码一点点抠出来还原不仅耗时巨大而且对方一更新你就得重来维护成本太高。经过一番调研和实战我发现结合“环境补全”与“RPC远程过程调用”的思路是目前应对瑞数6.5这类动态加密方案比较高效且稳定的策略。简单来说就是用一个真实的浏览器环境通常是Chrome的无头模式去执行瑞数的加密逻辑然后通过RPC将这个加密能力“暴露”出来供我们的Python爬虫程序远程调用。这样加密的核心黑盒逻辑由浏览器自己搞定我们只需要关心如何稳定地启动这个环境并与之通信。这个方法的核心价值在于“解耦”和“复用”。我们将复杂的JS执行环境与爬虫业务逻辑分离爬虫程序无需关心瑞数代码的具体实现只需像调用本地函数一样请求加密结果。同时一个补好的浏览器环境可以服务多个爬虫任务大大提升了资源利用率和开发效率。接下来我就把这次实战中关于RPC调用架构设计、动态cookie sign的生成策略以及那些踩坑后总结出的关键技巧详细拆解一遍。2. 核心思路环境补全与RPC调用架构2.1 为什么选择“补环境RPC”这条路面对瑞数通常有几种思路一是纯算法还原二是使用自动化浏览器如Selenium、Playwright三是补环境配合RPC。纯算法还原对逆向能力要求极高且瑞数的代码混淆和VM保护机制非常强更新频繁这条路性价比太低。使用自动化浏览器如playwright模拟真人操作虽然简单直接但资源消耗大、速度慢不适合大规模并发采集且浏览器指纹容易被高级风控识别。“补环境RPC”则是一种折中且高效的方案。它的核心思想是在一个精心修补过的、能够骗过瑞数检测的Node.js或浏览器环境中运行瑞数的核心加密JS并将生成cookie和sign的函数封装成服务接口。外部爬虫程序通过HTTP、WebSocket等RPC协议来调用这个接口获取加密参数。这样做的好处显而易见逆向工作量最小化我们不需要完全理解瑞数的所有加密算法只需要确保执行环境能被瑞数代码认为是“真实的浏览器”即可。这主要靠补全各种浏览器特有的API和属性如window、document、navigator等。执行环境隔离且稳定加密逻辑在一个独立、可控的进程中运行即使崩溃也不会影响主爬虫。我们可以专门优化和维护这个“加密服务”。高性能与可扩展一个加密服务进程可以处理多个并发请求。当爬虫需要高并发时可以部署多个加密服务实例形成集群通过负载均衡来分配请求。便于更新和维护当瑞数更新其JS代码时我们通常只需要检查环境补全是否依然有效或者微调RPC服务端的逻辑而不需要改动爬虫的主体代码。2.2 整体架构设计我采用的是一种经典的三层架构具体组件和流程如下[爬虫客户端 (Python)] | | (HTTP/WebSocket RPC 请求携带URL等参数) V [RPC服务网关 (可选如Nginx)] -- 负载均衡 -- | V [加密服务集群 (Node.js Puppeteer/Playwright)] | | (在补全的浏览器环境中执行JS生成cookie sign) V [返回加密结果 (JSON)] | | (携带cookie/sign的HTTP响应) --第一层爬虫客户端。用Python的requests或aiohttp库编写。当需要访问受瑞数保护的页面时它不直接发起请求而是先向加密服务发起一个RPC调用。第二层RPC服务网关。如果部署了多个加密服务实例需要一个网关来做负载均衡和路由。简单的可以用Nginx的upstream配置复杂的可以用专门的服务网格。对于初期或小规模应用可以直接让爬虫连接固定的加密服务地址。第三层加密服务集群。这是最核心的部分。每个服务实例本质上是一个Node.js Web服务器常用Express或Koa框架它内部通过Puppeteer或Playwright启动并控制一个Chrome浏览器实例。在浏览器中我们注入补环境脚本并加载目标页面或直接执行核心JS将生成加密参数的函数暴露给Node.js端再由Node.js通过HTTP接口提供给外部调用。2.3 技术选型Puppeteer vs Playwright在Node.js端控制浏览器主流选择是Puppeteer谷歌官方和Playwright微软出品。我两者都深度使用过简单对比一下在这次场景下的选择Puppeteer更成熟社区资源丰富特别是关于瑞数补环境的文章和代码片段大多基于它。API相对稳定。缺点是只支持Chromium系浏览器。Playwright后起之秀支持Chromium、Firefox、WebKit三大引擎。API设计更现代、一致自动等待等机制更智能。在处理复杂页面交互时可能更有优势。对于瑞数6.5其检测逻辑主要针对Chrome/Chromium因此两者都能胜任。我最终选择了Playwright主要原因是其更清晰的异步API和更好的错误处理机制在编写长时间运行的服务时感觉更稳健。但以下内容的核心思路对两者完全通用。3. 加密服务端核心实现详解3.1 服务端基础框架搭建首先初始化一个Node.js项目安装依赖。npm init -y npm install express playwright创建一个基础的服务文件server.js。这里使用Express作为HTTP服务器。const express require(express); const { chromium } require(playwright); // 或 require(puppeteer) const app express(); const port 3000; // 中间件解析JSON格式的请求体 app.use(express.json()); // 核心路由处理生成cookie和sign的请求 app.post(/generate, async (req, res) { const { targetUrl } req.body; // 假设客户端传递目标URL if (!targetUrl) { return res.status(400).json({ error: Missing targetUrl }); } let browser null; try { // 1. 启动浏览器 browser await chromium.launch({ headless: true, // 无头模式生产环境建议为true args: [ --disable-blink-featuresAutomationControlled, // 关键隐藏自动化特征 --no-sandbox, --disable-setuid-sandbox ] }); // 2. 创建浏览器上下文和页面 const context await browser.newContext(); const page await context.newPage(); // 3. 注入补环境脚本在页面加载任何内容之前 await page.addInitScript({ content: // 这里是补环境代码的核心区域详见下一节 Object.defineProperty(navigator, webdriver, { get: () undefined }); window.chrome { runtime: {} }; // ... 更多补丁 }); // 4. 导航到目标页面触发瑞数JS执行 await page.goto(targetUrl, { waitUntil: networkidle, timeout: 30000 }); // 5. 从页面中提取加密结果 // 方法A如果瑞数将结果直接写入cookie或全局变量可以通过evaluate获取 const cookieSign await page.evaluate(() { // 这个函数在浏览器上下文内执行 // 假设瑞数生成的cookie名为FSSBBIl1UgzbN7N80T const cookie document.cookie.match(/FSSBBIl1UgzbN7N80T([^;])/); // 假设sign在window对象上 const sign window._rsaSign || ; return { cookie: cookie ? cookie[1] : null, sign }; }); // 方法B更可靠的是监听特定的网络请求或执行特定的JS函数来获取 // 这里以方法A为例 res.json({ success: true, data: cookieSign, timestamp: Date.now() }); } catch (error) { console.error(RPC服务处理失败:, error); res.status(500).json({ success: false, error: error.message }); } finally { // 6. 关闭浏览器释放资源 if (browser) { await browser.close(); } } }); app.listen(port, () { console.log(加密RPC服务运行在 http://localhost:${port}); });这是一个最简化的框架。它暴露了一个/generate的POST接口接收targetUrl启动浏览器访问该URL并在补环境后尝试提取cookie和sign。注意在生产环境中绝不能为每个请求都启动和关闭一个浏览器这太耗时了。正确的做法是复用浏览器实例或页面上下文。我们可以启动一个浏览器然后为每个请求创建一个新的“隐身上下文”incognito context或标签页。甚至可以使用browser.newPage()在同一个上下文中创建新页面但要注意cookie的隔离问题。最佳实践是使用一个“浏览器池”来管理多个浏览器实例以支持更高并发。下面会讨论优化策略。3.2 瑞数6.5环境补全关键点补环境是成败的关键。瑞数会检测大量的浏览器属性和行为。我们的目标不是补全所有Web API而是补全那些它用于检测自动化工具的关键点。以下是一些必须处理的“重灾区”1. Navigator 对象// 清除或覆盖webdriver属性 Object.defineProperty(navigator, webdriver, { get: () undefined, configurable: true, enumerable: true // 注意有些检测会遍历属性需要可枚举 }); // 补全plugins和mimeTypes Object.defineProperty(navigator, plugins, { get: () [1, 2, 3, 4, 5], // 模拟有插件 configurable: true }); Object.defineProperty(navigator, mimeTypes, { get: () [1, 2, 3, 4, 5], configurable: true }); // 覆盖language和languages Object.defineProperty(navigator, language, { get: () zh-CN }); Object.defineProperty(navigator, languages, { get: () [zh-CN, zh, en] });2. Window Document 对象// 定义chrome对象非Chrome浏览器也需要 if (!window.chrome) { window.chrome { runtime: {}, loadTimes: function() {}, csi: function() {}, app: { /* ... */ } }; } // 覆盖某些只读属性如document.hidden等 Object.defineProperty(document, hidden, { get: () false }); Object.defineProperty(document, visibilityState, { get: () visible }); // 补全document.createElement的原始方法防止被检测hook const originalCreateElement document.createElement; document.createElement function(tagName) { const element originalCreateElement.call(document, tagName); // 如果是canvas可以为其添加一些指纹干扰 if (tagName.toLowerCase() canvas) { const originalGetContext element.getContext; element.getContext function(contextType) { const context originalGetContext.call(this, contextType); if (contextType 2d) { // 对2d context进行一些细微的、非确定性的修改增加指纹随机性 context.fillText function(...args) { // 轻微修改不影响渲染但改变指纹 return originalFillText.apply(this, args); }; } return context; }; } return element; };3. 函数toString() 方法瑞数经常通过检查原生函数的toString()结果是否包含[native code]或是否被修改来检测环境。// 保护原生函数 const nativeFunctionToString Function.prototype.toString; Function.prototype.toString function() { // 对于某些特定函数返回固定的[native code]字符串 if (this window.alert || this window.prompt) { return function ${this.name}() { [native code] }; } // 其他函数返回原始的toString结果 return nativeFunctionToString.call(this); };4. 原型链污染检测瑞数可能会检查Object.prototype、Array.prototype等是否被添加了额外属性。// 确保原型链干净 delete Object.prototype.__defineGetter__; delete Object.prototype.__defineSetter__; // ... 清理其他可能被检测的属性5. 屏幕与视口属性// 覆盖屏幕属性使其看起来像普通桌面浏览器 Object.defineProperty(screen, width, { get: () 1920 }); Object.defineProperty(screen, height, { get: () 1080 }); Object.defineProperty(screen, availWidth, { get: () 1920 }); Object.defineProperty(screen, availHeight, { get: () 1040 }); Object.defineProperty(window, devicePixelRatio, { get: () 1 });6. WebGL 和 Canvas 指纹这是高级检测点。简单的补全可能不够需要更复杂的干扰。一个常见技巧是重写WebGLRenderingContext的getParameter和getExtension方法返回经过微调的值。// 示例干扰WebGL指纹 const originalGetParameter WebGLRenderingContext.prototype.getParameter; WebGLRenderingContext.prototype.getParameter function(parameter) { // 对UNMASKED_VENDOR_WEBGL等关键参数进行微调 if (parameter 37445) { // UNMASKED_VENDOR_WEBGL return Google Inc. (NVIDIA); // 模拟一个常见值 } if (parameter 37446) { // UNMASKED_RENDERER_WEBGL return ANGLE (NVIDIA, NVIDIA GeForce GTX 1060 6GB Direct3D11 vs_5_0 ps_5_0); } return originalGetParameter.call(this, parameter); };实操心得补环境是一个“猫鼠游戏”。没有一劳永逸的脚本。最好的方法是动态调试。你可以先用一个未补环境的浏览器打开目标网站在开发者工具控制台中运行一些常见的检测脚本网上可以找到记录下返回值。然后在你的补环境脚本中让这些检测返回与真实浏览器一致的值。另外瑞数6.5的检测是分阶段、按需加载的所以补环境脚本可能需要以“猴子补丁”的形式在页面加载初期就注入并持续监听和拦截后续的检测代码。3.3 RPC通信协议与接口设计我们的服务端需要提供一个稳定、明确的接口供客户端调用。上面例子中的/generate接口过于简单在实际生产中需要考虑更多因素。优化后的接口设计app.post(/api/v1/encrypt, async (req, res) { const { url, options } req.body; // options 可包含是否需要执行特定动作如点击、等待何种信号、自定义超时等 const taskId generateTaskId(); // 生成唯一任务ID // 立即响应告知任务已接收采用异步处理 res.json({ success: true, taskId, status: processing }); // 将任务推入队列由后台Worker处理 taskQueue.push({ taskId, url, options, resSocket }); // 假设通过WebSocket返回结果 }); // 或者保持同步但增加更多参数 app.post(/api/v1/encrypt/sync, async (req, res) { const { url, waitForSelector, execScript, timeout 30000 } req.body; // ... 处理逻辑 // 返回更详细的结果 res.json({ success: true, data: { cookies: { /* 提取到的所有相关cookies */ }, signs: { /* 可能多个sign */ }, userAgent: pageUA, pageTitle: await page.title(), // ... 其他可能有用的元数据 } }); });通信协议选择HTTP (RESTful API)最简单兼容性最好。对于请求-响应模式足够。缺点是如果生成过程很长30秒HTTP连接可能超时。WebSocket更适合长任务或需要服务端主动推送的场景。客户端发送请求后可以保持连接等待服务端处理完毕推送结果。这能避免HTTP超时问题。gRPC如果追求高性能和强类型接口定义可以考虑gRPC。但对于Python和Node.js的异构环境HTTP/JSON通常更简单。我建议初期使用HTTP长轮询或WebSocket。如果处理时间通常在几秒内用HTTP同步接口最简单。如果经常需要等待复杂交互或长时间执行就用WebSocket。4. 客户端调用与工程化实践4.1 Python客户端封装爬虫端需要调用上述的RPC服务。这里封装一个Python类。import aiohttp import asyncio import time import logging from typing import Dict, Optional, Any class RsEncryptRPCClient: def __init__(self, rpc_server_url: str http://localhost:3000): 初始化RPC客户端 :param rpc_server_url: 加密RPC服务的基础地址 self.base_url rpc_server_url.rstrip(/) self.session: Optional[aiohttp.ClientSession] None self.logger logging.getLogger(__name__) async def __aenter__(self): self.session aiohttp.ClientSession() return self async def __aexit__(self, exc_type, exc_val, exc_tb): if self.session: await self.session.close() async def get_cookie_and_sign(self, target_url: str, timeout: int 45) - Dict[str, Any]: 调用RPC服务获取指定URL的动态cookie和sign :param target_url: 目标网页URL :param timeout: 请求超时时间秒 :return: 包含cookie和sign的字典 if not self.session: self.session aiohttp.ClientSession() api_url f{self.base_url}/api/v1/encrypt/sync payload { url: target_url, timeout: timeout * 1000, # 毫秒 options: { waitUntil: networkidle, # 等待页面加载完成 # execScript: window.getSign(), # 如果需要执行特定JS # extraHeaders: {...} # 可以传递初始请求头 } } try: async with self.session.post(api_url, jsonpayload, timeouttimeout) as response: if response.status 200: result await response.json() if result.get(success): return result.get(data, {}) else: self.logger.error(fRPC服务返回错误: {result.get(error)}) raise Exception(fRPC Error: {result.get(error)}) else: text await response.text() self.logger.error(fHTTP {response.status}: {text}) raise Exception(fHTTP Error {response.status}) except asyncio.TimeoutError: self.logger.error(f获取加密参数超时URL: {target_url}) raise except aiohttp.ClientError as e: self.logger.error(f网络请求失败: {e}) raise # 使用示例 async def main(): async with RsEncryptRPCClient(http://your-encrypt-service:3000) as client: try: encrypt_data await client.get_cookie_and_sign(https://target-protected-site.com/page) # encrypt_data 可能包含 {cookies: {FSSBBIl1UgzbN7N80T: ...}, sign: abc123...} cookie_str fFSSBBIl1UgzbN7N80T{encrypt_data[cookies][FSSBBIl1UgzbN7N80T]} headers { Cookie: cookie_str, User-Agent: encrypt_data.get(userAgent, Mozilla/5.0 ...), # 通常sign会放在请求头或请求参数里根据实际观察决定 X-Sign: encrypt_data.get(sign, ) } # 然后用这个headers去发起真正的业务请求 async with aiohttp.ClientSession() as session: async with session.get(https://target-protected-site.com/api/data, headersheaders) as resp: data await resp.json() print(data) except Exception as e: print(f流程失败: {e}) if __name__ __main__: asyncio.run(main())4.2 服务端性能优化与稳定性直接为每个请求启动/关闭浏览器是不可行的。我们必须实现资源复用。1. 浏览器实例池Browser Pool创建一个管理多个浏览器实例的池子。当有加密请求到来时从池中取出一个空闲的浏览器或上下文来处理处理完毕后归还给池子而不是关闭。// 简化的浏览器池概念代码 class BrowserPool { constructor(maxBrowsers 5) { this.maxBrowsers maxBrowsers; this.browsers []; // 存放空闲浏览器实例 this.waitingQueue []; // 存放等待获取浏览器的请求 this.activeCount 0; } async acquire() { if (this.browsers.length 0) { return this.browsers.pop(); // 有空闲直接返回 } if (this.activeCount this.maxBrowsers) { // 没空闲但还没到上限创建新的 this.activeCount; return await this.createBrowser(); } // 已达上限排队等待 return new Promise((resolve) { this.waitingQueue.push(resolve); }); } release(browser) { if (this.waitingQueue.length 0) { // 有请求在等待直接把浏览器给下一个请求 const nextResolve this.waitingQueue.shift(); nextResolve(browser); } else { // 没有等待放回池子 this.browsers.push(browser); } } async createBrowser() { // 启动浏览器应用通用启动参数 return await chromium.launch({ headless: true, args: [--disable-blink-featuresAutomationControlled] }); } }在接口处理中app.post(/api/v1/encrypt/sync, async (req, res) { const browser await browserPool.acquire(); const context await browser.newContext(); // 为每个请求创建独立的上下文隔离cookie const page await context.newPage(); try { // ... 执行补环境和导航逻辑 res.json({ /* 结果 */ }); } finally { await context.close(); // 关闭上下文但浏览器实例还回池子 browserPool.release(browser); } });2. 页面/上下文复用与隔离更细粒度的复用是复用BrowserContext。每个上下文有自己的cookie和本地存储相互隔离比创建整个浏览器实例更快。你可以维护一个“上下文池”。但要注意一个上下文内打开过多页面可能会占用较多内存。3. 健康检查与自动重启浏览器实例或Playwright/Puppeteer连接可能因为内存泄漏、页面崩溃等原因变得不稳定。需要定期进行健康检查例如打开一个空白页看是否成功如果失败则销毁该实例并从池中移除然后创建新的实例补充。4. 请求队列与超时控制如果并发请求超过池容量必须有队列机制。同时每个请求必须设置合理的超时时间防止某个请求卡死长期占用浏览器资源。4.3 错误处理与重试机制在分布式环境下网络抖动、服务临时不可用、瑞数偶尔的随机检测失败都是常态。必须有健壮的错误处理和重试机制。客户端重试策略import tenacity from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type class RsEncryptRPCClient: # ... __init__ 等 ... retry( stopstop_after_attempt(3), # 最多重试3次 waitwait_exponential(multiplier1, min2, max10), # 指数退避等待 retryretry_if_exception_type((aiohttp.ClientError, asyncio.TimeoutError, Exception)), # 重试特定异常 reraiseTrue # 重试次数用尽后抛出原始异常 ) async def get_cookie_and_sign_with_retry(self, target_url: str, timeout: int 45) - Dict[str, Any]: 带重试的获取方法 return await self.get_cookie_and_sign(target_url, timeout)服务端容错服务端代码要有完善的try...catch捕获浏览器操作中的所有异常导航超时、选择器找不到、JS执行错误等并返回结构化的错误信息给客户端而不是让进程崩溃。5. 动态Cookie Sign生成策略深度解析通过RPC调用我们拿到了cookie和sign但理解它们的生成策略对于调试和应对变化至关重要。5.1 Cookie (FSSBBIl1UgzbN7N80T) 的构成瑞数的动态cookie通常是一长串编码字符串可能是Base64。解码后或通过调试观察其设置过程你会发现它通常包含以下信息时间戳cookie生成的时间。会话ID/指纹一个本次浏览器会话的唯一标识可能来源于Canvas指纹、WebGL指纹、浏览器特性哈希等。行为摘要可能记录了页面加载过程中的一些事件如鼠标移动、点击、滚动的哈希值。瑞数会注入监听器来收集这些数据。版本标识标识瑞数防护的版本如6.5。校验码对以上所有内容的一个签名防止篡改。在RPC环境中由于我们补全了环境并模拟了基本行为页面加载、可能的鼠标移动瑞数JS会基于这个“模拟环境”生成一个合法的cookie。关键在于这个环境在单次会话中需要保持一致性。如果你第一次用环境A生成cookie第二次请求却用了环境B即使补丁相同但某些动态属性如performance.timing不同生成的cookie就会失效。5.2 Sign参数的定位与生成Sign参数通常用于后续的API请求作为二次验证。它可能出现在请求头Header如X-Sign,Sign,Authorization等。URL查询参数Query如?signabc123。请求体Body尤其是POST请求的JSON或表单数据中。定位方法网络抓包在补好环境的浏览器中手动操作一次或通过自动化脚本使用开发者工具的Network面板查看向数据接口发起的请求仔细检查Headers、Payload、Query String。全局搜索在瑞数加载的JS文件中搜索关键词如sign、encrypt、encode、param等找到生成和添加sign的代码位置。Hook大法在补环境脚本中可以HookXMLHttpRequest.prototype.send和fetch函数在请求发出前打印出其参数从而捕获sign是如何被添加的。// 在补环境脚本中注入Hook (function() { const originalSend XMLHttpRequest.prototype.send; XMLHttpRequest.prototype.send function(body) { // 检查请求头或URL中是否有sign const headers this.getAllResponseHeaders?.(); // 注意获取请求头较复杂通常需hook setRequestHeader console.log(XHR发送:, this._url, Body:, body); return originalSend.call(this, body); }; const originalFetch window.fetch; window.fetch function(input, init) { console.log(Fetch调用:, input, Init:, init); return originalFetch.call(this, input, init); }; })();生成策略Sign通常是使用某种加密算法如AES、RSA、或自定义算法对一组特定参数可能包含时间戳、随机数、请求路径、cookie中的某个值等进行加密后得到的。通过RPC我们不需要逆向这个算法只需要让浏览器环境里的瑞数JS帮我们算好。我们的任务是确保触发sign计算的必要条件被满足。有时sign的计算依赖于页面中某个全局变量或某个特定函数被调用这就需要我们在RPC服务端在提取sign之前先执行一段JS代码来触发这个计算。// 在page.evaluate中可能需要在提取前执行某些操作 const sign await page.evaluate(async () { // 假设需要点击一个按钮或者调用一个全局函数来生成sign if (window.generateSignForAPI) { return await window.generateSignForAPI(/api/data/list); } // 或者监听网络请求从下一个请求中截取 return new Promise((resolve) { const originalFetch window.fetch; window.fetch function(...args) { if (args[0].includes(/api/data/list)) { console.log(捕获到API请求签名可能在Header:, args[1]?.headers); // 可以从args[1].headers里找到sign const sign args[1]?.headers?.[X-Sign]; if (sign) resolve(sign); } return originalFetch.apply(this, args); }; // 触发请求例如模拟点击 document.querySelector(#load-data-btn)?.click(); }); });5.3 应对瑞数升级与策略变动瑞数的JS代码和检测点会不定期更新。我们的RPC服务需要有感知和适应能力。监控与告警在爬虫客户端记录每次RPC调用获取cookie/sign的成功率。如果成功率在短时间内显著下降例如从99%跌至80%立即触发告警邮件、钉钉、Slack等提示可能瑞数已更新。动态补丁加载不要将补环境脚本硬编码在服务中。可以将其存放在外部文件或数据库中。服务启动时加载并支持热更新。当发现失败时可以快速更新补丁文件并重启服务或通过信号通知服务重新加载补丁。多版本环境备用有时瑞数会对不同地区或不同用户群分发不同版本的JS。你的RPC服务可以准备多套略有差异的补环境策略例如针对不同的userAgent或注入不同的补丁并在请求时根据某种规则如目标URL的域名选择使用哪一套。人工介入流程当自动更新补丁无法解决问题时需要人工进行逆向分析。此时拥有一个能够快速启动、并方便进行console.log调试的测试环境至关重要。可以写一个简单的调试脚本使用headless: false模式打开浏览器手动观察哪里出了问题。6. 常见问题排查与实战技巧6.1 问题速查表问题现象可能原因排查步骤与解决方案RPC服务返回cookie或sign为空1. 页面未加载成功。2. 补环境不充分瑞数JS执行失败或未执行。3. 提取结果的JS代码逻辑错误如选择器不对。1. 检查page.goto是否成功网络是否通畅目标URL是否可访问。2. 在服务端启动浏览器时设置headless: false并截图或录制视频查看页面是否正常渲染。3. 在page.evaluate中多打印一些调试信息例如console.log(document.cookie)查看浏览器控制台输出通过page.on(console, ...)监听。4. 逐步增加补环境脚本的强度对比与真实浏览器的差异。获取到的cookie/sign无效请求仍被拒1. cookie/sign已过期。2. 生成cookie/sign的环境与使用它的环境不一致如IP、User-Agent。3. sign对应的请求参数不匹配如时间戳、随机数。1.确保时效性cookie生成后应立即使用。检查瑞数cookie的有效期通常是会话级或很短时间。2.保持环境一致RPC服务返回的User-Agent等信息应在爬虫发起业务请求时原样使用。3.检查请求完整性使用Fiddler/Charles抓包对比通过RPC服务生成的请求和你手动在浏览器中操作的请求检查所有头信息、参数是否完全一致特别是Referer、Origin等。RPC服务超时或无响应1. 浏览器启动或页面加载太慢。2. 服务端代码有未处理的异常导致进程卡死。3. 浏览器池资源耗尽请求在队列中等待过久。1. 优化浏览器启动参数禁用不必要的功能如--disable-images。2. 为page.goto和page.evaluate等操作设置合理的超时时间并用try...catch包裹。3. 增加浏览器池容量或优化页面加载逻辑如直接跳转到核心JS执行页面而非首页。4. 实现服务端心跳检测和看门狗watchdog对僵死的浏览器进程进行强制回收。服务运行一段时间后内存泄漏1. 页面、上下文未正确关闭。2. 浏览器实例本身的内存泄漏。1.确保资源释放在finally块中务必调用await context.close()和await page.close()。2.定期重启为每个浏览器实例设置一个最大工作次数或最长生存时间达到阈值后强制重启该实例。3. 使用browser.process().pid监控浏览器进程内存超过阈值则重启。高并发下成功率下降1. 单个浏览器实例处理能力有限。2. 网站对同一IP的并发请求有频率限制。3. 服务器资源CPU、内存不足。1.横向扩展部署多个RPC服务实例客户端使用负载均衡。2.请求队列与限流在RPC服务端实现请求队列控制同时处理的请求数避免压垮浏览器。3.使用代理IP为不同的浏览器上下文配置不同的代理IP模拟不同用户。Playwright/Puppeteer可以通过context设置代理。6.2 独家避坑技巧“隐身模式”与用户数据目录启动浏览器时尽量使用无痕模式browser.newContext()而不是复用用户数据目录。这可以避免残留的cookie、缓存影响本次会话保证每次请求环境的“纯净”。同时禁用缓存也是一个好习惯await context.addInitScript(() { Object.defineProperty(navigator, storage, { get: () ({ estimate: () ({ usage: 0, quota: 0 }) }) }); })注意这只是简单示例实际需要更全面的补丁。鼠标移动与行为模拟瑞数6.5可能会检测页面上的鼠标移动事件。虽然补环境可以伪造一些属性但更逼真的做法是在page.goto后用page.mouse.move(x, y)模拟一段随机的鼠标移动轨迹。这能更好地欺骗基于行为分析的检测。优先使用page.addInitScript而非evaluate注入补丁addInitScript会在页面加载任何脚本之前执行确保我们的补丁在瑞数检测代码运行之前就位。而evaluate是在页面加载后执行可能为时已晚。监听页面错误和请求通过page.on(pageerror, ...)和page.on(requestfailed, ...)监听页面错误和失败请求。很多情况下瑞数检测失败会导致JS报错或加载特定资源失败这些日志是调试补环境是否成功的宝贵信息。准备一个“黄金标准”环境在本地维护一个永远能通过瑞数检测的浏览器环境可能是手动配置的、不自动更新的Chrome。当线上RPC服务失败时可以在这个“黄金环境”里手动操作对比两者在控制台输出、网络请求、Cookie设置等方面的差异快速定位补环境的缺失点。签名参数不一定只有一个仔细分析你可能发现除了sign还有ts时间戳、nonce随机数等参数一起发送。务必确保你的爬虫在发起业务请求时将这些参数全部、按原样带上缺一不可顺序最好也保持一致。这套“RPC调用动态环境补全”的方案经过多个高防护级别项目的实战检验在稳定性、可维护性和对抗升级能力上都远胜于传统的纯逆向或全浏览器自动化方案。它本质上是一种“以自动化对抗自动化”的策略将最复杂的识别与反识别对抗限制在一个专门化的服务内使得核心爬虫业务逻辑得以保持简洁和高效。
 与 FISTA：从 LASSO 到 O(1/k²) 收敛速度的 3 种推导)
