「这台手机的包怎么还在我这里？」

联调到一半，隔壁同事把测试机拿走了。他电脑上的 DevPeek 已经开着，Mock 和参数转换也配好了，手机却还记着我的代理地址。

过了一会儿，我的抓包列表里还在冒请求，他那边一条都没有。

「这台手机现在到底连的是谁？」

以前只能打开 Wi-Fi 详情，找到代理设置，把主机名改成他的局域网 IP，再核对端口。还机时改回来，下一个人借走时再改一次。不同品牌入口不一样，有的藏在「高级选项」里。

这套动作不难，但是它发生得太频繁，而且没有人会把「还机前清代理」当成一项正式流程。忘了切，包继续打到上一位同事；忘了清，测试机离开办公室后可能连网页都打不开。一个人在自己手机上调试时还好，一台设备在开发、测试之间转起来，几步系统设置就成了持续的摩擦。

我们想把交接收成一句话：扫谁的码，包就进谁的 DevPeek。

普通 App 改不了系统代理

最直接的想法，是做一个小工具保存几组 IP 和端口，点一下就替用户改好 Wi-Fi 代理。

但 Android 没给普通 App 这项权限。Wi-Fi 的 HTTP 代理属于系统网络配置，第三方应用可以把地址显示出来、复制出来，却不能静默写进去。除非设备被 Root、由企业 MDM 管理，或者应用本身是 Device Owner——这些都不适合一台普通团队测试机。

只做一个「代理地址收藏夹」并没有解决问题：点完收藏，用户还是得回系统设置粘贴。借一次机改一次，原来的摩擦几乎原封不动。

继续找系统允许的路径时，我们注意到了 VpnService。它原本是 Android 留给 VPN 客户端的接口：经用户明确授权，应用可以建立一张虚拟网卡，决定流量从哪里出去。Android 10 又给它补了 setHttpProxy，允许给这张虚拟网卡声明 HTTP 代理。

这正好绕开了「修改 Wi-Fi 配置」：

Android 10 及以上，通过 VpnService.setHttpProxy 把认系统 HTTP 代理的流量交给当前这台 DevPeek；
Android 8–9 没有这条 API，走 TUN → SOCKS5 → HTTP CONNECT → DevPeek；
设置里原来的 Wi-Fi 代理不动，断开 VPN 后，手机回到原来的网络路径。

VPN 在这里不是为了把 DevPeek 做成手机 VPN 产品，而是普通 App 无法改系统代理之后，系统仍然允许用户授权的一条路。

「一键」实际指什么

我们一直给「一键」加引号，因为第一次使用并不是真的点一下就结束：要安装 App，要允许系统 VPN，有 HTTPS 解密需求时还要装 CA。系统弹出的授权和警告也不该被绕开。

真正想省掉的是：每次换人，都进系统设置重填代理。

电脑与手机在同一局域网时，DevPeek 的手机面板会出一张配对码。它不是原来的证书下载码，而是一条 devpeek://proxy 链接，里面带着协议版本、代理端口、电脑显示名，以及可能可用的局域网 IP：

devpeek://proxy?v=1&host=192.168.1.23&ips=192.168.1.23,10.0.0.2&port=8888&name=Alice

手机扫码后，会按顺序短探测这些地址，找到当前网络里真正可达的那一个，再申请建立 VPN。这样电脑同时开着 Wi-Fi、网线或虚拟网卡时，不必让拿手机的人猜该填哪张网卡的 IP。扫不了码，仍可以从相册识别、粘贴链接或手填地址。

连过的电脑会留在历史里，并显示名字、IP 和端口。测试机再次回到同一位同事手里，可以从历史直接连接；换给另一个人，就扫另一张码。App 会持续检查桌面代理是否还活着，连续连接失败时主动断开，而不是保留一个看起来正常、实际上已经失效的出口。

还机前仍建议点「断开」。不断开时，新请求可能继续进入上一台电脑——这正是原来借机场景最容易漏的事。至少现在连接对象会明确显示在 App 顶部和系统常驻通知里，不必再回忆 Wi-Fi 设置中填过哪个 IP。

