工具对比
NetPeek vs Charles Proxy：iOS 抓包工具对比
Charles 等着 App 把流量发到代理；NetPeek 直接在手机上接管网络接口，因此能看到代理根本收不到的请求。
| NetPeek | Charles Proxy | |
|---|---|---|
| 抓包层级 | 本机虚拟网卡 —— 在设备上直接接管数据包 | HTTP 代理服务器 —— App 需经系统代理设置主动接入 |
| 覆盖范围 | 经隧道的任意 App 流量，包括不认代理的 SDK | 仅覆盖遵循 Wi-Fi HTTP 代理设置的客户端 |
| 配置成本 | 安装描述文件、信任证书、点开始抓包 | 同一 Wi-Fi 下的 Mac、手填代理 IP 与端口、安装证书 |
| 离开 Wi-Fi 时 | 蜂窝网络下照常工作，无需中转 | 需要桌面机在同一网络内可达 |
| 数据存放位置 | 留在设备本机，只有你主动导出时才离开 | 存在中转会话的那台桌面机上 |
| AI 分析 | 内置 MCP 服务，可接入你自己连接的 AI 客户端 | 无 |
核心差异：接管网络接口，而不是等 App 走代理
Charles 是跑在桌面上的 HTTP 代理服务器。iPhone 之所以能连上它，是因为你把 Wi-Fi 的 HTTP 代理指向了那台机器；而且只有尊重该设置的客户端才会出现在会话里。NetPeek 则在手机本机运行一个虚拟网络接口，流量在网络层就被接管，不取决于某个 App 愿不愿意走代理。
这实际上让你多看到什么
- 忽略系统 HTTP 代理、直接发起连接的 App 与 SDK —— 统计、广告、崩溃上报、支付类 SDK。
- 使用蜂窝网络、连着强制门户网络，或身边根本没有 Mac 时产生的流量。
- 你没有主动操作的 App 在后台的活动，整个会话期间持续记录。
- 连接级细节 —— 域名、端口、TLS 握手与耗时 —— 而不只是代理被递到手上的那段 HTTP 交换。
Charles 依然擅长的地方
Charles 成熟稳定，背后还有一块桌面大屏；如果你本来就在那台机器上调试 Web 应用，它是合理选择。当你的工作以桌面为主、目标 App 又遵循系统代理时，这套流程没有问题。NetPeek 面向的是另一种情况：要调试的对象就是这部手机，而为此还得拖一台笔记本过来才是真正的瓶颈。
关键能力并不缺席
- 重写请求与响应的 Header 和 Body，用设备本地文件做 Map Local，返回 Mock 响应。
- 编辑并重放任意已抓获的请求，用来复现问题。
- 用 JavaScript 脚本处理需要条件判断的调试逻辑。
- 在你手动安装并信任 NetPeek CA 之后，按你放行的主机查看 HTTPS 明文。
从 Charles 迁移过来
- 移除设备上手动配置的 Wi-Fi HTTP 代理 —— NetPeek 不需要它。
- 安装 NetPeek 描述文件，并在「设置 → 通用 → 关于本机 → 证书信任设置」中信任其证书。
- 把原来的断点和 Map Local 规则改写成 NetPeek 的重写规则。
- 开始抓包并正常操作 App，不需要再运行任何其它东西。