简介：这份文档面向Android开发初学者与需要联调模拟器网络环境的开发者，聚焦AVD模拟器与电脑IP不在同一网段、无法联网或通信失败这一常见痛点，给出从启动模拟器到验证生效的完整操作路径。资源共1个doc文件，压缩包约47KB，篇幅精简，便于随查随用。内容围绕adb命令行展开，涵盖启动模拟器、进入platform-tools执行adb shell、用getprop读取默认DNS（10.0.2.3）与默认IP（10.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 devices

adb version用来确认你调的是哪个 adb，机器上装了多个 SDK 时经常出现版本打架。adb devices是后面所有排查的基准：正常应该看到一行emulator-5554 device，如果列表是空的，说明 adb 根本没连上模拟器；如果显示offline，说明连上了但握手没完成。这两个状态对应不同的处理路径，先看清楚再动手，别一上来就 kill-server。

2.2 device '(null)' not found：adb 服务端状态坏了

这个报错的意思是 adb 客户端在找设备时，拿到的设备标识是空的，本质是 adb 服务端进程状态异常，常见于模拟器重启过、adb 被别的工具占用、或者上一次连接没干净退出。原文给的解法是杀掉再重启 adb 服务，这是标准操作：

# 杀掉当前 adb 服务端进程 adb kill-server # 重新启动 adb 服务端 adb start-server # 再次确认设备是否回来 adb devices

kill-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.3，IP 是10.0.2.15，这两个值来自模拟器内置的虚拟路由器，和电脑的真实网段天然隔离。

3.1 getprop 全量输出怎么筛

直接敲getprop会刷屏，常见做法是配合过滤，只留关心的键：

# 进入模拟器 shell adb shell # 全量属性（信息很多，仅用于确认命令可用） getprop # 只筛 DNS 相关属性 getprop | grep dns # 只筛 IP 相关属性 getprop | grep -i ip

getprop不带参数时输出的是[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 是虚拟 DNS，10.0.2.2 通常指向宿主机。这套地址在模拟器内部自洽，所以模拟器一般能上网，但它和电脑的 192.168.x 网段不通。这就是为什么电脑上跑的服务，模拟器访问不到；也是为什么有些内网接口在模拟器里调不通。理解这一点，后面 setprop 改地址才有意义——不是随便填个 IP，而是把模拟器拉进电脑所在的网段。

3.3 改之前先记下电脑的网段和 DNS

setprop 要填的值不是拍脑袋来的，得先看电脑自己的网络配置。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.20，DNS 是192.168.5.1，那么模拟器的 DNS 就该设成192.168.5.1，IP 设成同网段一个没被占用的地址，比如192.168.5.100。这里最容易犯的错是 IP 和电脑完全一样，导致地址冲突；正确做法是同网段、不同主机位。记下这三个值，下一步直接往里填。

4. setprop 改完不生效：DNS 与 IP 两条命令的正确写法

到了真正改配置的环节，原文给了两条命令：setprop net.dns1 192.168.5.1改 DNS，setprop net.gprs.local-ip 192.168.5.100改 IP。命令本身很短，但坑不少：值填错、改完不验证、重启后丢失，都是高频翻车点。这一章把两条命令拆开讲清楚，再补上验证和持久化的注意点。

4.1 改 DNS：setprop net.dns1 的参数怎么定

DNS 决定了模拟器能不能把域名解析成 IP，填错的表现是「能 ping 通 IP 但打不开网页/接口域名解析失败」。命令在adb shell里执行：

# 进入模拟器 shell adb shell # 把 DNS 改成电脑使用的 DNS 地址 setprop net.dns1 192.168.5.1 # 确认写入结果 getprop net.dns1

net.dns1是主 DNS 属性，值必须是电脑当前可用的 DNS 服务器地址，通常就是ipconfig /all里看到的那个。填完立刻用getprop net.dns1回读，确认输出是192.168.5.1而不是空或者旧值。如果回读为空，说明属性名在当前镜像上不生效，需要换镜像支持的键，别硬套。DNS 改对之后，域名解析才会走电脑的 DNS，而不是虚拟的 10.0.2.3。

4.2 改 IP：setprop net.gprs.local-ip 的网段对齐

IP 这条命令的目的是把模拟器拉进电脑所在网段，让两边能互相访问：

# 在 adb shell 中把模拟器 IP 设到电脑同网段 setprop net.gprs.local-ip 192.168.5.100 # 回读确认 getprop net.gprs.local-ip

net.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 一直 offline，kill-server 也没用

原因是模拟器系统没启动完，或者 adb 被 IDE 自带的版本抢占。解决：先等模拟器进桌面，再adb devices；仍 offline 就关掉 IDE 里的 adb 连接，用 platform-tools 下的 adb 重新start-server。判断 offline 和 not found 的区别，能省掉一半无效操作。

6. 快速定位这类问题的排查路径与验证习惯

模拟器网络问题看着杂，其实有一条很稳的排查主线：先确认 adb 能连上，再确认属性值对不对，最后确认网络层通不通。三步各自有明确的判断信号，任何一步没过就不要往下走，否则会在错误的方向上越查越乱。下面这张对照表是我平时排查时脑子里过的顺序，可以直接拿去用。

验证习惯上，我一般坚持「改一项、验一项」：改完 DNS 先回读 DNS，改完 IP 先回读 IP，两项都对了再测连通性。最忌讳的是一次性把 DNS、IP、路由全改了，然后发现不通，根本不知道是哪一项出的问题。另一个习惯是每次换网络环境（比如从家里换到公司）都重新跑一遍ipconfig /all，因为网段和 DNS 会变，旧脚本里的值很可能已经失效，这也是「昨天还好今天不行」的常见来源。

还有一个容易被忽略的点：验证连通性时先 ping IP 再测域名。ping 不通 IP 是路由或网段问题，ping 通 IP 但域名解析失败才是 DNS 问题。把这两个分开测，能直接定位到是第 4 章哪条命令没生效。很多所谓的玄学问题，拆成这两步之后就一点都不玄了。

从那以后我每次开模拟器联调前，都强制先跑一遍adb devices和两条 getprop 回读，确认基线再写代码。这个习惯帮我省掉了大量「代码背锅」的冤枉时间。希望这些步骤能帮到你，下次再遇到模拟器连不上，先按这条主线走一遍，比盲目重装快得多。

本文还有配套的精品资源，点击获取