桌面上的局域网协作解决的是电脑之间发现伙伴、发送请求或调试录制；配套 App 解决的是同一台测试机在人之间交接。它们服务同一个团队，却不是同一条链路。

手机也只负责把流量送进当前这台电脑。抓包、解密、Mock、参数转换和页面调试仍由桌面 DevPeek 完成，和快速上手里的代理链路没有分叉。

证书还是要装，只是不用再自己找下载

代理切过去以后，HTTP 会先进入列表。要看到 HTTPS 明文，手机仍然必须信任当前这台电脑的 DevPeek CA。VPN 解决的是流量往哪里走，证书解决的是客户端是否接受中间人解密，两件事不能互相替代。

以前通常还要让电脑再出一张证书码，用浏览器下载文件，然后回到系统设置里找到它。现在 App 已经知道连的是哪台电脑，便可以直接向它请求 /devpeek-ca.crt，写入手机的「下载」目录，再打开系统设置。

到这里就是普通 App 能做的上限。Android 11 之后，应用不能再通过 KeyChain 直接发起 CA 安装；最终确认必须由用户在系统设置里完成。所以按钮没有叫「一键安装」，而是很具体的 保存并打开设置：

手机须已设锁屏（PIN / 图案）
点按钮后，确认文件已保存到「下载 / devpeek-ca.crt」
进入「安全 → 加密与凭据 → 安装证书 → CA 证书」
不要选「VPN 和应用」
选刚保存的 devpeek-ca.crt，确认警告后返回

不同厂商的菜单名字可能不同，这一步没法假装不存在。我们能减少的是重复找下载入口、确认证书来自哪台电脑；不能替用户接受一张根 CA。

未安装 App 的设备仍可使用桌面上的「扫码下载证书」。配对码和证书码继续分开：前者决定流量去哪里，后者只负责取得 CA。完整的证书信任与 SSL 解密范围见代理与 SSL 证书。

VPN 图标亮了，不等于整台手机都被抓了

这里还有一个容易误解的地方：VpnService 建起的是流量入口，不代表我们把整台手机的所有连接都送到电脑。

在 Android 10 及以上，Chrome、系统浏览器和常见 WebView 这类认系统 HTTP 代理的客户端会进入 DevPeek；不认代理的连接会经虚拟网卡直接回到手机原来的网络。这样做的目标是让测试机保持可用，而不是为了抓一个 H5，把所有后台同步、推送和其它应用流量都灌进桌面列表。

因此边界也很明确：

不是所有 App 都会进代理：很多原生 App 不认系统 HTTP 代理，会直接联网。
用户 CA 不是系统 CA：Android 7+ 默认不让普通 App 信任用户证书。微信等应用即使装了 CA，HTTPS 也可能无法解密；调试时仍需明确允许用户证书的构建。
UDP / QUIC 不保证进入 DevPeek：需要时让目标页面回退到 TCP / HTTP，不能把 VPN 图标当作全协议接管。
仍受局域网约束：手机和电脑须处于可互通的网络，电脑防火墙也要放行代理端口。
目前不做按应用过滤、系统证书注入和 iOS：这些不是藏起来的开关，而是尚未覆盖的能力。

它也不是手机上的独立抓包台，不替代连得上时的 Chrome Inspect。它只把团队最常重复的那一步——测试机换人时重设代理——从系统设置里拿了出来。流量进入桌面后，怎么筛选、看详情和重发，仍以抓包与过滤为准。

从「改设置」缩短到「确认连接对象」

回过头看，这个 App 的起点不是「DevPeek 也要有一个移动端」，而是一台测试机在团队里转来转去时，代理地址跟不上人。

我们没法消掉 Android 的 VPN 授权，也不能替用户安装根证书；更不能承诺所有 App、所有协议都被接管。能做的是把每次都要重复的 IP、端口和网卡判断交给配对码，把当前连接对象明明白白地显示出来，把断开和切换留在同一个入口。

原来是「进系统设置，确认现在填的是谁的 IP」。现在尽量缩短成「看一眼名字，扫一下码」。

测试机借来借去，我们不想再改系统代理