ApiCatcher核心功能介绍及使用场景

ApiCatcher 是面向 iOS、Android、macOS 和 Windows 的 HTTP/HTTPS 抓包与调试工具。移动端在设备本机用 VPN 接管流量，不需要再把手机代理到电脑；桌面端可以在系统代理和 TUN 之间切换，TUN 用来抓那些不走系统代理的请求。

它名字里的 Api，来自最初要解决的问题：抓到的请求不该只躺在历史列表里，而应该变成可以继续用的接口。下面介绍这八个能力各自解决什么问题，以及对应的使用场景。

抓包

抓包是后面所有功能的入口。开启后，App 或浏览器发出的 HTTP/HTTPS 会经过本地代理，安装并信任 CA 证书后可以解密 HTTPS。WebSocket 的握手和数据帧也会被记下，数据帧按聊天记录的方式排列，JSON 会格式化高亮，还可以按 Payload 搜索。

日常会用到的配套能力：

• 黑白名单：按 Host 过滤。白名单非空时只记录命中的域名，黑名单里的域名不记录。支持 *，例如 *.example-api.com。
• Session：一次开始到停止是一个 Session，请求历史可以按这次抓包单独查看或删除。
• 搜索：URL、请求头、响应头、请求 Body、响应 Body 都能搜。还可以按方法、协议、Content-Type、状态码和时间范围过滤。
• 导出：单条请求可以导出 Raw、cURL、Markdown；一批请求可以导出 HAR。图片、视频、音频会单独归类，带 Range 的分片会先合并再导出。

场景：接口问题排查。 复现一次出错的操作，在历史里打开这条请求，对照客户端实际发出的 URL、Header、Body，以及服务器返回的状态码和响应 Body。请求本身不对，问题在客户端；请求是对的、响应不对，问题在服务器。先分清两边，再继续往下查。

场景：确认某个功能用了哪些接口。 把这个功能按不同业务场景各操作一遍。抓包历史里就能确定它打了哪些接口，以及不同场景下的传参有何不同。

自动生成 API

符合条件的 HTTP/HTTPS 请求会被整理成按 Host 分组的接口文档。接口的唯一键是「方法 + Host + Path」。同一个接口被抓到多次时，Query、Header、Body 只补充还没出现过的字段，不会拿后一次的字段名覆盖前一次。响应示例只在状态码为 200 时更新。

文档可以按 Host 整包导出，也可以只导出一个接口，或从 API 收藏里导出。目标是 Postman、Apifox，或一份 Bruno 的 ZIP。

场景：导出到接口管理。 接口文档生成之后，按 Host 整包导出，或只导出一个接口、一个收藏目录，送到 Postman、Apifox 或 Bruno，在接口管理工具里维护和共享。

与导出 HAR 再导入 Postman 等 API 管理平台生成 API 不同，ApiCatcher 生成的 API 会随着捕获到的请求覆盖的业务场景变多，字段也越来越全。

重放请求

重放是 ApiCatcher 自己再当一次客户端：从历史里取出一条 HTTP/HTTPS 请求，改或不改查询参数、请求头、请求 Body，发给服务端，在重放页看状态码和响应。App 不会因为这次重放刷新界面。WebSocket 则是在这里重连，手动发一帧、看对端回包。

抓包开着时，重放会经过本地代理，因此已经配置的重写和脚本会作用到这次重放上，历史里也会再出现这条记录。

场景：接口联调。 后端改完接口，或在接口里加上排查日志后，客户端一键重放刚才抓到的那条请求。一次重放就能确认问题是否已经修好，也能让这次请求打进新日志里，继续排查。

组合重放

组合重放把多条 HTTP/HTTPS 请求放在一张画布上，按依赖执行。没有互相依赖的节点并行；有依赖的节点串行，上一层全部成功后才跑下一层。

四个常用编辑动作：

场景：链路联调。 多个请求要按顺序一起调，后面的请求要用前面的响应。给下游设置依赖，用依赖注入把上游响应填入下游请求，按依赖顺序执行。例如 GET /user 依赖 POST /login，POST /order 依赖 GET /user，在后两个请求上把 token 注入 Authorization，按登录、获取用户信息、下单的顺序执行。

场景：测同一接口多种入参。 同一个接口要一次验证多组不同入参。把该请求添加多次，如需串行执行则把所有节点串成一条线（仅建立依赖，无需配置依赖注入），各节点用预设参数写入各自的请求体。执行后对比各节点结果。例如把登录请求添加三次，请求体分别是正常账号、密码错误、空密码。

重写

重写在请求真正到达业务服务器之前，或响应回到 App 之前，按规则改流量。一条规则由作用域和动作组成。作用域是 Host，加上可选的 Path 和 Method。

