Reqable3.2.23

Reqable 是一款把 HTTP 流量捕获、接口调试和 REST API 测试放在同一工作流里的跨平台工具。它的价值不只是发送一个请求，而是能把真实流量查看、重发、修改，再沉淀为可复用的 API 请求；相应地，代理、证书和授权边界也必须先配置清楚。

3.2.23 应该下载哪一个包

截至 2026-08-31，Reqable 官方资料标示当前版本为 3.2.23，官方 GitHub Release 的发布时间为 2026-08-10。官方下载页按平台和架构列出最新入口，下面这张表用于选包，实际下载仍应从官方下载页进入。

版本号来自官方发布资料；下载页的 latest 链接可能随着构建更新而变化，因此本文不保存安装包直链，也不把文件大小写成固定值。

先分清抓包调试和 API 测试

Reqable 的两个核心功能解决的是不同问题：

• 抓包调试：桌面端通过系统代理捕获 HTTP 流量，移动端通过 VPN 隧道捕获；打开请求详情后，可以查看方法、URL、状态码、请求/响应头和正文，并按域名、应用、协议或状态筛选。
• API 测试：从零编辑 REST 请求，填写查询参数、Header、Body、授权和环境变量，发送后查看响应，还可以从 cURL、HAR、Postman 等资料导入或保存到 API 集合。
• 调试与测试联动：捕获到的流量可以直接编辑成新的 API 会话；API 测试也能开启跟随调试，让发送动作同时出现在流量列表里。

如果你的目标是复现线上请求，先抓包再编辑更省步骤；如果目标是编写稳定的回归请求，直接建 API 并保存到集合更清晰。两者都需要在合法授权范围内进行。

第一次抓包前要准备什么

1. 确认捕获范围：先明确设备、应用、域名和时间窗口，打开过滤条件，避免把无关流量或隐私数据一并保存。
2. 准备代理链路：桌面端检查系统代理是否指向 Reqable；移动端按官方流程启用 VPN 捕获，并确认设备网络没有被其他代理接管。
3. 安装并信任 CA 证书：HTTPS 解密需要证书。证书只应安装在测试设备或测试环境，处理完毕后按设备系统流程移除，不要把生产账号、支付信息或个人数据导入调试会话。
4. 用无敏感请求验证：先访问可控的测试接口，确认能看到状态码、请求头和响应，再扩大到目标应用；看不到流量时依次检查代理、证书、应用证书固定和网络权限。

证书只放在测试设备

桌面端可从工具栏盾牌图标进入证书安装页，安装成功后图标会变为绿色；Android 非 Root 设备通常手动安装用户证书，Android 7 及以上还要由应用配置是否信任用户证书。抓包任务结束后，应在测试设备的证书管理中移除不再需要的 CA，并清空含 Token、Cookie 或个人数据的会话文件。

Reqable 官方介绍明确提醒它面向开发、测试、网络、安全和爬虫等工程场景；它可以修改网络传输数据，不应被用于未授权拦截、绕过访问控制或处理不属于自己的通信。

从一条流量沉淀为可复用请求

一个实用闭环是“捕获 → 检查 → 编辑 → 验证 → 保存”。在流量列表中选中请求，打开详情查看 Summary、Headers、Query 和 Body；确认它不是重定向、静态资源或带临时密钥的偶然请求后，使用编辑/Compose 功能创建 API 会话。Reqable 会带入请求方法、协议、路径、参数、Header 和 Body，接下来再把环境地址、Token 和测试数据替换成变量。

• 用重发或回放确认请求能否稳定复现；不要把一次性的 Cookie、签名和时间戳直接固化。
• 需要改写请求或响应时，优先使用 Map Remote、Map Local、断点或脚本，并记录规则的作用域和退出条件。
• 验证状态码之外的响应结构、业务字段和错误分支，再保存到 API 集合，避免把失败样本当成成功基线。
• API 集合未登录时保存在本机；需要跨设备同步时再登录并检查云同步范围。

协议与端能力不要混为一谈

官方介绍页同时给出两组协议说明：API 测试部分列出 HTTP/1.1、HTTP/2、HTTP/3（QUIC），而 API 调试协议列表又写明 HTTP/3（QUIC）暂不支持。因此若任务是捕获 HTTP/3 流量，不能据此假定抓包调试已经完整兼容，应先用目标环境验证。HTTP/1.x、HTTP/2、WebSocket、SSE、IPv4/IPv6 以及 HTTP/HTTPS/SOCKS 代理则在官方调试说明中有明确列出。

桌面端和移动端也不是同一套能力：官方文档明确说明移动端不提供重写、断点和脚本等调试功能，需要这些操作时应把移动流量转到桌面端处理。Android 与 iOS 适合移动侧捕获、查看和发送请求，桌面端更适合证书管理、复杂改写、Python 脚本和大批量分析。

遇到问题按链路排查

Reqable 更适合需要“真实流量分析 + 可重复 API 测试”的开发和测试流程；如果只是偶尔发送一个普通 HTTP 请求，Apifox 这类更偏项目化 API 管理的工具可能更直接。两者的重点不同，不应只按功能数量比较。