[排障复盘] Chrome 卡顿并非内存不足：Cloudflare Challenge 循环重试导致高 CPU（AIYA用户重发）

通用
, ,
1

背景

这次排查的是 Windows 上 Chrome 明显卡顿，但系统内存并未吃满的情况。

现场现象：

  • 浏览器操作发涩、输入延迟明显
  • 资源管理器看内存仍有余量
  • Chrome CPU 占用会突然抬高

排查步骤（未先关标签页）

  1. 对 chrome.exe 子进程做连续采样，统计每个 PID 的 CPU 峰值/均值
  2. 在 Chrome 任务管理器（Shift+Esc）按 CPU 排序并显示 PID
  3. 把系统采样 PID 与 Chrome 任务项一一对应

关键证据

  • 120 秒窗口内，Chrome 总 CPU 峰值约 39.30%
  • 可疑高占用 PID：6952、42292、4956
  • 在 Chrome 任务管理器中：
    • PID 6952 = 子框架: https://challenges.cloudflare.com/
    • PID 42292 = 子框架: https://challenges.cloudflare.com/
  • PID 6952 一度达到 81.8% CPU
  • 同时可见扩展进程（篡改猴测试版）内存较高，可能放大 Challenge 重试问题

结论

这类卡顿的核心不是内存，而是 Cloudflare Challenge 子框架反复重试：

  • 验证脚本持续运行（JS/WASM）
  • 多个子框架并发时 CPU 叠加抢占
  • 页面出现明显卡顿

为什么会“持续触发 CF”

常见原因：

  • 挂着很久的标签页恢复后，challenge token/cookie 已过期
  • 代理出口变化，Cloudflare 认为会话不连续
  • Cookie/本地存储策略阻断状态写回
  • 用户脚本/扩展注入干扰了 challenge iframe
  • 同站多标签并发触发验证，失败重试相互叠加

实际结果

关闭相关高负载页面后，浏览器流畅度立即恢复，说明归因成立。

给同类问题的快速自检

  1. Shift+Esc 打开 Chrome 任务管理器，按 CPU 排序并显示 PID
  2. 优先看是否有 challenges.cloudflare.com 子框架异常占用
  3. 临时禁用目标站点上的用户脚本扩展再观察
  4. 检查代理规则，必要时让 *.cloudflare.com 直连做对照
  5. 确认 Cookie/站点数据策略没有阻断验证状态持久化