速读摘要：客户一台网站服务器被大量 UA 为
Lightpanda/1.0的请求打爆，CPU 长时间 100%、页面打开卡顿。Lightpanda 是一款专为 AI 代理和自动化工作流设计的开源无头浏览器（不是搜索引擎、不是爬虫框架、也不是传统爬虫），其默认 UA 容易被识别但不主动限速。最终通过百度云防护新建一条”UA 拦截”自定义规则，把 Lightpanda/1.0 与其他 12 类常见 AI/无头浏览器 UA 全部精准拦截，响应从 200/卡顿变为 403，CPU 立刻回落，网站秒级恢复。本文完整复盘这次事件。
一、故障现象：CPU 100% + 页面卡顿
客户反馈：上午业务高峰期间，服务器 CPU 持续 100%，网站后台操作严重卡顿，疑似被攻击。
第一时间排查：
- CPU/负载：
top看到 4 核 CPU 全跑满，load average飙到 8+ - 网络流量：
iftop看到入向流量明显高于平时 - 进程状态：PHP-FPM / Nginx worker 进程数被撑到最大
- 关键线索：在
access.log里翻到几乎所有异常请求都带着同一个 UA ——Lightpanda/1.0
二、服务器日志：UA 一边倒的异常
从日志里随便抓一段，2 秒钟内 20 条请求全部带 Lightpanda/1.0：
从日志看，几个非常明显的特征：
- UA 完全一致：
Lightpanda/1.0（不是伪装过的浏览器，也不是普通爬虫）； - JA3 / JA4 指纹只有 2 个：说明同一批机器、同一类客户端工具在跑；
- 来源 IP 杂乱：20 条请求里出现了 13+ 个不同 IP，跨多家运营商（电信/移动/联通/境外）—— 不是单点攻击，而是一批 AI 代理在同时拉数据；
- 请求频率极高：毫秒级并发（同一秒有 4-5 条），远超过正常浏览器节奏。
三、Lightpanda 是什么？为什么它会”打爆”网站？
继续深挖 Lightpanda/1.0 这个 UA，发现它来自一款 2024 年新晋的开源无头浏览器 —— Lightpanda（GitHub: lightpanda-io/browser）。
3.1 项目背景
Lightpanda is an open-source headless browser built for AI agents and automation workflows.
设计目标：
- 面向 AI 代理：让 LLM Agent / Browser-Use 类工具能拿到”结构化、可计算”的网页内容；
- 极轻量级：相比 Chrome / Firefox 几十 MB，Lightpanda 编译后不到 1 MB；
- 专注协议兼容：支持 HTML、CSS 选择器、JS 子集、HTTP/2 / HTTP/3；
- 默认 UA 暴露：
User-Agent: Lightpanda/1.0，不主动伪装成 Chrome。
3.2 你为什么会在日志里看到它？
简单说，谁在用 Lightpanda 拉你的网站：
- AI 代理浏览：Hermes Agent、OpenAI Operator、Anthropic Computer-Use、各类 RAG 数据采集代理，用 Lightpanda 当默认 headless engine；
- 自动化测试：一些 CI/CD 流水线把 Playwright 切到了 Lightpanda 做轻量测试；
- 网页抓取/爬虫：有人用 Lightpanda 做大规模数据采集。
Lightpanda 官方文档明确解释了这个 UA 的三种典型使用场景：网页抓取/爬虫、AI 代理浏览、自动化测试。默认 UA 不做伪装，所以一旦被识别，几乎一拦一个准。
3.3 为什么它会”打爆” CPU？
- 并行度极高：AI 代理天然就是几十上百个并发页面 + 整站抓取；
- JS 仍要执行：Lightpanda 不是单纯 HTTP 请求，会执行脚本渲染 DOM；
- 不遵守 robots.txt：默认就硬抓，对 robots 协议不友好；
- UA 一目了然：不伪装 → 一抓一个准；
- 缺乏”自我节流”：工具使用者往往只关心”能不能拿到”，不关心”会不会把别人打爆”。
合在一起：单台 Lightpanda 实例跑一小时可能产生几万次请求，多个 AI 代理同时跑，对中小网站就是”瞬间击穿”。
四、解决方案：百度云防护自定义 UA 拦截规则
4.1 为什么用 WAF 而不是改 Nginx？
可选方案有三种：
| 方案 | 优劣 |
|---|---|
| Nginx 改 UA 拦截 | 需要登录每台服务器维护，且拦截后还得手工分析 IP 画像，维护成本高 |
| 改业务限流 | 影响真实用户，误伤率高 |
| 百度云防护 UA 拦截 | 一处配置全站生效，可视化日志，自动追加封禁，秒级生效 |
4.2 规则配置（百度云防护 → 自定义规则 → 新建）
关键配置：
| 配置项 | 值 |
|---|---|
| 规则名称 | UA拦截 |
| 接入类型 | SaaS WAF |
| 优先级 | 0（最高） |
| 匹配条件 | User-Agent 包含以下多值之一 |
| 拦截 UA 列表 | Lightpanda/1.0、gptbot、Amazonbot、HeadlessChrome、PhantomJS、Playwright、Prerender、selenium、webdriver、WebDriver、chromedp、Splash、Cypress |
| 生效模式 | 永久生效 |
| 处置动作 | 拦截并追加封禁（自动把来源 IP 拉入临时封禁名单 1440 分钟） |
| 响应页面 | 不单独指定（使用全局默认拦截页） |
| 防护站点 | 全站生效 |
为什么把这 13 个 UA 一起拦截？Lightpanda 不是孤例 ——
gptbot（OpenAI 训练抓取）、Amazonbot（Amazon 训练抓取）、HeadlessChrome/PhantomJS/Playwright等都是”非人类”行为特征，对业务站点没价值反而耗资源。在客户业务场景下，全部拒绝”自带”AI/无头浏览器 UA 是合规的。
4.3 拦截后效果
规则上线 30 秒内就看到拦截效果：日志里 Lightpanda/1.0 请求被切到 WAF，响应码 403，不再打到源站。
我们随手挑一条被拦截的请求看完整细节：
- 攻击 IP：
117.189.35.5（贵州遵义） - 攻击时间：
2026-08-19 17:53:33 - 攻击路径：
/job/c1/530/c2/632/c3/964/edu/1/trade/13/settr/30/nat/1.html - 接入类型：SaaS WAF
- 命中规则：
UA拦截（规则 ID 1000126053） - JA3 / JA4：
da6b4ed151e487ee5d4414c1b4833627/t13d1710h2_5b57614c22b0_95ca0cbbc74b - 响应码：403（拦截）
- 处置动作：拦截并把 IP 加入 1440 分钟封禁名单
- 请求 UA：
Lightpanda/1.0，sec-ch-ua: "Lightpanda";v="1"（Sec-CH-UA 头也会暴露身份）
复盘下来 1 分钟内，源站 CPU 从 100% 降回 < 20%，网站恢复流畅。
（图：单次拦截事件 117.189.35.5 在 2026-08-19 17:53:33 的完整处置记录，命中规则 UA拦截、响应码 403、处置动作 拦截并追加封禁。）
五、经验总结与给同行的建议
5.1 如果你也遇到 CPU 100% 现象
按下面顺序排查，10 分钟内能定位：
top+ps aux --sort=-%cpu→ 确认是 Nginx/PHP 还是 Java/Go 在跑满；tail -f access.log→ 抓 20 条最近请求的 UA；- 排序
awk '{print $12}' access.log | sort | uniq -c | sort -rn | head→ 看 UA 集中度； - 如果某个 UA 占 50% 以上，八成就是它，直接按 UA 封；
- WAF / Nginx
if ($http_user_agent ~ "Lightpanda|gptbot|HeadlessChrome|PhantomJS|Playwright") { return 403; }一行命令搞定兜底。
