当抓包需要活过一次终端会话时，团队就会离开 mitmproxy：QA 工程师需要看到开发者看到的，机架里的手机需要在没有笔记本在旁的情况下被抓包，或者智能体需要在有人监督下对流量采取行动。Busymate DevTools 保留了拦截的理念——断点、重发、模拟、拦截规则、脚本——并把它们搬进带浏览器仪表盘、角色和审计记录的托管订阅源。
切换前先尝试一个工作流
- 保留现有的捕获文件。将一台测试设备与 Busymate 配对，并捕获一个您已经理解的请求。
- 重新创建一个模拟或断点并检查结果。现有的代理设置和规则不会自动转移。
- 在转移更大的工作流之前，确认云存储、保留窗口和设备访问授权适合您的团队。
为手机而生，
比较完整的工作流：捕获运行的位置、如何共享访问权限以及如何自动化调试。
在一个地方从 iPhone、Android、Chrome、代理和手机农场捕获。队友可以看到他们拥有或被授予访问权限的设备的请求。
454 MCP 工具让您的代理检查捕获的流量并在您的角色范围内行动。破坏性操作需要确认。
一整机架的真实 Android 和 iOS 设备，你可以在浏览器中镜像、点击和编写脚本——或者对智能体说一句话即可。
权限在数据库中执行，操作记录在审计日志中，仪表盘和 API 无法泄露存储的保险库密钥。
同样的问题，
我们这一列只列出已发布的能力。对方那一列基于我们在其自家公开页面上读到的内容——凡是无法确认的都会标注，而不是猜测。
- 包含
- 部分
- 不包含
- 未验证
关于 mitmproxy 的信息于 2026-09-01 从其公开的产品、定价和文档页面读取。如有变动，请告诉我们，我们会更正页面。 提交更正
什么时候 mitmproxy 才是正确的选择
很多团队应该继续使用 mitmproxy。以下就是我们会建议你这么做的情形。
你想要免费、MIT 许可的工具
无许可、无席位、无托管服务——装上就能用。对个人、CI 任务或安全实验室来说，这正合适。
你用 Python 编写一切
掌握完整 flow 的插件、无头运行、客户端和服务端回放——mitmproxy 首先是可编程代理，其次才是界面。
你需要 HTTP/3、原始 TCP 或 UDP
mitmproxy 的协议覆盖——HTTP/3、WebSocket、DNS、TCP 和 UDP——比一款移动优先的抓包应用更广。
人们在换用之前
我还能在命令行里跑点什么吗？
可以。bmc 命令行把 Chrome DevTools Protocol 流量从终端流式传到订阅源，本地代理服务器是任何客户端都能指向的标准 HTTP 代理。共享视图在仪表盘里，但终端并没有消失。
什么能替代我的 Python 插件？
按设备、用户或服务作用的服务端脚本，加上处理常见情况的模拟和拦截规则。它有意比拥有完整 flow 对象的插件更窄——更容易共享，更难做花哨的事。
我需要在每台手机上安装 CA 吗？
iOS 和 Android 应用在自身设置过程中处理信任问题，所以 mitm.it 那一步消失了。使用桌面代理的浏览器和后端仍需信任一次其 CA，和 mitmproxy 一样。
它开源吗？
不是。如果 MIT 许可和公开仓库正是你看重 mitmproxy 的地方，那就继续用 mitmproxy——Busymate DevTools 的源码可按需提供，但仓库是私有的。