资讯动态

Android模拟器网络配置全解析:从adb连接到IP/DNS设置

发布时间:2026/10/28 2:31:51 来源:尧图企业网站定制
简介这份文档面向Android开发初学者与需要联调模拟器网络环境的开发者聚焦AVD模拟器与电脑IP不在同一网段、无法联网或通信失败这一常见痛点给出从启动模拟器到验证生效的完整操作路径。资源共1个doc文件压缩包约47KB篇幅精简便于随查随用。内容围绕adb命令行展开涵盖启动模拟器、进入platform-tools执行adb shell、用getprop读取默认DNS10.0.2.3与默认IP10.0.2.15、通过setprop修改DNS和net.gprs.local-ip、再次getprop确认生效等环节并针对“device not found”“device offline”等报错给出重启adb进程的排错思路。已有2149人学习适合希望快速打通模拟器与电脑通信、减少环境调试耗时的开发者参考。1. 模拟器连不上网先别急着重装八成是 IP 和 DNS 没对上做 Android 开发的人几乎都被模拟器网络坑过一次。代码没问题、接口没问题、电脑浏览器能打开模拟器里就是转圈超时或者电脑上的本地服务模拟器死活访问不到。很多人第一反应是重装模拟器、换镜像、清缓存折腾半天最后发现根子在一个很朴素的地方模拟器默认跑在 10.0.2.x 这个虚拟网段里和电脑所在的 192.168.x 根本不是一个网段DNS 也指向虚拟网关 10.0.2.3。这个坑不分新手老手越是急着联调越容易翻车。这篇笔记就把 AVD 模拟器 IP 设置这件事从头到尾拆开从 adb 报错到 getprop 验证照着做能通也能明白为什么通。2. adb shell 进不去device not found 与 device offline 的排查顺序在改 IP 之前第一步永远是先能进到模拟器的 shell 里。这一步看着简单实际是报错最集中的地方。原文里提到的两个错误——error: device (null) not found和error: device offline——恰好代表了两种完全不同的故障一个是 adb 服务端和模拟器之间的连接断了一个是模拟器压根没起来或者没连上。分不清这两个后面所有 setprop 都是白搭。2.1 先确认 platform-tools 目录和 adb 版本很多人是在任意目录下直接敲adb shell结果提示找不到命令或者调到了别的 SDK 版本里的 adb。常见做法是先切到 Android SDK 下的platform-tools目录再执行命令。Windows 下大致是这样# 进入 SDK 的 platform-tools 目录路径按自己机器实际安装位置改 cd C:\Users\yourname\AppData\Local\Android\Sdk\platform-tools # 先看 adb 版本确认命令可用 adb version # 列出当前 adb 能识别到的设备 adb devicesadb version用来确认你调的是哪个 adb机器上装了多个 SDK 时经常出现版本打架。adb devices是后面所有排查的基准正常应该看到一行emulator-5554 device如果列表是空的说明 adb 根本没连上模拟器如果显示offline说明连上了但握手没完成。这两个状态对应不同的处理路径先看清楚再动手别一上来就 kill-server。2.2 device (null) not foundadb 服务端状态坏了这个报错的意思是 adb 客户端在找设备时拿到的设备标识是空的本质是 adb 服务端进程状态异常常见于模拟器重启过、adb 被别的工具占用、或者上一次连接没干净退出。原文给的解法是杀掉再重启 adb 服务这是标准操作# 杀掉当前 adb 服务端进程 adb kill-server # 重新启动 adb 服务端 adb start-server # 再次确认设备是否回来 adb deviceskill-server结束的是后台的 adb 服务进程不是模拟器本身所以模拟器不用关。start-server会重新拉起服务并扫描 5554 起的模拟器端口。执行完再跑一次adb devices如果设备回到device状态就可以继续adb shell。这里有个细节如果 kill 之后 start 仍然看不到设备先别怀疑命令去确认模拟器是不是真的在运行、有没有被别的 IDE 的 adb 抢走连接。2.3 device offline模拟器没启动或没连上error: device offline和上面那个不是一回事。它通常出现在模拟器还没完全启动、或者启动到一半卡住的时候。原文说得很直接如果未启动模拟器就会提示这个启动即可。实际操作里我一般按这个顺序确认# 第一步确认模拟器进程在不在Windows 任务管理器里看 qemu 相关进程 # 第二步确认 adb 能看到设备但状态是 offline adb devices # 第三步如果模拟器已启动仍 offline重启 adb 连接 adb kill-server adb start-server adb devices如果adb devices里显示emulator-5554 offline说明端口通了但模拟器系统还没准备好等它启动完看到桌面再试。如果一直 offline重启模拟器比反复 kill-server 更有效。这里的关键判断是not found偏服务端问题offline偏模拟器侧问题方向搞反了就会在错误的地方浪费时间。3. getprop 读不到正确值默认 DNS 和 IP 到底在哪看能进 shell 之后下一步是搞清楚模拟器当前的网络属性。原文用的是getprop这个命令会把系统属性全量打出来信息量很大新手容易看花眼。真正要盯的就两个键DNS 和 IP。默认情况下模拟器的 DNS 是10.0.2.3IP 是10.0.2.15这两个值来自模拟器内置的虚拟路由器和电脑的真实网段天然隔离。3.1 getprop 全量输出怎么筛直接敲getprop会刷屏常见做法是配合过滤只留关心的键# 进入模拟器 shell adb shell # 全量属性信息很多仅用于确认命令可用 getprop # 只筛 DNS 相关属性 getprop | grep dns # 只筛 IP 相关属性 getprop | grep -i ipgetprop不带参数时输出的是[key]: [value]格式的全部属性。管道接grep dns能快速定位net.dns1接grep -i ip能捞出net.gprs.local-ip这类键。注意不同系统镜像里属性名可能有差异如果 grep 不到就回到全量输出里人工找别死磕一个键名。这一步的目的是拿到「改之前」的基线值后面改完才有对比依据。3.2 默认 10.0.2.15 意味着什么看到net.gprs.local-ip是10.0.2.15就说明模拟器走的是内置虚拟网络10.0.2.15 是模拟器自己10.0.2.3 是虚拟 DNS10.0.2.2 通常指向宿主机。这套地址在模拟器内部自洽所以模拟器一般能上网但它和电脑的 192.168.x 网段不通。这就是为什么电脑上跑的服务模拟器访问不到也是为什么有些内网接口在模拟器里调不通。理解这一点后面 setprop 改地址才有意义——不是随便填个 IP而是把模拟器拉进电脑所在的网段。3.3 改之前先记下电脑的网段和 DNSsetprop 要填的值不是拍脑袋来的得先看电脑自己的网络配置。Windows 下用ipconfig /all重点看本机 IPv4 地址、子网掩码和 DNS 服务器# Windows 下查看本机网络配置 ipconfig /all # 关注三项IPv4 地址如 192.168.5.20 # DNS 服务器如 192.168.5.1 # 默认网关如 192.168.5.1假设电脑是192.168.5.20DNS 是192.168.5.1那么模拟器的 DNS 就该设成192.168.5.1IP 设成同网段一个没被占用的地址比如192.168.5.100。这里最容易犯的错是 IP 和电脑完全一样导致地址冲突正确做法是同网段、不同主机位。记下这三个值下一步直接往里填。4. setprop 改完不生效DNS 与 IP 两条命令的正确写法到了真正改配置的环节原文给了两条命令setprop net.dns1 192.168.5.1改 DNSsetprop net.gprs.local-ip 192.168.5.100改 IP。命令本身很短但坑不少值填错、改完不验证、重启后丢失都是高频翻车点。这一章把两条命令拆开讲清楚再补上验证和持久化的注意点。4.1 改 DNSsetprop net.dns1 的参数怎么定DNS 决定了模拟器能不能把域名解析成 IP填错的表现是「能 ping 通 IP 但打不开网页/接口域名解析失败」。命令在adb shell里执行# 进入模拟器 shell adb shell # 把 DNS 改成电脑使用的 DNS 地址 setprop net.dns1 192.168.5.1 # 确认写入结果 getprop net.dns1net.dns1是主 DNS 属性值必须是电脑当前可用的 DNS 服务器地址通常就是ipconfig /all里看到的那个。填完立刻用getprop net.dns1回读确认输出是192.168.5.1而不是空或者旧值。如果回读为空说明属性名在当前镜像上不生效需要换镜像支持的键别硬套。DNS 改对之后域名解析才会走电脑的 DNS而不是虚拟的 10.0.2.3。4.2 改 IPsetprop net.gprs.local-ip 的网段对齐IP 这条命令的目的是把模拟器拉进电脑所在网段让两边能互相访问# 在 adb shell 中把模拟器 IP 设到电脑同网段 setprop net.gprs.local-ip 192.168.5.100 # 回读确认 getprop net.gprs.local-ipnet.gprs.local-ip这个键名看着有点怪gprs 是历史遗留命名但在很多 AVD 镜像上就是用它来控制模拟器的本地 IP。填的值要和电脑同网段、主机位不同比如电脑192.168.5.20模拟器用192.168.5.100。填完同样要回读。这里要提醒一句这个属性改的是模拟器内部记录的值不等于底层网络接口立刻重配部分镜像上还需要配合重启网络或重启模拟器才真正生效所以下一步的验证不能省。4.3 改完必须回读验证别信「命令没报错就是成功」setprop 有个特点命令执行成功不代表值真的生效它只是把属性写进去回读才是唯一证据。原文第六步就是再次getprop确认新值生效这一步千万别跳# 一次性回读两个关键属性 getprop net.dns1 getprop net.gprs.local-ip # 或者过滤后一起看 getprop | grep -E net.dns1|net.gprs.local-ip回读时如果 DNS 是新值、IP 也是新值说明属性层改成功了。接下来再做连通性验证在模拟器里 ping 电脑的 IP或者在电脑上 ping 模拟器的地址。如果属性对了但 ping 不通问题就不在 setprop而在虚拟网络的路由或防火墙得换方向排查。这个「先验属性、再验连通」的顺序能帮你快速区分是配置没写进去还是写进去了但网络层没通。4.4 重启后配置丢失怎么办setprop 写的是运行时属性模拟器一重启基本就回到默认的 10.0.2.15 和 10.0.2.3。这是很多人「昨天还好好的今天又连不上」的真正原因。常见做法有两个方向一是每次启动后重新执行一遍 setprop写成脚本最省事二是在模拟器启动参数或镜像配置层面处理。脚本方式最直接# 保存为 set_avd_ip.sh每次模拟器启动后执行 adb shell setprop net.dns1 192.168.5.1 adb shell setprop net.gprs.local-ip 192.168.5.100 adb shell getprop net.dns1 adb shell getprop net.gprs.local-ip把两条 setprop 和两条回读放进脚本启动模拟器后跑一次比手动敲稳。注意脚本里的 IP 和 DNS 要跟着你当前网络环境改换了办公网就得同步更新否则又是一轮「怎么又连不上」。如果团队里多人共用一套调试环境把这个脚本和网段约定写进项目说明能省掉大量重复沟通。5. 避坑清单模拟器网络配置里最容易翻车的五个点这一章集中记录我在模拟器 IP 设置上踩过的坑每条按「现象 → 原因 → 解决」写都是能直接对号入座的场景。看完再回头做前面的步骤会少走很多弯路。5.1 现象setprop 执行成功getprop 回读还是旧值原因通常是属性键名和当前镜像不匹配或者命令在错误的 shell 上下文里执行比如没进adb shell就在宿主机上敲。解决先adb shell确认提示符变成模拟器内部再执行 setprop回读为空就换键名别反复重试同一条命令。判断依据是回读值不是命令有没有报错。5.2 现象模拟器能上网但访问不到电脑上的本地服务原因是模拟器还在 10.0.2.x 网段和电脑的 192.168.x 不通。解决按第 4 章把net.gprs.local-ip改到电脑同网段再在电脑上确认服务监听的是0.0.0.0而不是127.0.0.1。只改模拟器不改服务监听地址照样连不上这两件事要一起做。5.3 现象改完 IP 后模拟器彻底没网了多半是 IP 填成了电脑的地址造成冲突或者 DNS 填了一个不可达的地址。解决IP 用同网段不同主机位DNS 用ipconfig /all里真实可用的那个改完先 ping 网关再 ping 外网 IP最后才测域名。顺序反了会把 DNS 问题和路由问题混在一起。5.4 现象昨天配置好好的今天启动又回到 10.0.2.15原因是 setprop 是运行时属性重启即失效。解决把 setprop 写成启动脚本每次模拟器起来后执行一遍或者把网段约定固化到团队的调试流程里。别指望一次配置永久生效这是属性机制决定的不是操作失误。5.5 现象adb devices 一直 offlinekill-server 也没用原因是模拟器系统没启动完或者 adb 被 IDE 自带的版本抢占。解决先等模拟器进桌面再adb devices仍 offline 就关掉 IDE 里的 adb 连接用 platform-tools 下的 adb 重新start-server。判断 offline 和 not found 的区别能省掉一半无效操作。6. 快速定位这类问题的排查路径与验证习惯模拟器网络问题看着杂其实有一条很稳的排查主线先确认 adb 能连上再确认属性值对不对最后确认网络层通不通。三步各自有明确的判断信号任何一步没过就不要往下走否则会在错误的方向上越查越乱。下面这张对照表是我平时排查时脑子里过的顺序可以直接拿去用。阶段检查命令正常信号异常时先看什么连接层adb devices显示emulator-5554 device空列表查模拟器是否启动offline 查系统是否就绪服务层adb kill-serveradb start-server设备重新出现是否被 IDE 自带 adb 抢占属性层getprop net.dns1/getprop net.gprs.local-ip回读为新设的值键名是否匹配当前镜像网络层模拟器内 ping 电脑 IP有回包服务监听地址、防火墙、网段是否对齐持久层重启模拟器后再getprop值是否保留是否需要启动脚本重设验证习惯上我一般坚持「改一项、验一项」改完 DNS 先回读 DNS改完 IP 先回读 IP两项都对了再测连通性。最忌讳的是一次性把 DNS、IP、路由全改了然后发现不通根本不知道是哪一项出的问题。另一个习惯是每次换网络环境比如从家里换到公司都重新跑一遍ipconfig /all因为网段和 DNS 会变旧脚本里的值很可能已经失效这也是「昨天还好今天不行」的常见来源。还有一个容易被忽略的点验证连通性时先 ping IP 再测域名。ping 不通 IP 是路由或网段问题ping 通 IP 但域名解析失败才是 DNS 问题。把这两个分开测能直接定位到是第 4 章哪条命令没生效。很多所谓的玄学问题拆成这两步之后就一点都不玄了。从那以后我每次开模拟器联调前都强制先跑一遍adb devices和两条 getprop 回读确认基线再写代码。这个习惯帮我省掉了大量「代码背锅」的冤枉时间。希望这些步骤能帮到你下次再遇到模拟器连不上先按这条主线走一遍比盲目重装快得多。本文还有配套的精品资源点击获取

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