针对你遇到的AVD旧代理顽固残留、新代理完全不生效的问题，结合你已经用rootAVD获取Root权限的前提，我给你几个经过验证的深层排查与清除方案：

1. 直接排查系统层面的隐藏代理配置（Root环境专属） #

既然设备已经Root，我们可以直接钻到系统核心配置里找旧代理的痕迹：

• 先通过adb shell进入设备终端，再执行su切换到Root权限
• 执行以下命令排查关键配置：

  # 检查系统全局代理属性
  getprop | grep -i proxy
  # 检查网络连通性检测的配置文件
  cat /system/etc/sysconfig/connectivity_check.xml
  # 检查DHCP分配的残留配置
  cat /data/misc/netd/dhcp/dhcp-wlan0.lease
  

  • 如果getprop输出里有带172.24.54.23的属性（比如net.gprs.http-proxy），直接用setprop 对应属性名 ""清空
  • 如果connectivity_check.xml里硬编码了旧代理相关配置，直接用文本编辑器（比如vi）修改文件内容

2. 重置NetworkMonitor相关进程与缓存 #

从日志看，是系统的NetworkMonitor组件在调用旧代理，我们可以强制重置相关进程：

• 在Root shell里执行：

  # 停止networkstack进程
  am force-stop com.android.networkstack
  # 重启网络守护进程
  stop netd
  start netd
  

• 也可以在AVD图形界面操作：进入「设置 → 应用 → 显示系统应用 → 网络设置 → 存储 → 清除数据」，之后冷重启AVD

3. 检查宿主电脑上的AVD本地配置残留 #

有时候代理配置会存在AVD的本地镜像文件里，不一定只在虚拟机内：

• 先关闭AVD，找到你的AVD存储目录（通常是~/.android/avd/你的AVD名称.avd/）
• 打开config.ini文件，搜索proxy相关字段，若发现旧代理配置直接删除或修改
• 如果是userdata.img里的深层残留，可以用Root权限挂载该镜像到宿主电脑后内部排查（优先试前两个方法，这个相对繁琐）

4. 排查iptables规则是否被劫持 #

你提到已经查过iptables，但可以针对旧代理的IP和端口做精准排查：

iptables -t nat -L | grep 8081
iptables -t filter -L | grep 172.24.54.23

如果找到将流量转发到旧代理的规则，直接用iptables -t nat -D 规则编号（把规则编号替换成实际编号）删除

兜底方案：绕开代理连通性检测 #

如果以上方法都无效，我们可以修改系统的连通性检测地址，绕开旧代理的影响：
在Root权限下修改/system/etc/sysconfig/connectivity_check.xml，把默认的http://connectivitycheck.gstatic.com/generate_204替换为不需要代理的204检测地址，这样即使旧代理残留，网络状态也会被判定为正常，不影响实际使用。

内容来源于stack exchange