企业官网建设流程全解析

我最早遇到acw_sc__v2和无限debugger这两样东西，是在采集雪球网讨论数据的时候。当时打开开发者工具准备抓包，页面瞬间卡死在debugger断点上，网络请求一个都看不到。关掉断点，请求才能发出去，但每次请求的Cookie里都带了一个动态变化的acw_sc__v2，去掉就返回JS挑战页。那段时间我花了两天把这条链路彻底摸了一遍，这篇文章就把整个过程、绕过方案、逆向思路和踩过的坑都写出来，给同样在搞数据采集、前端安全或者反爬研究的同学一个参考。

雪球这套反爬体系并非单个技术点，而是由两道关卡组成：一道是无限debugger，用来卡住所有想打开开发者工具做分析的人；另一道是acw_sc__v2动态Cookie，用来拦截不执行JS的纯HTTP客户端。两道关卡互相配合，如果不先把第一个解决，后面连定位的机会都没有。

1. 雪球网反爬体系初探：acw_sc__v2和无限debugger到底是什么

1.1 从第一次请求说起：雪球网到底拦了什么

假设你现在用requests直接请求雪球网的行情页面，返回的内容其实是正常的HTML，但页面里没有任何接口数据，只有一段又一段等待浏览器执行的JS。直接拿正则去抓HTML里的目标内容，抓到的基本都是空壳。这时候如果你换成浏览器访问同一个地址，页面又能正常展示数据，说明服务器端对访问客户端的类型有严格判断。

真正的问题出现在打开开发者工具的那一刻。按下F12，Chrome的Sources面板自动跳到一段代码上，页面顶部出现一行黄色的提示条，显示“Paused in debugger”。点击继续执行，不到100毫秒又停在同一个位置，反复操作几轮之后你会意识到：有人在JavaScript里埋了定时触发的debugger语句。

这就是雪球网的第一道防线。它的目标不是拦截数据请求，而是拦截数据分析者。任何想通过网络面板查看请求详情、想在Sources里打断点调试JS的人，都会被困在这条断点循环里。只要你不找到绕过方式，后续工作基本没法推进。

1.2 acw_sc__v2的生成链路：阿里云WAF的JS挑战机制

等绕过无限debugger，重新刷新页面并观察网络请求，你会发现浏览器发出的每个请求里都带着一个acw_sc__v2的Cookie。去掉这个Cookie再直接请求，雪球网会返回一个掐头去尾的JS挑战页，里面只有一段脚本，没有任何业务内容。

这个acw_sc__v2属于阿里云WAF的JS校验能力，官方叫法是JS Challenge或动态JS验证。它的运行流程大致是：

1. 客户端第一次访问，没有acw_sc__v2，WAF识别为可疑请求，返回一个JS挑战页。
2. JS挑战页里包含一段脚本和一个变量arg1，脚本会基于arg1计算出acw_sc__v2的值。
3. 浏览器把计算出的值写入Cookie，并自动刷新页面。
4. 刷新后的请求带上acw_sc__v2，WAF验证通过，返回真实内容。

关键在于这个Cookie不是服务器下发的，而是客户端本地JS算出来的，所以普通爬虫不去执行页面JS，就永远拿不到合法Cookie。WAF通过这种“执行JS”的隐性考验，变相验证了访问者是一个真实浏览器环境。

1.3 无限debugger在整条链路中的角色

把acw_sc__v2的生成链路拉通之后，再回来看无限debugger，它的定位就很清楚了：保护生成算法不被逆向。acw_sc__v2的计算逻辑混在雪球的混淆JS里，正常情况下只要顺着Sources面板找，总能找到核心代码。但雪球把debugger语句和业务逻辑放在同一个脚本里，开发者工具一开就不断触发断点，让你根本没法静下心来看代码。

我当时抓到的大致实现模式是：

setInterval(function() { debugger; }, 100);

有些实现更阴，它不是直接用debugger关键字，而是把字符串拆开动态构造：

setInterval(function() { Function("de" + "bug" + "ger")(); }, 50);

这种写法让搜索debugger关键字的人在全局搜索时扑个空，必须花时间分析变量拼接，进一步拖慢逆向进度。可以说，无限debugger负责劝退，acw_sc__v2负责拦截，两道关卡配合下来，让直接拿requests或者普通脚本采集的人基本无从下手。

