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