云手机代理IP黑白名单按包名分流：先确认应用身份，再排查代理链路

云手机里想让一个应用走代理、另一个应用直连，通常要靠黑白名单或按包名分流。规则写对并不等于一定生效：包名、进程形态、系统网络层和代理入口任何一处不一致，都会出现“规则已保存但流量没按预期走”的现象。

先把“应用名称”和包名分开

分流规则匹配的通常是 Android 包名，而不是桌面上显示的应用名称。应用名称可能被改名、翻译或重复，包名才是系统识别应用的稳定标识。先在云手机的应用信息页确认完整包名，再复制到规则中，避免手打时漏掉前缀或大小写。

如果应用包含独立的登录、推送或 WebView 进程，还要确认服务商的规则是按主包名、子进程，还是按 UID 匹配。只把主界面包名加入白名单，可能仍有后台请求从另一条网络出口发出。

黑名单和白名单不要同时“想当然”

常见策略有两类：白名单模式只让列出的应用走代理，其余直连；黑名单模式则让大多数应用走代理，只排除指定应用。两种模式的默认值相反，先确认当前策略再写条目。

可以用一张小表先记录预期：

不要把“未配置的应用”默认为直连或代理，实际默认行为由云手机和代理组件决定。

规则保存后要确认下发到实例

云手机控制台保存规则后，可能还需要同步、重启网络组件或重新启动实例。先看控制台是否显示已下发，再在实例内重启目标应用。若规则由集中控制台下发，单台实例本地修改可能会被下一次同步覆盖。

建议一次只改一项：先加入目标包名，确认它的出口变化，再加入直连排除项。这样可以判断是包名不匹配，还是黑白名单逻辑相反。

验证“走代理”而不只是“能联网”

目标应用能打开页面，只能说明它联网成功，不能证明走了指定代理。应在获授权的测试接口上记录出口 IP、请求时间和实例标识，分别测试目标应用和排除应用。两者出口一致时，优先检查规则是否匹配到实际进程；出口不同但目标请求失败，则转查代理认证、地区限制和接口权限。

不要只依赖应用内显示的 IP。部分应用使用缓存、自己的 DNS 或内置网络库，展示结果可能与系统网络层不同。若服务商支持按会话或端口区分，也要确认目标应用使用的是预期入口。

常见冲突：VPN、系统代理和应用自带网络层

云手机里可能同时存在系统 VPN、代理客户端和应用内代理设置。它们的优先级会决定最终出口。排查时先只保留一条明确链路，暂时关闭无关 VPN 或应用内代理，再逐步恢复。遇到 DNS 泄漏、部分域名直连或后台请求不一致，应把 DNS、TCP 连接和应用层请求分开记录。

按包名分流的前提是你对应用和目标系统有授权。规则稳定后再批量复制到其他实例，并保留包名、规则模式、代理入口和验证结果，便于后续升级应用或更换云手机镜像时复核。