2. 无限debugger正面交锋：四种绕过方案实测

2.1 为什么无限debugger能让人寸步难行

无限debugger能卡住人，本质上是利用了开发者工具的默认行为：只要脚本执行到debugger语句，无论这个断点是不是你手动设置的，浏览器都会强制暂停。既然它是浏览器给开发者的正常调试能力，那就一定有对应的开关和控制方法。难点不在于技术上无法绕过，而在于很多人不知道这些开关的存在。

我当时在一个群里问了很多人，发现不少人的处理方式是：打开开发者工具后直接硬扛，一边疯狂点击“继续执行”，一边快速切换到Network面板看数据。这种操作不是不可行，但手工点击恢复的速度往往赶不上setInterval触发的速度，而且页面会变得卡顿，观察请求细节基本靠运气。后面我试了四种不同的方案，各有适用场景。

2.2 方案一：Deactivate breakpoints（Ctrl+F8）

最快的一种方式：打开Sources面板后，按下Ctrl+F8，或者点击工具条上的“Toggle breakpoints”按钮。这个操作会全局停用所有断点，包括代码里的debugger语句。

实际体验是按下快捷键之后立刻见效，页面恢复流畅，后续再也不会因为debugger语句而暂停。代价是手动设置的断点也会全部失效，如果中途想调试其他JavaScript代码，还得再按一次Ctrl+F8恢复。所以这个方案适合前期快速抓包观察请求流程，不适合长期调试。

2.3 方案二：Add script to ignore list（脚本黑名单）

这个方案更精准。在Sources面板左侧找到触发断点的脚本，右键点击文件，选择“Add script to ignore list”，Chrome就会在调试时直接跳过这个脚本里的所有断点，包括debugger语句。

用这个方案的前提是先确认罪魁祸首是哪个文件。雪球的脚本是动态加载执行的，经常显示为VMxxx，并不一定是正常的JS文件名，但同样可以右键加入忽略列表。加入之后，那个脚本就进了黑名单，既不会再触发暂停，也不会干扰其他文件的调试。

这个方案的坑在于：如果触发debugger的脚本和生成acw_sc__v2的脚本是同一个文件，那后续想在那个文件里打断点逆向算法时，也会被一起忽略。解决办法是把脚本从ignore list里移除，或者切换回Deactivate breakpoints模式。我用这个方案跑通整条逆向链路后，发现只要不点那个脚本的断点，其实影响不大。

2.4 方案三：Hook构造函数改写debugger指令

如果浏览器层面的开关因为某些原因没法用，比如网站检测到了DevTools状态，或者脚本通过动态拼接方式生成debugger字符串，那就需要从JavaScript本身下手。

核心思路是Hook住Function构造函数，在动态执行代码之前把包含debugger的字符串替换掉。我实际测试过的一版代码是这样的：

(function () { var original = Function.prototype.constructor; Function.prototype.constructor = function () { var args = Array.prototype.slice.call(arguments); if (typeof args[args.length - 1] === 'string') { args[args.length - 1] = args[args.length - 1].replace(/debugger/g, ''); } return original.apply(this, args); }; })();

这段代码在Console里执行后，再刷新页面，能拦截掉通过Function构造执行的debugger。缺点是对直接写在脚本源码里的字面量debugger语句无效，因为那些语句在解析阶段就存在，不会经过Function构造函数。实际场景中，这两类情况往往同时存在，所以我把方案三当成辅助手段，主要配合前面两个方案一起用。

2.5 方案四：Never pause here

最后一个方案是从断点行本身入手。如果已经定位到具体是哪一行触发的debugger，可以直接在那一行的行号上右键，选择“Never pause here”。Chrome会把这个位置加入忽略列表，之后执行到这里直接跳过，不再暂停。

这个方案在调试过程中非常实用。比如你想在某一行打断点观察变量，但发现这一行旁边有debugger干扰，就右键设置“Never pause here”，把干扰去掉，再在旁边加自己的断点。总体而言，我的建议是：快速浏览用Ctrl+F8，固定分析某个脚本用ignore list，精准调试用Never pause here，三套组合拳下来，无限debugger基本形同虚设。

3. acw_sc__v2加密逆向全记录：从断点到算法还原

