Akamai 机器人 Cookie 详解：_abck、ak_bmsc、bm_sz

Akamai Bot Manager Cookie 是 Akamai 用来记录它对你的客户端已经做出何种判断的方式。bm_sz 最先到达，通常出现在第一个 HTML 响应中，有效期约四小时。ak_bmsc 和 bm_sv 是约两小时的短期会话 Cookie。_abck 是持久 Cookie，有效期通常为一年：它记录你的浏览器的客户端检查是否已被接受。这些 Cookie 的值都经过加密且没有公开文档。你能从中读到的是：你持有哪些 Cookie、它们何时变化，以及它们是否始终停留在同一个客户端、同一个 IP 上。

Akamai Bot Manager Cookie 一览

Akamai 没有发布这些 Cookie 的逐字段规范。最可靠的公开信息是 Cookie 披露：Akamai 自己的产品文档和 Cookie 页面，以及部署了 Bot Manager 的网站的 Cookie 政策。下表综合了这些来源，来源之间有分歧的地方会注明。

来源：RIPE NCC Cookie 列表列出了全部五个 Cookie，均归为严格必要，_abck 为 1 年，bm_sz 为 4 小时，ak_bmsc、bm_sv 和 bm_mi 为 2 小时。cookie.is 给出的 _abck、bm_sz、ak_bmsc 和 bm_sv 有效期相同。Akamai 的 Identity Cloud Cookie 表给出了 bm_sv 的描述，以及 ak_bmsc 和 bm_sv 的 HttpOnly/Secure/SameSite 标志。Akamai 自己的 Cookie 偏好设置页面把 _abck、ak_bmsc 和 bm_sv 归入严格必要类，把 bm_sz 归入性能类。

两点实用提醒。第一，所有这些属性都按部署单独设置，上面的有效期只是典型值，并无保证。请读取你所访问网站实际的 Set-Cookie 响应头。第二，较新的部署会设置额外的 Cookie，你可能会在 DevTools 里看到它们的名字。我们没有找到关于它们的可靠公开描述，因此这里不做介绍。

_abck：承载判定结果的 Cookie

_abck 是反映你的浏览器是否通过 Akamai 客户端检查的持久 Cookie。它最初以未验证状态下发，之后每当 Bot Manager 脚本回传数据，就由服务器重写。它的过期时间通常是一年，但其中的“已验证”状态持续的时间远比 Cookie 本身短。

它的值是一长串加密字符串，各段之间用波浪号分隔。人们讨论的只有 ~-1~ 和 ~0~ 这样的短标记。请把下面的内容当作社区观察。Akamai 从未公开说明这些标记，而一篇详细的分析文章，Scrapfly 的文章，明确建议不要从这个值推断任何固定字段。各独立来源大致认同的解读如下：

• 靠前位置为 ~-1~：客户端尚未满足客户端检查。新下发的 _abck 就处于这个状态；如果始终没有可接受的遥测数据到达，它会一直停在这个状态。
• 该位置为 ~0~：检查暂时已满足。常见的说法是这是一个客户端“停止信号”，告诉页面脚本可以停止发送遥测数据。
• 已验证的 Cookie 可以被重置。受保护的端点可以下发新的 _abck，让你回到未验证状态，例如在登录或结账之前。

Crawlex 的文章给出了同样的解读，并强调这些结论“完全来自观察 Cookie 变化的人”。重要的推论在于 ~0~ 不意味着什么：它不是通行证。Akamai 仍会根据 IP 信誉、协议指纹和请求模式对每个请求评分，从另一个客户端或网络出示的 ~0~ Cookie 可能会失败。Akamai 自己的 Bot Manager 快速入门列出了一项名为 Cookie Integrity Failed 的检测，它“确保没有机器人运营者篡改或试图复制 Bot Manager Cookie”。所以，被复制的 _abck 恰恰是这套系统专门要抓的东西。

由于页面脚本要读取这个标记，_abck 通常不是 HttpOnly；一般可以在 document.cookie 中看到它。我们没有找到 Akamai 对此的说明，请在你测试的网站上自行确认。

bm_sz：会话种子

bm_sz 通常在受保护主机的第一个 HTML 响应中设置，早于任何 Bot Manager JavaScript 运行，有效期约四小时。Crawlex 的 bm_sz 分析等技术文章将其描述为客户端脚本所依据的按会话输入。这就是为什么来自其他会话或源站的 bm_sz 会让后续一切都失效。如果客户端始终没有收到 bm_sz，那么这个受保护页面很可能根本没有经过 Bot Manager，这一点在调试时很有用。