动作包括：

• 重定向：把生产域名转到本机或预发。
• Mock：不发真实请求，直接返回预设状态码、响应头和 Body。
• 丢弃请求 / 丢弃响应：模拟发不出去，或服务器一直不回。
• 延迟：给响应加上等待，看弱网下的 Loading 和超时提示。
• 修改：改 Header、整段替换 Body，或用正则在 Body 里查找替换。正则可以用 AI 按自然语言生成。

场景：接口 Mock。 后端接口还没就绪，或要让客户端走到某种状态时，不发真实请求，直接返回预设的状态码和响应体。例如给订单列表配一条 Mock，返回待支付和已完成两种状态，界面可以先做完，接口就绪后关掉规则。

场景：改写响应。 只改响应里的个别字段，看客户端后续怎么表现，不用改服务端数据。例如用正则把 "balance": 100 换成 "balance": 0，看余额不足时按钮怎么灰。

脚本

规则覆盖不了「每次都不一样」的逻辑时，用 JavaScript。启用后，匹配到的请求进入 interceptRequest，响应进入 interceptResponse。可以自己写，也可以让 AI 生成，或填写一个局域网脚本 URL，由团队统一下发。

脚本里可以直接用：

• crypto：MD5、SHA、HMAC、Base64，用来补签名或做 Body 加解密。
• localStore：跨请求保存 Token 等状态。
• httpClient：在脚本里再发一个 HTTP 请求，例如 Token 过期时先登录再注入。

场景：动态计算请求。 签名、时间戳这类值每次都不一样，固定替换做不到。在脚本里按当次请求算完再放行。例如重放总是 401 时，用当前时间和 Body 做 HMAC，写回 X-Timestamp 和 X-Signature。重放前必须先启动捕获，脚本才会作用到这次请求上；不启动捕获，脚本不会执行。

场景：Body 加解密。 企业内部项目通常会把 Body 再加密一层，HTTPS 解开后看到的仍是密文。用脚本在请求发出前加密、在响应回来后解密，才能看明文、改明文。例如在 interceptResponse 里把响应 Body 解密后查看；重放时在 interceptRequest 里把改过的明文再加密发出。重放前必须先启动捕获，脚本才会执行。

DNS 欺骗

产品里的名称是 DNS 映射。它做的是代理层的 DNS 欺骗：不改系统 hosts，也不改 Wi-Fi 的 DNS。开启抓包后，匹配到规则的连接绕过公网解析，直接连你填的 IP。HTTP 的 Host 和 TLS 的 SNI 仍是原域名，App 无感知。规则支持通配符，例如 *.apicatcher.net。

场景：同域名切测试和预发。 测试、预发、正式环境使用同一个域名。要访问测试环境或预发环境时，通过修改 DNS 把这个域名指到对应环境。例如在 DNS 映射里把该域名指到测试环境或预发环境的 IP，开启抓包后生效，不用每次改 Wi-Fi 的 DNS，也没有系统 DNS 缓存问题。

定时任务

定时任务按计划执行一条请求重放，或一整条组合重放。调度有两种：

• Cron：6 段，顺序是「秒 分 时 日 月 周」。0 * * * * ? 表示每分钟的第 0 秒。不确定写法时，用 AI 按自然语言生成。
• 自定义：按间隔秒循环，可限制次数或持续分钟数。

命中自动终止条件后任务停止。执行历史里可以看到耗时和成功率。手机上要先开始抓包，任务才会跑；桌面端只要应用开着就会跑。

场景：定时提交。 时间窗口很短，手动点容易错过。把一条请求或一条组合重放按间隔自动执行，并用响应内容自动停。例如秒杀开售前几秒开始，每 1 秒提交一次下单请求，响应里 code 为 200，或 Body 出现「抢购成功」「活动已结束」时停掉。

场景：定时巡检。 按周期反复请求同一条接口，看它是否可用、是否变慢。例如健康检查用 Cron 0 * * * * ?，每分钟一次，不配自动终止，在执行历史里看 P95。

场景：定时回归。 把已经编排好的组合重放按计划反复执行，检查结果是否仍符合预期。例如在组合重放里把同一接口添加多次，每个节点用预设参数写入不同入参，这些节点就是一组测试用例，再把这条组合重放设成每周执行一次。（对于需要依赖登陆的场景，组合规则先添加一个登陆请求作为其它所有请求的共同前置请求，但其它所有请求只能并行。）

更细的操作步骤在文档里：用户手册、重写、脚本、组合重放、定时任务。

以上功能并非 ApiCatcher 的全部功能，更多功能可前往官网了解。本文列举的使用场景也并非只能用于这些场景，只是我们提供这些功能最初想要解决的问题。