2. 网络层排查：检查网络连通性、DNS解析问题、防火墙与端口策略
设备身份注册失败，十有八九卡在网络层。我这些年排查过的案例里，大概有六成都是网络问题伪装成了「证书错误」或「服务器拒绝」。说白了，设备连不上服务器，后面所有加密握手、身份认证都是空谈。
这一节我们聚焦三个最常出问题的点：网络通不通、域名能不能解析、端口有没有被拦。按这个顺序查，能省下大量时间。
核心原则：先验证连通性，再验证DNS，最后验证防火墙。跳过任何一步都可能让你在错误的方向上浪费半天。
2.1 网络连通性检查
先问一个问题：设备能ping通服务器吗？
我个人习惯，拿到注册失败的设备，第一件事就是ping目标服务器IP。注意，这里说的是IP地址，不是域名。先绕过DNS，直接验证网络层是否可达。
小技巧：如果设备在NAT后面，先ping网关。网关不通就别折腾服务器了，先修本地网络。
具体怎么做？我一般分三步走：
- ping网关 —— 确认设备到本地路由器的链路正常
- ping服务器IP —— 确认公网路由可达
- ping服务器域名 —— 初步验证DNS是否工作（但这一步不绝对）
我在项目里遇到过一种情况：设备能ping通网关，但ping不通服务器。查了半天，发现是设备的默认路由丢了。你想想看，设备能访问局域网，但出不去，注册当然失败。这种问题在嵌入式设备上特别常见，尤其是刚烧完固件、网络配置没持久化的时候。
注意：有些服务器禁用了ICMP，ping不通不代表网络不通。这时候要用tcping或telnet验证端口连通性，后面会讲。
2.2 DNS解析问题
ping通了IP，但注册还是失败？好，接下来查DNS。
设备注册时，通常用域名连接服务器。如果DNS解析出错，设备连服务器都找不到，更别说注册了。
我常用的排查命令：
# 在设备上执行
nslookup iot-register.example.com
# 或者用dig（如果设备支持）
dig iot-register.example.com
# 查看本地DNS配置
cat /etc/resolv.conf常见的DNS问题有这几类：
| 问题类型 | 现象 | 典型原因 |
|---|---|---|
| DNS服务器不可达 | nslookup超时 | 设备DNS配置错误，或DNS服务器挂了 |
| 域名解析失败 | 返回NXDOMAIN | 域名拼写错误，或DNS记录未生效 |
| 解析到错误IP | 能解析，但连不上 | DNS缓存污染，或CDN调度异常 |
| 本地hosts覆盖 | 解析结果与预期不符 | /etc/hosts中有错误条目 |
我曾经排查过一个案例：设备注册成功率只有30%，时好时坏。查了三天，最后发现是设备用的公共DNS服务器偶尔返回超时，换成内网DNS就稳定了。嗯，这里要注意，物联网设备对DNS的依赖比PC更敏感，因为很多设备没有重试机制，一次失败就直接报错了。
建议：生产环境中，给物联网设备配置至少两个DNS服务器，并且优先使用内网DNS。如果必须用公网DNS，记得在设备端实现DNS重试逻辑。
2.3 防火墙与端口策略
网络通了，DNS也对了，注册还是失败？八成是防火墙在搞鬼。
设备身份注册通常使用HTTPS（443端口）或自定义的加密端口。但很多企业网络只开放了80和443，如果注册服务跑在8443、8883这类端口上，就会被防火墙拦下来。
我建议按这个顺序排查：
- 确认注册服务端口 —— 先搞清楚服务器到底监听哪个端口
- 测试端口连通性 —— 用telnet或nc验证
- 检查中间防火墙 —— 包括设备侧防火墙、企业出口防火墙、云平台安全组
端口测试命令：
# 测试TCP端口是否开放
telnet iot-register.example.com 443
# 或者用nc（netcat）
nc -zv iot-register.example.com 443
# 如果设备不支持telnet，用设备自带的工具
# 比如一些IoT SDK提供了socket测试函数这里有个坑：很多物联网设备用的不是标准Linux，没有telnet和nc。我遇到过一台设备，只能用自研的AT指令测试网络。这种情况下，我一般会在设备日志里找socket connect的返回值——如果返回-1或超时，基本就是防火墙拦截了。
经验之谈：如果设备在企业内网，IT部门可能启用了出站防火墙白名单。你需要把注册服务器的IP和端口加到白名单里。我曾经因为漏加一个端口，导致设备注册失败，排查了整整两天。
防火墙策略的常见问题汇总：
| 场景 | 现象 | 解决方案 |
|---|---|---|
| 设备侧防火墙拦截 | 设备无法发起任何外连 | 检查iptables或设备防火墙规则 |
| 企业出口防火墙拦截 | 内网设备无法连接公网服务器 | 申请开放目标IP和端口 |
| 云平台安全组未放行 | 服务器收不到设备请求 | 检查云安全组入站规则 |
| 运营商/ISP拦截 | 特定端口被运营商封锁 | 改用标准端口（443）或申请ISP解封 |
重要提醒：有些防火墙会做深度包检测（DPI），即使端口开放了，如果流量特征不符合HTTP/TLS协议，也可能被拦截。我遇到过MQTT over TLS的流量被DPI误判为异常流量而丢弃的情况。解决办法是确认防火墙策略是否做了协议识别，必要时关闭DPI或添加白名单。
最后说一句：网络层排查是设备身份注册的基础，但也是最容易被忽视的环节。很多工程师一上来就查证书、查密钥，结果折腾半天发现是网络不通。我的建议是——先通网，再谈安全。网络层没问题了，我们再往下走，去排查传输层和应用层的问题。