模拟器里换代理IP，路径不止一条：改宿主机的系统代理、改模拟器的全局设置、改实例内部的客户端、在实例里装转发工具。四条路径的效果差别很大，最常见的问题是改在宿主机上，实例里却没生效，因为模拟器的网络是独立的一层，宿主机那一份配置传不进去。
先确认改的是哪一层的网络。
判断方法很直接：在实例里打开浏览器查一次地址，再在宿主机上查一次。两个地址不一样，说明实例走的是自己的线路；两个一样，说明实例跟着宿主机走。这一步做完，后面改哪一层就有方向了，不用四条路径都试一遍。
四条路径各自的适用范围
宿主机层适合单实例场景，代理IP配一次全部生效，缺点是所有实例共用一个地址。模拟器全局设置适合多实例，一改全改，缺点是没法给单个实例单独配。实例内部适合精细控制，一个实例一个地址，缺点是要逐个配，十个实例配十遍。转发工具适合需要按协议分流的场景，配置复杂但最灵活。
- 宿主机系统代理
- 只适合单实例；多实例共用同一地址，等于没拆
- 模拟器全局设置
- 一改全改，适合统一线路，不适合单实例区分
- 实例内部客户端
- 一个实例一条线，最精准，工作量随实例数线性增长
- 实例内转发工具
- 按协议分流，灵活但配置复杂，排查难度最高
路径选错，配得再仔细也不会生效。
多数人最后会落在实例内部配置这条路径上：实例内部配置，一个实例一条线。原因是模拟器的实例本身就是独立的运行环境，在实例里配，跟在一台独立机器上配没有区别，理解成本最低。代价是实例多的时候要重复劳动，只能用批量脚本解决。
批量配置怎么做
批量配置的前提是每个实例的配置文件路径有规律，文件名带编号。有了这个前提，一份模板加一个循环就能配完，改的时候也只改模板。没有规律的话，先花半天把目录结构整理成带编号的形式，后面每次批量都能省下时间，这笔投入一两天就回本。
配置完之后一定要逐个实例查地址。批量配置最容易出的问题是某个实例的配置文件路径写错，配置写到了别处，那个实例还在用默认线路。十个实例里错一个，平时看不出来，等任务跑到那个实例才发现，前面的时间白费。
四条代理IP路径没有哪条绝对更好，看的是实例数量和任务周期。单实例短周期，宿主机配一次就够；十实例长周期，只能在实例内部逐个配。数量决定路径，路径决定工作量，工作量决定要不要写脚本，这个链条想清楚了，配起来就不乱了。