3.1 定位加密入口：在VM上下文里找到关键函数

绕过无限debugger只是热身，真正的重头戏是从混淆JS里挖出acw_sc__v2的生成算法。我第一次操作时走了不少弯路，后来总结出一套相对顺畅的定位流程。

第一步，先清理掉所有断点和忽略列表，正常访问雪球首页，在Network面板里找到最开始返回的HTML请求。第一次访问时，这个HTML通常就是JS挑战页，里面有一段内联脚本，会定义一个变量，常见变量名是arg1：

<script> var arg1='%xx%xx%xx...'; </script>

这个arg1就是生成acw_sc__v2的输入原料。记下它的原始值，后续做算法验证时要用。

第二步，在Sources面板里搜索acw_sc__v2这个字符串。如果直接搜索不到，可能是因为代码混淆时把它拆开拼接了，这时候换一种思路，搜索“cookie”或者“expires”这些设置Cookie时的固定写法，找到document.cookie =的赋值语句。在赋值语句那一行打断点，刷新页面，然后查看调用栈，就能回溯到真正生成Cookie值的函数。

定位的时候建议配合浏览器右上角的格式化按钮（Pretty print），把压缩过的JS代码展开，阅读体验会好很多。雪球的脚本在格式化之后，整体逻辑会清晰不少。

3.2 扣代码还是理逻辑：为什么我选择重写算法

找到生成函数后，摆在我面前的有两条路。第一条是把JS函数整体扣下来，放到Node.js或者PyExecJS里原样执行，再把结果拿回来用。这个方案看起来最省事，但实际操作中非常痛苦。因为那段JS里充斥着环境检测和DOM操作，比如document、window、navigator对象，有的还夹着Canvas指纹读取、鼠标事件监听。在纯Node.js环境里没有这些对象，必须一个一个用mock对象补环境，经常是补完一个又冒出另一个。

第二条路是读懂算法，然后用Python或Node.js重写一遍。这条路前期慢，但一旦跑通，后续维护成本极低，而且不依赖任何重型的JS解释环境。我最后选择了第二条。

逆向时有几个原则值得分享：先别急着逐行读代码，先把输入和输出搞清楚。输入就是arg1字符串，输出是浏览器实际种下的acw_sc__v2值。然后在本地用Node.js写个小脚本，用同样的输入跑一遍自己的算法逻辑，跟真实输出对比，对上了再继续，对不上就回头检查。

3.3 核心算法拆解：字节位移、异或和16进制混淆

我逆向到的雪球acw_sc__v2生成逻辑，核心可以拆成四个步骤：

1. 用%分割arg1字符串，得到若干个十六进制片段。
2. 去掉分割后的第一个空元素，从第二个片段开始处理。
3. 每个片段用parseInt(item, 16)转成整数。
4. 将这个整数与固定密钥做异或运算，这里密钥是十进制31，也就是十六进制的0x1F，异或结果再用String.fromCharCode()转成字符，依次拼接。

这个算法本质是一种编码混淆，不是强加密。它没有密钥交换，没有哈希校验，只要知道异或的常量值，任何人都能轻松还原。用伪代码表示：

result = '' for item in arg1.split('%')[1:]: code = parseInt(item, 16) decoded = code XOR 31 result += String.fromCharCode(decoded) return result

密钥31为什么是31而不是其他数字？其实没有高深的道理，就是一个随机选定的常量，写在混淆JS里。不同网站的WAF实现可能选择不同的密钥，比如我后来分析其他使用同类WAF的网站时，见过0x1C、0x24、0x17这些值。所以逆向时不能假设密钥固定，要在JS代码里找到那个异或的源操作数。

3.4 验证算法正确性：用Node.js快速跑通

在写完整的Python实现之前，我习惯先用Node.js把核心算法跑通。因为浏览器本身执行的就是JS，用Node.js能最快地对照验证。

function generateAcwScV2(arg1) { let result = ''; const parts = arg1.split('%'); for (let i = 1; i < parts.length; i++) { if (parts[i] === '') continue; result += String.fromCharCode(parseInt(parts[i], 16) ^ 31); } return result; } // 替换成实际抓到的arg1 const arg1 = '%46%72%6f%6d...'; console.log(generateAcwScV2(arg1));

