不少人以为模拟器里配了代理，里面所有应用就都会走这条IP。实际跑下来，常常是浏览器正常、某个应用依旧直连。这跟模拟器本身关系不大，问题出在应用各自实现网络请求的方式上。有的应用老老实实读系统设置，有的自己带一套网络模块，压根不看那个开关。
为什么会分成两类
安卓系统里的代理设置是一份约定，应用主动去读才生效。系统自带的浏览器，以及遵循这套约定的应用会读，请求就顺着代理IP出去。另一类应用自己实现了网络请求，从建立连接到发送数据都自己管，系统里那份设置对它没有约束力。这不是某个模拟器的毛病，真机上也是同样的表现。
- 读系统代理的应用
- 浏览器、部分工具类应用，请求按系统设置走代理IP
- 自带网络模块的应用
- 网络请求自己实现，不读系统设置，表现为直连
- 系统自带服务
- 更新检查、推送连接等常驻进程，多数独立于应用配置
怎么确认是应用的问题还是配置的问题
分辨方法很简单：在同一个模拟器里换一个应用试。浏览器走了代理IP而目标应用不走，基本可以判定是这个应用不读系统设置，与地址端口填得对不对无关。如果连浏览器都直连，那才要回头查配置本身，比如入口找错了层、端口没对上。
同一个模拟器，换个应用试，结论立刻分明。
确认之后有三条路。第一条是找应用自身有没有代理相关设置，有就直接在里面填。第二条是从更底层的网络层接管，让模拟器的出站请求整体经过代理IP，应用读不读那份设置都无所谓。第三条是接受现状，只给会读的应用配代理。三条路的成本差别不小。
底层接管为什么更彻底
底层接管不做在应用层，而是在模拟器发出请求的必经位置做转发。它不管应用读不读系统设置，只要是这台模拟器出去的请求，都会经过代理IP。代价是配置更复杂，需要额外软件或网络层的改动，而且改动会影响整个模拟器，不单单是某一个应用。适合目标应用完全不认系统设置的情况。
还有一类容易被忽略的是模拟器自身的服务。更新检查、推送连接这些常驻进程，多数不跟随应用层的代理配置。它们流量不大，排查时却容易造成误判，以为代理没生效。
应用的网络请求怎么发，决定了代理IP能不能管到它。
把应用分成会读和不会读两类，再决定是逐应用配置还是整体接管，模拟器里的代理IP才能真正覆盖到需要它的地方。动手之前想清楚要覆盖的范围，比事后一个个排查省事。