简介：这份文档面向 Android 开发初学者与需要联调测试的工程师，聚焦模拟器与电脑不在同一网段、无法联网或通信失败这一常见痛点，系统梳理 AVD 模拟器 IP 与 DNS 的修改流程。内容从启动模拟器、进入 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 进程重启排错思路。资源包共 1 个 doc 文件，约 47KB，篇幅精炼，适合边操作边对照查阅。目前已有 2149 人学习，可作为 Android 模拟器网络配置的速查手册，帮助读者快速打通模拟器与电脑的通信链路。
1. 模拟器连不上网：别急着改 IP，先看清 10.0.2.15 这个默认值
adb shell敲下去，回你一句error: device '(null)' not found，或者模拟器明明开着却提示error: device offline——这两个报错在 Android 开发里出现频率高得离谱，折腾人的地方在于它看起来像网络问题，实际可能是 adb 服务没起来、模拟器没连上、或者你改的 IP 根本没生效。更反直觉的是，很多人一上来就去改模拟器 IP，结果发现模拟器默认的10.0.2.15和电脑根本不在一个网段，改完setprop重启又打回原形。这篇笔记围绕ip avd android这条线，把模拟器 IP 设置里最常见的几类翻车场景拆开讲：报错怎么读、根因在哪、命令怎么敲、改完怎么验证。适合刚接触 AVD 调试的新手照着做，也适合被setprop坑过的老手对照排查思路。
2. adb 连不上模拟器：device '(null)' not found与device offline的根因和恢复顺序
这两个报错经常被混为一谈，但触发条件完全不同。先把它们分开，后面的操作才不会瞎试。
2.1error: device '(null)' not found：adb 服务状态坏了
这个报错的意思是 adb 客户端在找设备时，拿到的设备标识是空的。常见触发场景是 adb 服务进程卡死、端口被占用、或者上一次adb会话异常退出后残留了僵尸进程。它跟模拟器本身开没开关系不大，哪怕模拟器正常运行，adb server 挂了照样报这个。
我一般按这个顺序恢复，别一上来就重装 SDK：
# 进入 platform-tools 目录，路径按自己 SDK 安装位置改 cd %LOCALAPPDATA%\Android\Sdk\platform-tools # 先看当前 adb 版本和服务状态 adb version adb devices # 杀掉可能卡死的 adb 服务进程 adb kill-server # 重新拉起服务，再列设备 adb start-server adb devices逻辑说明：adb kill-server干掉的是 adb server 这个后台进程，不是模拟器；adb start-server会重新监听 5037 端口并扫描已连接的设备。执行完adb devices正常应该看到类似emulator-5554 device的一行。如果列表是空的，说明 adb 起来了但没识别到模拟器，问题就转到模拟器侧，而不是继续在 adb 上打转。
参数上要注意：adb devices输出里状态列是device才算真正可用，offline和unauthorized是两种不同的病。offline通常是模拟器进程还在启动中或者 adb 与模拟器版本不匹配；unauthorized在模拟器上少见，多见于真机没点授权弹窗。
2.2error: device offline：模拟器没就绪或连接通道断了
这个报错字面意思是设备存在但处于离线状态。原文里提到「如果未启动 Android 模拟器，则会提示 error: device offline」，这个判断方向是对的，但实际排查要更细一层：模拟器窗口出来了不代表系统已经 boot 完成。AVD 从冷启动到sys.boot_completed=1中间有几十秒，这段时间 adb 能看见设备但状态是 offline。
排查顺序建议这样：
# 确认模拟器进程是否真的在跑（Windows 任务管理器里找 qemu 或 emulator） adb devices # 如果显示 offline，先等 30 秒再查一次，排除启动未完成 timeout /t 30 adb devices # 仍然 offline，重启 adb 服务再试 adb kill-server adb start-server adb devices # 还不行就冷重启模拟器：关闭 AVD 窗口后从 AVD Manager 重新启动这里有个血泪经验：不要在对 offline 设备执行adb shell的同时反复kill-server，容易把模拟器的 adb 连接通道彻底搞乱，最后只能重启模拟器。正确做法是先确认模拟器 boot 完成——在模拟器里能看到桌面、能滑动，再执行 adb 命令。
2.3 进入 shell 前的最后一道检查
原文第二步是「进入 platform-tools 目录，执行 adb shell」。这一步之前建议加一个确认动作，避免带着错误状态进 shell：
# 确认设备在线后再进 shell adb devices adb shell getprop ro.build.version.sdkgetprop ro.build.version.sdk能返回一个数字（比如 30、33），说明 shell 通道完全通了，后面改 DNS 和 IP 才有意义。如果这条都失败，先回到 2.1 和 2.2 处理连接问题，别往下走。
3. 改完 IP 不生效：setprop net.gprs.local-ip的适用边界与验证方法
这是整篇最容易翻车的地方。原文给的方案是setprop net.dns1改 DNS、setprop net.gprs.local-ip改 IP，命令本身没错，但很多人执行完getprop看到值变了就以为大功告成，结果模拟器里打开浏览器还是上不了网，或者电脑 ping 不通模拟器。根因在于：setprop改的是属性值，不等于网络栈真的按这个值工作。
3.1 先搞清楚默认值从哪来
原文提到默认 DNS 是10.0.2.3、默认 IP 是10.0.2.15，这两个值来自 AVD 的虚拟路由器机制。模拟器内部走的是一个 NAT 网络，10.0.2.15是模拟器自己的地址，10.0.2.3是虚拟 DNS，10.0.2.2通常指向宿主机。也就是说，模拟器和电脑本来就不在一个网段，这是设计如此，不是配置错误。
所以「把 IP 改到和电脑一个网段」这个诉求，要先想清楚目的：如果是为了让电脑访问模拟器上的服务，正确做法通常是端口转发（adb forward），而不是硬改模拟器 IP；如果是为了让模拟器访问局域网里的某台机器，改 DNS 和路由比改 IP 更关键。原文的方案适用于特定测试场景，但不能当成万能解。
3.2 按原文步骤执行，但每步都要验证
# 1. 进入 shell adb shell # 2. 查看当前网络相关属性，先记录原始值便于回滚 getprop | grep -E "net.dns|net.gprs.local-ip" # 3. 修改 DNS 为电脑所在网络的 DNS（示例值，按实际改） setprop net.dns1 192.168.5.1 # 4. 修改模拟器 IP 到与电脑同网段（示例值，按实际改） setprop net.gprs.local-ip 192.168.5.100 # 5. 再次查看确认属性已写入 getprop net.dns1 getprop net.gprs.local-ip参数说明：net.dns1是主 DNS 属性，部分系统版本还认net.dns2；net.gprs.local-ip这个属性名带 gprs 字样，在较新的 Android 版本上不一定被网络栈读取，这是它「改了不生效」的主要原因之一。执行setprop不需要 root，但属性只在当前模拟器实例生命周期内有效，重启模拟器后恢复默认。
验证不能只看getprop回显。属性写进去只证明字符串存下了，要确认网络真的通了，得在模拟器内部或通过 adb 做实际连通性测试：
# 在 adb shell 里 ping 宿主机网关（10.0.2.2 通常指向宿主机） ping -c 4 10.0.2.2 # 测试 DNS 解析是否工作 ping -c 4 www.example.com # 查看当前路由表，确认默认网关 ip route如果getprop显示新值但ping不通，说明属性没被网络栈采纳，这时候要么换用模拟器启动参数配置网络，要么回到端口转发方案，别在setprop上死磕。
3.3 什么时候该放弃改 IP，改用端口转发
这是很多教程没讲清的分界线。判断标准很简单：你要的是「电脑访问模拟器里的服务」还是「模拟器访问电脑/局域网里的服务」。
前者用adb forward，稳定且不依赖 IP 属性：
# 把电脑 8080 端口转发到模拟器 8080 端口 adb forward tcp:8080 tcp:8080 # 查看已有转发规则 adb forward --list # 用完移除 adb forward --remove tcp:8080后者才需要考虑 DNS 和网络配置，而且优先在 AVD 启动参数里配，而不是进系统后setprop。启动参数方式在模拟器重启后依然有效，setprop方式重启即失效，这是两者最本质的差别。
4. 避坑清单：模拟器网络配置里最容易踩的五个坑
这一节按「现象 → 原因 → 解决」记录，都是实际调试中反复出现的。
坑一：setprop执行成功，重启模拟器后 IP 又变回 10.0.2.15。原因：setprop写的是运行时属性，不落盘，模拟器实例销毁即丢失。解决：需要持久化就在 AVD 启动参数或系统镜像配置层面处理，或者接受每次启动后重新执行一遍脚本；测试脚本里把setprop命令固化成一段 shell，启动后自动跑。
坑二：改了net.dns1，模拟器里浏览器还是打不开网页。原因：DNS 属性改了但网络栈没重新加载，或者模拟器本身没有外网出口。解决：先ping 10.0.2.2确认宿主机通不通，再ping一个公网 IP（如ping -c 2 8.8.8.8）区分是 DNS 问题还是路由问题；DNS 问题再检查net.dns1是否被系统覆盖。
坑三：adb devices一直显示 offline，重启 adb 也没用。原因：模拟器 boot 未完成，或者 adb 版本与模拟器镜像不匹配。解决：等模拟器完全进入桌面再查；仍 offline 就关闭模拟器，用 AVD Manager 冷启动；版本问题看adb version与 SDK 里 platform-tools 是否一致。
坑四：adb shell提示device '(null)' not found，但模拟器窗口正常。原因：adb server 进程异常，设备标识没注册上。解决：adb kill-server后adb start-server，再adb devices；如果 5037 端口被别的程序占用，需要先释放端口。
坑五：把模拟器 IP 改成和电脑同网段后，电脑反而 ping 不通模拟器。原因：模拟器网络是 NAT 模式，改属性值不改变底层 NAT 映射，宿主机到模拟器的入站连接本来就不走这条路。解决：电脑访问模拟器服务用adb forward；需要模拟器主动访问电脑，用10.0.2.2这个宿主机别名，而不是改模拟器 IP。
5. 快速定位模拟器网络问题：一张对照表和三条固定动作
排查这类问题，我习惯先做三条固定动作，再看对照表，基本能在五分钟内把范围缩到 adb 层、模拟器层还是网络配置层。
三条固定动作：
# 动作一：确认 adb 服务与设备状态 adb kill-server && adb start-server && adb devices # 动作二：确认 shell 通道可用 adb shell getprop sys.boot_completed # 动作三：确认网络属性与连通性 adb shell getprop net.dns1 adb shell ping -c 2 10.0.2.2sys.boot_completed返回1才说明模拟器系统真正就绪，返回空或0时后面所有网络操作都不可信。这一步能挡掉大量「模拟器还没起来就急着改配置」的无效操作。
对照表用来快速分流：
| 现象 | 最可能所在层 | 首选动作 |
|---|---|---|
device '(null)' not found | adb 服务层 | adb kill-server+adb start-server |
device offline | 模拟器就绪层 | 等 boot 完成或冷启动 AVD |
getprop有值但 ping 不通 | 网络配置层 | 检查路由与 NAT，改用端口转发 |
| 重启后 IP 恢复默认 | 属性持久化层 | 改用启动参数或固化脚本 |
| 电脑访问不到模拟器服务 | 连接方向层 | adb forward tcp:本地端口 tcp:模拟器端口 |
这张表的价值在于避免「一个报错试所有命令」。我见过太多人对着 offline 反复setprop，方向从一开始就错了。
从那以后我每次动模拟器网络配置前，都强制先跑一遍adb devices加getprop sys.boot_completed，两个都正常才往下走，省下的时间比多敲几条命令多得多。这份操作文档里把adb shell、getprop、setprop的完整顺序和两个典型报错都列了出来，配合上面的排查顺序用，能少走不少弯路。希望帮到你。
本文还有配套的精品资源，点击获取