ak_bmsc：短期会话 Cookie

ak_bmsc 是约两小时的会话 Cookie。披露中称它用于区分人类与机器人，Akamai 的 Identity Cloud 文档也称它“用于优化性能”。各文章对其 HttpOnly 标志说法不一。Akamai 自己的 Identity Cloud 表格写的是 HttpOnly: false，而几篇爬虫博客说它是 HttpOnly，这说明该设置因部署而异。如果它在会话中途消失，通常是因为已过两小时，或者你的客户端丢弃了 Cookie。

bm_sv 与 bm_mi

bm_sv 是 Akamai 唯一直接描述过的 Cookie（“Akamai Bot Manager 用来帮助区分由人类产生的 Web 请求和由机器人或其他自动化程序产生的 Web 请求”），有效期约两小时。Akamai 的快速入门还列出了一项 Session Validation 检测，它“统计来自某个客户端的 HTML 页面请求和 AJAX 请求数量”。从命名看它可能与 bm_sv 有关，但没有公开资料证实，所以不要依赖这一点。bm_mi 出现在部分部署的披露中，有效期两小时，没有更多细节。

传感器流程的概念性说明

Bot Manager 分层工作。边缘节点独立评估每个请求，浏览器中的 JavaScript 层则补充客户端证据，并记录在 _abck 中。Akamai 的快速入门列出了主要检测项：

• 冒充已知机器人：伪造的 Googlebot 等。
• 基于 User-Agent 的检测和请求异常检测：单个请求内部的不一致。
• Web 爬虫信誉：“给近期参与过爬取活动的 IP 地址打上不良信誉分”。
• Cookie 完整性、会话验证和浏览器验证：“确认请求来自真实的 Web 浏览器”。
• 行为异常检测：仅限 Premier，用于登录、结账等交易类端点。

Akamai 当前的检测方法页面描述了同样的划分：透明检测捕捉“顺序错乱的请求头和浏览器版本不匹配”，而主动检测“通过一次交互来确认请求来自 Web 浏览器”。

Cookie 的生命周期由这一设计决定：

1. 受保护主机的第一个响应设置 bm_sz 和未验证的 _abck，页面加载 Akamai 的脚本。
2. 脚本在浏览器中收集客户端信号（环境、时序，部分页面还有交互），并提交到同一网站的第一方端点。
3. Akamai 将提交内容与请求级信号一起评分，并返回一个更新 _abck 的 Set-Cookie。
4. 后续请求携带这些 Cookie。边缘节点检查它们是否完整、是否属于本会话，以及是否与它看到的其他信息相符。

不在本文范围内：本文不描述传感器载荷、如何生成它，也不介绍如何构造 Cookie 值。伪造 Akamai 遥测数据正是 Cookie Integrity 及相关检测要抓的行为，我们不提供这方面的帮助。如需了解包括 TLS 和 HTTP/2 指纹在内的完整信号图景，请参阅我们的 Akamai Bot Manager 深度解析。

为什么纯 HTTP 客户端会卡在无效的 _abck 上

requests、httpx 或 Go 的 net/http 这类 HTTP 库不执行 JavaScript，因此 Bot Manager 脚本永远不会运行，也没有任何东西会更新 _abck。客户端会一直发送它在第一个响应中收到的未验证 Cookie。在 Akamai 要求浏览器验证的页面上，这就是预期结果。

修好 TLS 也改变不了这一点。仿冒库可以让握手和 HTTP/2 帧看起来像 Chrome，但它无法产生脚本本应产生的客户端证据。实际中通常是这样：只使用透明层的页面照常可用，而需要主动验证的页面（登录、购物车，以及部分网站的搜索 API）开始返回 403 或挑战页面。

在选择工具之前，先问问自己究竟需要哪些页面。大量公开数据无需经过主动验证层就能获取，而网站的官方 API 或数据源往往比自动化浏览器更合适。

在干净、一致的连接上，真实浏览器有何不同

真实浏览器会运行脚本、保留 Cookie、发送始终一致的 TLS 和 HTTP/2 指纹，并在整个会话期间停留在同一个网络上。正是这些因素的组合，让 _abck 进入并保持已验证状态。每一项都很重要：

