capx 抓包工具

原创

白白
白白

白白学安全

2026年10月15日 21:11
山东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

我开源了 capx：
把抓包、手机测试和 AI 接进同一个工作台

从一次页面报错出发，找到请求、比较差异、重放验证，再让 AI 参与排查。这篇文章把 capx 的功能、设计思路、手机接入和实际使用方式讲清楚。

手机上的页面转了一会儿，最后提示“加载失败”。后台究竟返回了什么？参数有没有传对？相同操作为什么有时成功、有时失败？这些问题，是做接口开发和移动端测试时经常遇到的。

为了找到答案，通常要先在手机上复现，再到抓包工具里翻记录，复制请求与响应，检查参数，然后修改请求重新发送。问题复杂一点，还需要截图、对照操作步骤，再把结果整理给开发或测试同事。

AI 可以帮助分析日志，但使用过程中又多了一层信息搬运：复制哪些请求、补充什么上下文、怎么让分析建议对应回原始记录，仍然要花时间处理。

我做 capx 的出发点，就是把这些相互关联的步骤接起来。现在项目已经开源，这篇文章结合一个具体排查场景，介绍它能做什么、为什么这样设计，以及实际接入手机和 AI 时需要准备什么。

先认识 capx：围绕“观察、分析、验证”组织工作。

capx 是一款本地运行的抓包、接口分析与自动化测试工具。它提供 Web 控制台、桌面入口、REST API 和 MCP 接口，将流量查看、请求重放、手机测试和 AI 工具接入放在同一工作台里。

日常使用时，可以在页面里查看 HTTP/HTTPS 请求、HTTP/2 和 WebSocket 流量；需要验证接口行为时，把历史请求送到重放器；测试手机 App 时，接入 Android 或 iPhone；希望让 AI 参与时，再通过 MCP 提供相应的数据与工具能力。

从复现到验证：一种典型的测试流程，按任务逐步执行

这些入口围绕同一项测试任务使用。比如，在手机上点击后，可以根据发生时间、目标域名和请求路径筛选相关记录，再分析或重放验证。具体哪条请求对应哪次操作，仍要结合证据判断。

流量概览：查看目标站点、请求与最近流量（模拟数据）

以自己的测试 App 为例，走一遍接口排查。

假设正在测试一个商品列表页面：刷新后偶尔加载失败，而对应接口是 /api/products。下面是一种建议的排查流程，接口路径和字段仅用于说明，实际内容以自己的测试服务为准。

第一步，先缩小范围。记录复现时间，在请求历史中按目标域名、路径与错误状态码筛选，找到这次操作附近的记录。先确认失败发生在哪个接口，再展开分析。

第二步，比较请求与响应。选择一条失败记录和一条可比较的成功记录，核对查询参数、请求正文、内容类型以及必要的会话信息，再看响应状态和错误正文。关注具体字段，而不仅是一个“500”。

第三步，把猜测变成可验证的修改。例如怀疑 page\_size 参数影响结果，可以将请求发送到重放器，保持其他条件尽量一致，只修改这个参数，再观察状态码和正文是否变化。

第四步，整理证据。记录修改了什么、返回了什么，以及结果是否支持原来的判断。成功请求与失败请求可能还受会话、缓存或服务端状态影响，一次重放的结果需要放回具体环境中理解。

这条流程的价值，是把“页面失败了”逐步收敛成可以讨论的问题：哪条请求、哪些字段、什么返回、什么操作能够复现。后续沟通也更容易围绕证据展开。

接口分析：读取请求和响应，再进入重放器验证（模拟数据）

把这一段工作交给 AI 辅助，需要怎样的指令？

capx 通过 MCP 向支持该协议的 AI 客户端提供工具。客户端中的模型负责理解任务和组织分析，capx 负责提供可调用的查询与操作能力，后台服务需要先运行。

比较适合作为起点的，是范围明确、结果容易核对的任务。例如，围绕已有抓包记录提出这样的请求：

请筛选商品列表相关的失败请求，选择一条可比较的成功记录，比较查询参数、请求正文和响应差异。分别列出直接观察到的事实、待验证的猜测，以及下一步建议。请在每项发现中标明对应的请求记录。

