4、网络层连接问题：DHCP获取失败、IP地址冲突、DNS解析异常、网关不可达
WiFi连上了，信号满格，但就是上不了网。这恐怕是现场最让人抓狂的场景之一。我早年跑工地时，经常被客户拽到设备前问：“你看，WiFi图标都亮了，为什么APP还是显示离线？”
说白了，WiFi连上只代表你过了“链路层”这一关。真正的通信，还得看网络层。这一层要是出问题，设备就是个“睁眼瞎”——能看到路，但不知道往哪走。
核心观点：WiFi连接成功 ≠ 网络可用。DHCP、IP、DNS、网关，这四个环节任何一个断了，设备都无法正常通信。
4.1 DHCP获取失败——设备拿不到“身份证”
设备连上WiFi后，第一件事就是发DHCP Discover广播，去找路由器要个IP地址。如果这一步卡住了，设备会一直停留在“获取IP中”的状态。
常见原因
- DHCP地址池耗尽：家里或工地上设备太多，IP不够分。我见过一个仓库，200多个传感器挤在一个/24网段里，新设备死活拿不到地址。
- DHCP服务未开启：有些路由器默认关闭了DHCP，或者被误操作关了。
- STA端DHCP客户端异常：设备本身的DHCP协议栈有bug，或者被某些低功耗模式卡住了。
- VLAN隔离：企业网络里，AP和DHCP服务器不在同一个VLAN，广播透传不过去。
排查技巧：抓包看WiFi接口。如果看到设备反复发DHCP Discover，但没有任何Offer回应，基本就是服务端的问题。如果收到了Offer但没发Request，那就是设备端的问题。
我常用的排查步骤
- 先看路由器后台，确认DHCP地址池还有空余。
- 在设备上手动配置一个静态IP，看能不能ping通网关。如果能通，基本锁定是DHCP的问题。
- 检查DHCP报文交互。我习惯用Wireshark抓个几十秒的包，过滤条件写
bootp或dhcp。
# 在Linux设备上手动触发DHCP续租
udhcpc -i wlan0 -b -x hostname:my_device
# 查看当前DHCP租约文件
cat /var/lib/dhcp/dhclient.leases4.2 IP地址冲突——两个设备抢同一个“门牌号”
IP冲突是个老问题，但在物联网场景里特别常见。尤其是那些没有做地址检测的廉价模组，一上电就抢地址。
为什么会这样？有些设备在断线重连后，会直接使用上次保存的IP地址，而那个地址可能已经被别的设备占用了。
注意：IP冲突不会导致WiFi断开，但会导致网络时通时断。设备可能上一秒还能ping通，下一秒就超时了。这种“间歇性抽风”最难排查。
如何确认是IP冲突
- 在PC上ping目标IP，同时用
arp -a看MAC地址。如果MAC地址来回变，那就是冲突了。 - 在路由器后台看DHCP租约列表，找有没有重复的IP。
- 抓包看ARP应答。正常情况下一个IP只有一个ARP回复，如果有两个不同的MAC回复同一个IP，那就是冲突。
# 在设备端主动检测IP冲突（Linux）
arping -D -I wlan0 -c 3 192.168.1.100
# 如果返回0表示地址可用，返回1表示冲突我记得有一次在智能家居项目里，20个灯控面板同时上电，结果有3个面板抢到了同一个IP。现场测试时怎么按都没反应，查了半天才发现是IP冲突。从那以后，我要求所有模组上电后必须先发ARP探测，确认地址没人用才敢用。
4.3 DNS解析异常——知道门牌号，但不知道门在哪
设备拿到了IP，也能ping通网关，但就是连不上服务器。这时候十有八九是DNS出了问题。
说白了，DNS就是把域名翻译成IP地址的“电话本”。电话本丢了，你就算有电话也打不出去。
典型表现
- ping IP地址能通，但ping域名不通。
- 设备日志里出现
DNS resolution failed或getaddrinfo error。 - APP显示“正在连接”，然后超时。
常见根因
| 问题类型 | 具体表现 | 排查方法 |
|---|---|---|
| DNS服务器不可达 | 设备配置的DNS服务器IP是错的，或者服务器挂了 | 用 nslookup 或 dig 测试 |
| DNS缓存污染 | 路由器或设备本地缓存了错误的解析结果 | 清空缓存后重试 |
| 域名未注册/过期 | 服务器域名本身解析失败 | 在PC上直接解析确认 |
| MTU导致DNS报文被丢弃 | DNS over TCP时，大报文被分片后丢失 | 调整MTU或改用EDNS0 |
我的习惯：在设备固件里内置一个“DNS诊断”功能。长按某个按键，设备就会依次ping 8.8.8.8、解析 baidu.com、解析自己的服务器域名。这样现场人员不用抓包也能快速定位。
4.4 网关不可达——出了门，发现路是断的
网关是设备离开本地网络的“大门”。如果网关不可达，设备只能和局域网里的设备通信，出不去。
你想想看，设备拿到了IP，知道了DNS，但就是找不到网关。这就像你有了身份证、有了电话本，但家门口的路被挖断了。
网关不可达的几种情况
- 网关IP配置错误：设备手动配置了错误的网关地址。
- 网关设备宕机：路由器死机了，或者被重启了。
- 路由表缺失：设备没有默认路由，不知道把包往哪发。
- ARP解析失败：设备发ARP问网关的MAC地址，但没人回应。
# 查看设备的默认路由
route -n
# 或者
ip route show
# 手动添加默认路由
route add default gw 192.168.1.1我在项目中遇到过一种情况：设备能ping通网关的IP，但就是上不了外网。后来发现是网关设备本身的路由表坏了，它自己都出不去。这种情况，你查设备端是查不出问题的，必须登录到网关上看。
避坑指南：我曾经在批量部署时，发现一批设备全都连不上服务器。排查到最后，发现是网关设备的NAT表满了。几百个设备同时发起连接，网关的NAT转换不过来，直接把新连接丢了。所以，网关的并发能力一定要提前评估。
4.5 网络层问题排查流程图
下面这张图是我自己总结的排查思路。遇到网络层问题，按这个流程走一遍，基本能定位到根因。
4.6 综合排查清单
最后，我整理了一份快速排查清单。现场遇到问题，按这个顺序查一遍，能省下不少时间。
| 步骤 | 检查项 | 命令/方法 | 预期结果 |
|---|---|---|---|
| 1 | IP地址是否有效 | ifconfig 或 ip addr |
地址不是169.254.x.x（APIPA） |
| 2 | 默认路由是否存在 | route -n |
有0.0.0.0的条目 |
| 3 | 网关是否可达 | ping 网关IP |
收到回复 |
| 4 | DNS是否可用 | nslookup 域名 |
返回正确IP |
| 5 | 外网是否可达 | ping 8.8.8.8 |
收到回复 |
| 6 | 服务器域名解析 | ping 服务器域名 |
收到回复 |
嗯，网络层的问题说复杂也复杂，说简单也简单。你只要记住一句话：IP是地址，网关是门，DNS是电话本。哪个环节断了，就修哪个环节。别一上来就怀疑模组坏了，先看看这些基础配置对不对。