• 整个会话保留同一个 Cookie 存储。如果在请求之间丢弃 Cookie，每个请求看起来都像首次访问：新的 bm_sz、未验证的 _abck，脚本又得重新运行。在 Playwright 中，一个浏览器上下文就是一个 Cookie 存储，不要每个页面都新建上下文。
• 每个会话固定一个出口 IP。在一个 IP 上签发给某会话的 Cookie，如果从另一个 IP 重放，看起来就像 Cookie Integrity 要抓的复制行为。如果在会话中途轮换 IP，Cookie 就不再与签发它们的网络相符。凡是有状态的操作（浏览某个类目、购物车、登录流程）都应使用粘性会话，只在会话之间轮换。我们的粘性会话与轮换会话指南介绍了如何确定会话时长。
• 从干净的 IP 开始。Web 爬虫信誉按 IP 评分。有爬取历史的数据中心 IP 段，在任何 Cookie 设置之前就已被怀疑。住宅 IP 和移动 IP 的信誉基线各不相同；我们的 IP 信誉深度解析解释了这些分数是如何得出的。
• 以人类合理的频率发送请求。Session Validation 实打实地统计每个客户端的 HTML 和 AJAX 请求数。每分钟发出数百个页面请求的会话，有效的 _abck 也救不了它。

遵循这些规则的最简 Playwright 配置如下：一个持久上下文、一个粘性住宅出口，并保存状态，让下一次运行延续同一会话，而不是从头开始：

from pathlib import Path
from playwright.sync_api import sync_playwright

STATE = Path("state.json")
PROXY = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "USERNAME-sid-abc123-ttl-10m",   # 粘性：本会话使用同一出口 IP
    "password": "PASSWORD",
}

with sync_playwright() as p:
    browser = p.chromium.launch(proxy=PROXY)
    context = browser.new_context(
        storage_state=str(STATE) if STATE.exists() else None
    )
    page = context.new_page()
    page.goto("https://www.example.com/", wait_until="load")
    # ……少量页面跳转，保持人类的节奏……
    names = sorted(c["name"] for c in context.cookies())
    print(names)                                # 查看你持有哪些 Akamai Cookie
    context.storage_state(path=str(STATE))      # 为下次运行保留 Cookie 存储
    browser.close()

把保存的状态与其会话 ID 绑定。如果通过另一个出口 IP 恢复 state.json，你就重新制造了原本想避免的 IP 变更问题。

故障排查：现象、可能原因、检查项

每次只检查一个变量。大多数“被 Akamai 拦截”的报告最终都属于前三行之一。这张表里还有一个没什么帮助但诚实的答案：有时网站已经决定不在该路径上为自动化流量提供服务，正确的做法是停止，或者申请访问权限。

给网站所有者：在自己的日志中解读这些 Cookie

如果你在运行 Bot Manager，请记录 Cookie 的名称和 _abck 状态标记，而不是它们的值，并以 Akamai 自己的机器人判定结果作为决策依据。这些值经过加密，格式可能随时变化。从普通访问日志中可以得到的模式：

• 访问深层 URL 却完全没有 bm_sz 或 _abck 的请求。这些是不带 Cookie 的客户端：要么是首次访问，要么是丢弃 Cookie 的工具。如果商品或搜索 URL 上这类请求占比很高，又没有对应的落地页访问，就说明存在脚本化访问。
• 同一个 _abck 值出现在许多 IP 或 ASN 上。这是 Cookie 共享或重放。Akamai 的 Cookie Integrity 检测就是为此而设，你的日志能让你看清问题有多大、影响了哪些路径。
• 在许多请求中一直保持未验证状态的会话。这通常意味着客户端从不执行你页面的 JavaScript。收紧规则之前先核实这一点，因为隐私扩展和脚本加载失败也会造成这种情况。
• 源站侧的机器人判定结果。Akamai 可以把判定结果以请求头的形式转发到你的源站。Auth0 的集成指南记录了 akamai-bot 和 akamai-user-risk 请求头，并指向 Akamai 的“Forward Bot Results to Origin”配置。使用这类受支持的字段，胜过解析 Cookie 内部结构。

关于隐私：这些 Cookie 是与设备绑定的标识符。RIPE NCC 等的披露将其归为严格必要，这在欧盟通常意味着无需征得同意。但把原始值和 IP 一起保存的日志仍属于个人数据，因此在取得标记和名称集合后，应对值做哈希处理或直接丢弃。

这些 Cookie 不能告诉你什么

Cookie 可以表明客户端验证尚未完成，却无法表明某个请求会被放行。请求级检测（IP 信誉、协议指纹、请求头异常、频率）独立于 _abck 运行，网站所有者还会按路径设置你从外部看不到的策略。调试时，把 Cookie 当作信号之一，把响应码、挑战页面和时序当作其他信号。