跑出来的结果如果和浏览器Network面板里看到的acw_sc__v2值完全相同，说明算法理解正确。如果不一致，检查三件事：第一，分割符是不是%；第二，异或的常量是不是31；第三，有没有漏掉arg1里的特殊片段，比如混入Unicode编码%uXXXX的情况。这类特殊编码需要先额外处理一次，不能直接用parseInt(item, 16)解析。

4. 用Python复现acw_sc__v2生成器

4.1 为什么不推荐直接用Selenium

很多人在这一步会选择Selenium或Playwright，开个无头浏览器让页面自己生成Cookie。坦白说这个方案确实能跑通，但我不推荐把它作为长期方案。

原因有三个：一是效率低，每次请求都要启动一个完整浏览器进程，内存和CPU占用都很大，并发处理更是麻烦；二是自动化特征明显，虽然无头浏览器在慢慢“隐身”，但WAF依然可以通过webdriver标记、浏览器指纹、JS执行上下文等维度识别自动化环境；三是维护成本高，浏览器版本一升级，相关驱动就要跟着升，稳定性没法保证。

既然acw_sc__v2的生成算法已经逆向出来了，用纯Python手写生成器才是性能最好、最可控的方案。

4.2 完整Python代码实现

下面这份代码是我验证过的实现，分两步完成请求：第一步访问目标页面拿到挑战页，从HTML里提取arg1；第二步计算acw_sc__v2并写入Session，再重新请求目标地址。

