3、网络层排查：IP地址获取、Ping测试、路由追踪与DNS解析
设备连不上云，十有八九是网络层出了问题。我排查过上千台掉线的物联网设备，最怕的就是那种“灯亮着，数据就是上不来”的情况。说白了，网络层就是设备的“身份证”和“地图”——它得知道自己是谁（IP），知道网关在哪（路由），还得知道服务器叫什么（DNS）。
这一章，咱们就把这四个环节拆开揉碎了讲。你跟着我的思路走一遍，大部分网络层问题都能定位到根因。
核心排查路径： IP地址获取 → 网关连通性 → 路由可达性 → DNS解析
任何一个环节断裂，设备就是“孤岛”。
3.1 IP地址获取：设备的第一张“身份证”
设备上电后第一件事，就是给自己弄个IP地址。要么找DHCP服务器要，要么自己写死一个静态IP。我见过太多设备“掉线”，其实就是IP没拿到。
3.1.1 DHCP方式
大部分物联网设备默认用DHCP。设备发一个广播包，DHCP服务器回一个IP租约。这个过程叫DORA（Discover、Offer、Request、Ack）。
快速验证方法： 在设备上执行 ifconfig 或 ip addr，看有没有拿到IP。如果IP是169.254.x.x，那就是DHCP失败了——这是Windows的APIPA自动分配地址，说明设备没找到DHCP服务器。
我在一个智能路灯项目里遇到过：200盏灯，每天早上有30盏连不上。查了半天，发现是DHCP租约时间设成了1小时，而路灯夜间断电超过1小时，第二天IP已经被分配走了。后来我把租约改成24小时，问题解决。
3.1.2 静态IP方式
工业设备、网关节点，我建议用静态IP。稳定，不依赖DHCP服务器。但有个坑——IP冲突。
静态IP配置避坑指南：
- IP地址必须在子网范围内（比如网关是192.168.1.1/24，设备IP就得是192.168.1.x）
- 子网掩码必须一致（常见的是255.255.255.0）
- 默认网关必须填对（填错了，设备能Ping通局域网，但出不去）
- DNS服务器至少填两个（主备）
我曾经帮一个工厂排查产线设备掉线问题。30台设备，每天随机掉3-5台。我抓包一看，好家伙，有人把一台新设备的IP设成了和PLC一样的地址。IP冲突导致两台设备轮流掉线。从那以后，我要求所有静态IP必须登记在Excel表里，上线前先Ping一下。
3.2 Ping测试：最直接的连通性验证
拿到IP之后，第一件事就是Ping网关。网关是设备出局域网的大门，门都出不去，就别提连云了。
3.2.1 标准Ping测试步骤
# 在设备上执行
ping 192.168.1.1 # Ping网关，看局域网通不通
ping 8.8.8.8 # Ping公网IP，看能不能出互联网
ping baidu.com # Ping域名，看DNS解析+网络连通性Ping不通怎么办？别慌，按顺序排查：
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| Ping网关不通 | 网线/网口故障、VLAN配置错误、防火墙拦截ICMP | 检查物理连接、交换机端口配置 |
| Ping公网IP不通，但网关通 | 网关NAT配置问题、运营商限制、路由表缺失 | 检查网关的默认路由和NAT规则 |
| Ping域名不通，但公网IP通 | DNS解析失败 | 检查DNS服务器配置 |
我的经验： 很多物联网设备默认禁用了ICMP响应。如果Ping不通，先确认设备是否开了ICMP。有些路由器也默认禁Ping，别被假象迷惑。
3.3 路由追踪：找到数据包的“迷路”点
Ping通了网关，但连不上云服务器。这时候就需要路由追踪了。它能告诉你数据包走到哪一步丢了。
3.3.1 常用命令
# Windows
tracert 8.8.8.8
# Linux/Mac
traceroute 8.8.8.8
# 物联网设备（如果支持）
mtr 8.8.8.8 # 结合Ping和路由追踪，更好用输出结果里，每一跳就是一个路由器。如果某跳显示 * * * 或者超时，那问题大概率出在这一段。
我记得有个项目，设备在北京，服务器在杭州。设备Ping网关通，Ping公网IP也通，但就是连不上服务器。我跑了一次traceroute，发现数据包走到某个运营商节点后就没了。后来联系运营商，发现是路由策略问题，绕路了。
小技巧： 如果traceroute中间某跳超时，但后续跳又能通，那可能是那个节点禁用了ICMP，不用太担心。如果连续3跳以上超时，那才是真断了。
3.4 DNS解析：域名转IP的“翻译官”
设备连云服务器，通常用域名（比如 iot.aliyun.com）。DNS就是把域名翻译成IP地址的。翻译错了，设备就找不到服务器。
3.4.1 常见DNS问题
- DNS服务器不可达： 设备配置的DNS服务器IP不对，或者DNS服务器挂了
- DNS缓存污染： 设备或路由器缓存了错误的DNS记录
- 域名解析超时： DNS查询超时，设备等不到回复
- DNS劫持： 运营商或恶意设备篡改DNS响应
3.4.2 排查方法
# 在设备上执行
nslookup iot.aliyun.com # 查看解析结果
dig iot.aliyun.com # 更详细的DNS查询
# 检查DNS服务器连通性
ping 8.8.8.8 # 先确认能Ping通DNS服务器
nslookup iot.aliyun.com 8.8.8.8 # 指定DNS服务器查询如果nslookup返回了IP，但设备还是连不上，那可能是设备固件里写死了某个IP，或者DNS缓存没刷新。我遇到过一台设备，固件里写死了5年前的服务器IP，换了服务器之后，设备一直连旧的IP，当然连不上。
重要提醒： 物联网设备通常有DNS缓存。改了DNS配置后，记得重启设备或清除缓存。有些设备缓存时间长达24小时，你改了配置，它第二天才生效。
3.5 综合排查实战：一个真实案例
去年帮一个智慧农业项目排查。大棚里的温湿度传感器，每天下午3点准时掉线，5点自动恢复。我一开始以为是网络问题，结果发现：
- DHCP获取IP正常（设备IP没变）
- Ping网关正常（延迟1ms）
- Ping公网IP正常（延迟20ms）
- Ping服务器域名超时
问题出在DNS。我查了DNS服务器日志，发现每天下午3点，DNS服务器会做一次缓存清理，导致域名解析临时失败。而设备固件里，DNS查询超时时间设成了30秒，重试次数只有1次。所以一旦DNS超时，设备就认为服务器不可用，直接断连。
解决方案很简单：把DNS查询超时改成5秒，重试次数改成3次。再也没掉过线。
总结一下排查顺序：
- 先看IP：
ifconfig或ip addr，确认IP、掩码、网关 - 再Ping网关： 确认局域网连通性
- 然后Ping公网IP： 确认互联网连通性
- 接着路由追踪： 找到丢包点
- 最后检查DNS：
nslookup或dig
按这个顺序走，90%的网络层问题都能定位。剩下的10%，可能是防火墙规则、MTU问题或者运营商限制，那就要抓包分析了。
嗯，网络层排查就这些。记住，别一上来就怀疑设备坏了。先看看IP拿到了没，网关通不通。很多时候，问题就出在最基础的环节。