浏览器抓包代码

为什么需要浏览器侧抓包

当你想分析某个网站的接口调用，或者逆向前端页面的请求逻辑时，传统抓包工具如 mitmproxy 或 Charles 需要配置代理和安装 CA 证书。这个过程不仅繁琐，还容易因为证书信任问题导致抓包失败。特别是面对需要登录态的接口，每次都要手动复制 cookie 或 token，效率低下且容易出错。

更常见的情况是：你真正关心的数据并不是写在静态 HTML 里，而是通过 XHR/Fetch 动态加载的。直接抓取网页源码根本拿不到这些数据，浏览器侧抓包成了刚需。

核心工作原理

这个技能基于 Python + Playwright，在浏览器内部直接监听网络请求，完全绕过了代理和证书的配置。

工作流程如下：

• 启动无头浏览器访问目标页面
• 自动捕获所有 XHR/Fetch 请求及其响应
• 将结果输出为结构化 JSON
• 支持导出为 CSV、HAR 或 Markdown 格式

关键能力：

• 登录态持久化：首次登录后保存 storage_state，后续抓包无需重复登录
• URL 过滤：用 --filter-url 正则表达式精准定位接口，避免噪声
• 响应体控制：默认 2MB 上限，可用 --max-body 调整，或用 --no-bodies 禁用
• 动态等待：SPA 页面用 --wait-selector 确保数据加载完成

典型使用场景：

• 分析前端页面调用了哪些后端接口
• 采集动态加载的数据用于爬虫
• 生成 HAR 文件导入 Chrome DevTools 复现分析
• Mock 或篡改请求用于前端联调

适用边界与注意事项

这个方案擅长浏览器侧的 HTTP/HTTPS 请求抓取，但有几个明确的适用边界：

不适用的场景：

• TCP/UDP 网络层原始包（改用 Wireshark/scapy）
• 移动原生 App 流量（改用 mitmproxy + frida）
• Node.js 服务端流量

常见坑点：

• 响应体只能读一次：response.body() 重复调用会抛错，脚本已做缓存
• 异步回调需要包装：直接传 async 函数给 page.on 不会 await，必须用 asyncio.create_task
• HTTPS 必须忽略错误：不加 --ignore-https-errors 会导致白屏，请求事件不触发
• SPA 要等数据：page.goto 返回时 XHR 未必发完，用 --wait-selector 等待节点出现

如果你需要修改请求头、Mock 响应、并发抓多个页面，或者重放请求，可以参考 references/playwright_capture_guide.md 中的进阶章节。