对应到工具调用，AI 可以先使用 capx\_list\_http 查询 HTTP 历史摘要，再用 capx\_get\_http 读取选中交易的具体内容。例如，下面是筛选 5xx 记录的工具参数示意：

{
  \"tool\": \"capx\_list\_http\",
  \"arguments\": {
    \"status\": \"500-599\",
    \"limit\": 50
  }
}

有了初步结果，还可以继续要求 AI 整理复现说明，而不必再次手工拼接上下文：

请根据已经读取的记录，整理一份问题说明：包括复现前置条件、操作步骤、相关接口、关键参数差异、实际返回、已经验证的修改，以及仍需确认的问题。

查询已有记录和执行主动操作有不同的权限要求。需要通过 MCP 重放请求或操作手机时，应按对应工具的要求显式开启权限；手机点击等操作还受到后台主动操作开关控制。可以先从读取与分析开始，再逐步加入需要的操作。

手机测试入口统一，Android 和 iOS 分别准备。

移动端测试经常同时涉及界面与网络。capx 在 App 抓包页面提供截图、元素定位、点击、输入、滑动和启动 App 等入口，平台底层分别使用 Android ADB 和 iOS WebDriverAgent，也就是 WDA。

Android 的准备过程相对直接：安装 Platform Tools，连接 USB，在手机上开启 USB 调试并授权电脑，然后在页面选择设备。通过截图或元素定位找到目标，再结合网络请求观察操作结果。原生 ADB 输入适用于可打印 ASCII，中文输入仍需要额外输入法或自动化方案。

代理地址是一个容易配置错的细节。Wi-Fi 模式下，应先在 App 抓包页启用手机访问入口，选择电脑的局域网 IP，并允许对应手机 IP 连接；手机 Wi-Fi 代理再填写这个电脑地址及代理端口。

举一个虚构的局域网例子：电脑是 192.168.1.10，手机是 192.168.1.20，代理端口是 18080。手机代理应填写 192.168.1.10:18080，并确保监听、白名单与防火墙允许这条连接。

Android USB 模式则可以使用 adb reverse，把手机端口转发到电脑，因此手机端配置 127.0.0.1 也能工作。两种模式的连接路径不同，配置时应先确认自己使用的是 Wi-Fi 还是 USB 转发。

iOS 通过 WDA 提供截图、点击、中文输入和滑动。页面提供 USB 与签名环境检测，以及自动准备入口，帮助处理工具检查、签名安装、通信隧道、开发者镜像、XCTest 启动和 USB 转发等阶段。

这部分需要有效开发身份或已有效签名的 WDA，以及设备信任、开发者模式和相应系统授权。签名过期或系统确认未完成，都会影响连接。界面操作就绪之后，HTTPS 抓包仍需另外配置 Wi-Fi 代理、安装测试 CA 并开启完全信任。

手机 App 抓包入口：在同一工作台选择平台、设备和代理（模拟数据）

设备连接完成后，可以从一个简单动作开始验证：读取当前截图，定位测试 App 的搜索框，输入测试关键词，再查看相关请求是否出现。截图与输入成功、代理有流量、接口正文可读，是几个需要分别确认的结果。

小程序调试，接入的是目标提供的标准 CDP。

capx 的小程序页面可以发现并选择本机调试服务提供的目标，也可以填写标准 CDP WebSocket 地址后连接，例如 ws://127.0.0.1:9222/devtools/page/target-id。地址中的 target-id 应替换为实际目标。

使用顺序是先准备外部调试提供方，让目标具有可用的 CDP 入口，再到 capx 选择目标进行连接。页面查看、截图和点击等操作，取决于目标实际支持的 CDP 命令。Windows 微信窗口操作则使用自行安装的微信客户端。

因此，体验小程序能力时，需要同时检查“调试提供方是否已经准备好”和“capx 是否连接到正确目标”。项目公开版提供连接与操作入口，微信客户端及外部调试环境由使用者准备。

代理通了，为什么接口正文还可能看不懂？

在移动端抓包中，需要区分三层条件：网络流量能否到达代理、HTTPS 是否能被正确解析，以及正文是否还存在业务层加密。它们分别解决不同的问题。