import requests import re def generate_acw_sc_v2(arg1: str) -> str: result = "" parts = arg1.split("%") for item in parts[1:]: if not item: continue result += chr(int(item, 16) ^ 31) return result def get_xueqiu_page(url: str) -> str: session = requests.Session() headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 " "(KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36", "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif," "image/webp,*/*;q=0.8", "Accept-Language": "zh-CN,zh;q=0.9", "Referer": "https://xueqiu.com/", "Connection": "keep-alive", } # 第一次请求，触发JS挑战页 resp = session.get(url, headers=headers, timeout=10) text = resp.text # 从内联JS里提取arg1 match = re.search(r"var arg1='([^']+)'", text) if not match: # 如果没有arg1，说明当前请求没有被挑战，直接返回页面内容 return text arg1 = match.group(1) acw_value = generate_acw_sc_v2(arg1) # 将计算出的acw_sc__v2写入Session，并再次请求目标页面 session.cookies.set("acw_sc__v2", acw_value) resp2 = session.get(url, headers=headers, timeout=10) return resp2.text if __name__ == "__main__": html = get_xueqiu_page("https://xueqiu.com/hq") print(len(html))

这里有几个细节要提醒一下。第一次请求的Session不能丢弃，因为响应头里的acw_tc等Cookie值代表会话状态，必须保留。其次，session.cookies.set时要确认没有把之前的Cookie覆盖掉，最好在设置后打印一下session.cookies看看全貌。

4.3 带Cookie发起请求的完整流程

上面的代码把两次请求封装在同一个Session里，这个设计是有原因的。雪球WAF校验acw_sc__v2时，不只是看这个Cookie存在不存在，还会结合其他Cookie和请求头做综合判断。如果第二次请求换了一个完全没有历史的Session，只带acw_sc__v2，被识别的概率会大幅上升。

另外要注意的是，如果你要请求的不是HTML页面，而是接口，逻辑也是一样的：先走一遍挑战流程拿到合法的acw_sc__v2，再带着这个Cookie请求真实接口。可以封装一个通用的方法，判断当前Session里有没有acw_sc__v2，没有就先触发挑战页，有就直接请求。这样对后续批量采集会友好很多。

5. 实测踩坑记录：Cookie重写、请求头顺序和IP风控

5.1 坑一：Cookie被强制重写

我第一次跑通代码如下逻辑后，发现第二次请求依然返回挑战页。抓包对比浏览器和requests的请求头，最后定位到问题是Cookie被覆盖了。

场景是这样的：第一次请求挑战页时，服务端会在响应头里下发Set-Cookie，其中有一个acw_sc__v2的初始占位值，也可能是过期值。requests的Session会自动处理这些Set-Cookie，把我手动设置的acw_sc__v2覆盖掉。

解决方法是：在发起第二次请求前，先检查session.cookies里acw_sc__v2的实际值，如果不对就再set一次。我在代码里加了一句调试输出，打印cookies的完整内容，才意识到这个坑。

更稳妥的做法是，第一次请求后先不急着set Cookie，而是等到所有需要的Cookie都拿到手，再统一覆盖acw_sc__v2。重点要保证Session里acw_sc__v2的值始终是自己计算出来的那一个，而不是服务端下发的初始值。

5.2 坑二：请求头顺序对结果的影响

在连续多次实验后，我还遇到过一个比较“玄学”的情况：同样的Cookie，同样的IP，只改请求头字段的顺序，成功率就不一样。这大概率是WAF在做HTTP头部特征识别时，对某些字段顺序有隐式要求。

为了最大程度贴近真实浏览器，我最终固定了一套完整的请求头，主要包括：

• User-Agent
• Accept
• Accept-Language
• Sec-Fetch-Dest
• Sec-Fetch-Mode
• Sec-Fetch-Site
• Sec-Ch-Ua
• Sec-Ch-Ua-Platform

如果是XHR请求，还需要加X-Requested-With: XMLHttpRequest。实测下来，把这一套补齐之后，被拦截的概率明显下降。如果某天的请求还是被拦，优先检查是不是请求头里漏了特定的Sec-Fetch字段。

5.3 坑三：高频请求触发风控怎么办

即使acw_sc__v2算法完全正确，Cookie也带上了，请求头也模拟了，只要请求频率稍微上去，雪球依然会返回验证码或者直接警告。这说明反爬体系是分层的：动态Cookie校验只能拦住不会执行JS的初级爬虫，对于能模拟Cookie的爬虫，还有更上层的风控策略在起作用。

我在压测时试过一秒发十几个请求，结果一分钟内就被封了几个IP。后来把请求间隔调整到3到5秒一次，单线程跑，基本就稳定了。如果确实需要更高的采集速率，建议用稳定的代理池，而且代理IP的信誉度一定要好，公共代理IP的出口地址早被风控标记了，用了反而更糟。

这个坑想提醒大家的是：逆向出算法不等于可以无限制采集。数据采集要尊重目标网站的规则，合理设置频率，能走官方API就走官方API，把所有希望压在一个逆向出来的Cookie上，随时可能被更严格的风控打回原形。

6. 这套方案能不能通用：聊聊acw_sc__v2系列变体

6.1 acw_sc__v2并非雪球独有

搞清楚原理之后你会发现，acw_sc__v2并不是雪球网自己设计的一套东西，而是很多网站都在用的通用方案。只要看到类似“第一次请求返回带arg1的JS挑战页，然后需要生成一个动态Cookie才能访问”的流程，基本就是同一套WAF体系下的产物。

同款站点之间，区别主要在于变量名和密钥。变量名不一定叫arg1，可能是arg2、arg3，总之是某个拼接出来的字符串。密钥不一定等于31，需要到混淆JS里去找那条异或运算代码，看它后面的常量是多少。找到密钥，算法就破解了一大半。

此外还有一些变体会在异或之后再做一层Base64编码，或者把异或结果改成十六进制大写字符串而不是字符拼接。这些都不难处理，先跑通一个样本，再用对照法验证，很快就能适配。

6.2 从acw_sc__v2延伸出的逆向思路

现在不少网站已经用上了acw_sc__v3，v3最大的变化是在Cookie生成过程中加入了更多环境特征，比如时间戳、Canvas、WebGL指纹、鼠标轨迹等。单纯模拟一个加密函数已经不够，可能需要借助轻量级的DOM执行环境或者维护一个真实的浏览器环境才能解决。

但逆向的整体思路是不变的：先绕过反调试，再定位入口，然后分析算法，最后用自己熟悉的语言重写验证。换个网站，换套变量名，方法论依然适用。

我的个人经验是，处理这类带JS挑战的站点，最重要的是留下“黄金样本”。所谓黄金样本，就是第一次访问时返回的挑战页HTML、arg1原始值，以及浏览器种下的最终Cookie值。这三个数据是验证算法的关键参照物，有了它们，哪怕代码写到一半思路断了，也能通过对比逐步逼近正确结果。我就因为没及时保存样本，在改代码时反复刷新页面，白白多花了一个晚上的时间。希望读到这里的你，别再踩这个坑。