分别验证网络、TLS 与业务正文，才能判断当前卡在哪一层

例如，手机能够连接代理，说明网络路径具备条件；应用接受测试 CA，才有机会读取相应 HTTPS 内容；如果响应中的 data 字段仍是业务密文，还需要匹配的算法、参数和有效密钥。WDA 的操作授权也不能替代证书信任。

capx 提供已捕获业务密文的单独解密入口，可以选择请求或响应、指定 JSON 字段，并配置算法与密钥。接口支持 AES、DES、3DES、RC4 和 RSA；结果单独显示，原始抓包记录保留，便于继续核对。

证书固定、QUIC 和业务层加密等情况仍需按 App 验证。判断结果时，可以明确记录当前确认到了哪一层，避免把“代理已连接”直接等同于“目标接口已取得明文”。

这些功能放在一起，能带来哪些实际价值？

常见动作集中，排查过程更连贯。从历史记录找到请求，再读响应、做重放或查看设备，可以围绕同一项任务继续操作，减少寻找记录和切换入口的步骤。

AI 可以围绕具体记录提供帮助。通过 MCP 读取请求与响应，让分析更容易对应到可核对的内容。任务也可以按查询、比较、整理、验证逐步推进，发现偏差时及时调整。

保留人工操作，也方便脚本接入。Web 页面适合交互排查，REST API 便于接入现有脚本，MCP 为 AI 客户端提供工具接口。可以按实际任务组合这些入口。

本地运行，便于按自己的环境组织测试。代理和历史记录可以在本机处理。使用外部 AI 时，仍需了解客户端的数据处理方式，并控制提供的数据范围。不同设备的实际可用性也应分别验证。

开源，方便查看实现与继续扩展。代码公开后，遇到具体问题可以结合实现排查，也可以按自己的工作流程修改。项目原创代码采用 MIT 许可证，第三方组件保留各自许可。

想体验，可以先跑通一个最小场景。

从仓库成功的 GitHub Actions 构建中下载对应平台的程序包，按文档启动后台与控制台。以 Windows 包为例，后台启动命令可以是：

.\capx-captured.exe -addr 127.0.0.1:19091 -proxy 127.0.0.1:18080 -state-dir .\state

打开 http://127.0.0.1:19091/ 后，先用自己的测试目标产生一条请求，确认历史中可以查看，再做一次重放。手机测试按平台准备设备与测试 CA；接入 AI 时，将 MCP 配置中的路径替换为自己的绝对路径。下面示例以 C:/tools/capx 为解压目录：

{
  \"mcpServers\": {
    \"capx\": {
      \"command\": \"C:/tools/capx/capx-mcp.exe\",
      \"env\": {
        \"CAPX\_API\": \"http://127.0.0.1:19091\",
        \"CAPX\_TOKEN\_FILE\": \"C:/tools/capx/state/token\",
        \"CAPX\_MCP\_ACTIVE\": \"0\"
      }
    }
  }
}

后台需要先启动，令牌通过实例的 token 文件读取。可以先保持示例中的读取配置，确认 AI 能查询历史；需要主动测试时，再按工具要求设置 CAPX\_MCP\_ACTIVE=1，并为相应操作开启后台权限。

我更希望使用者带着一个具体问题来体验：一次偶发失败、一组参数差异，或者一个需要重复执行的界面操作。先把一个场景跑通，再把更多动作加入自己的测试流程。

项目源码、配置示例和使用说明都已放在 GitHub。欢迎试用、提交问题和参与改进；反馈时附上系统与设备版本、复现步骤和脱敏后的关键记录，会更方便定位问题。

项目仓库：https://github.com/hquip/capx

下载与构建说明：https://github.com/hquip/capx/blob/main/docs/GITHUB\_BUILD.md

手机自动化与 MCP 示例：https://github.com/hquip/capx/blob/main/docs/MOBILE\_AUTOMATION.md

文中界面图使用模拟数据展示功能，流程图用于解释使用方式。请仅在自己拥有或取得明确授权的环境中使用，公开日志、截图和抓包数据前做好脱敏。