NAT 的必要性
IPv4 地址长期紧缺，蜂窝运营商普遍为物联网卡分配 私网地址（如 10.x、100.64 CGNAT 段），在核心网或 NAT 网关处通过 NAT（Network Address Translation）映射到少量公网地址。对业务而言，终端仍可主动访问互联网或企业 VPN，但外部主机无法随意向终端私网地址发起连接，除非建立静态映射或使用反向隧道。理解这一点有助于区分“平台连不上设备”究竟是网络问题还是架构限制。
会话与超时
NAT 设备维护五元组会话表，空闲超时后映射被回收，长连接可能无声断裂。物联网若采用 MQTT 长连接或自定义 TCP，应配置应用层心跳与 TCP keepalive，间隔需小于运营商 NAT 超时典型值（各网差异较大）。UDP 类协议更敏感，需双向定期报文维持映射。若设备进入 PSM 深度休眠，唤醒后原映射可能已失效，应设计会话重建逻辑。
对称型与锥型差异
不同 NAT 行为（Full Cone、Restricted、Symmetric 等）影响 P2P、语音与某些 VPN 模式。物联网较少做端到端 P2P，但若使用 WebRTC 或打洞方案，需提前在现网验证。企业侧若做 IP 白名单，应注意终端出口公网地址可能随基站切换或 CGNAT 轮换而变化，应改用设备证书或固定接入专线。
排查建议
当业务侧看到“偶发断连”，可在模组侧抓取源端口变化与 TCP 状态，与平台防火墙日志对照。若 ICMP 被禁，PMTUD 与部分诊断工具会失真，应结合应用日志综合判断。对于需要被云端主动下发的场景，优先采用设备先连平台的长连接或短信唤醒，而非假设公网可直接访问终端私网 IP。
地址复用与映射表项
运营商侧的 NAT 把许多物联网卡的私网地址和端口，改写成少量公网地址上的不同端口，从而让终端主动访问外面的服务器。映射表项至少记下源地址、源端口、目的地址、目的端口和协议。表项在空闲一段时间后被删除，之后从公网侧回到原私网端口的包不再有去处。所以“终端能上网”和“服务器能随时找终端”是两件不同的事。静态端口映射或专线才能提供稳定入站；普通上网 APN 上的公网地址还可能属于运营商级转换，出口地址会在基站或负载变化时更换。
业务架构应默认由设备先向平台建立会话，用应用层心跳把表项续租，心跳间隔短于该网络实际回收时间。这个时间因运营商和 APN 而异，要用现网测量，不能抄家用路由器的默认值。需要被叫唤醒时，用短信或平台侧已有的长连接投递，而不是向卡的私网地址发起连接。UDP 没有连接状态，更要靠双向报文续租，只发不收的周期上报会在对端回复时发现映射已经没了。
休眠醒来之后端口作废
设备进深睡前没有关闭 TCP，醒来后原套接字仍显示已连接，第一包数据才发现映射被收掉，应用要到多次重传后才重建。服务器把终端出口 IP 写进白名单，CGNAT 一轮换全部离线，运维误判为模组故障。对称型转换下，终端对服务器 A 和服务器 B 使用的外部端口不同，按对 A 打洞的端口去连 B 一定失败。ICMP 被禁后，有人用 ping 不通来否定 NAT 的存在，业务 TCP 其实是通的。长连接没有心跳、只依赖 TCP 保活的默认两小时，中间的 NAT 早在这之前回收了表项。
唤醒后应主动重新注册，而不是复用睡眠前的套接字。若地址族是 IPv6 且不再经过这类转换，路径会不同，需要单独验证，见蜂窝 IPv6。大包在映射仍有效时也会因路径长度失败，那是MTU 与分片的问题，不要和表项超时混成同一种断线。
测量映射超时要用目标接入点上的真实卡：建立会话后停止发送，逐段加长空闲时间，直到服务器收不到回包，再把心跳定在这个时间之内并留余量。深睡唤醒后的第一条消息应是重新注册，而不是业务数据。服务器侧不要把出口地址当作设备身份，地址会随转换设备轮换；身份放在证书或设备号里。需要入站时改用短信触发或专线固定映射，并在设计说明里写清普通上网接入点做不到被叫。排查断线时同时看模组侧端口是否变化、服务器是否还把包发往旧端口，两边对得上才算同一次会话。
心跳间隔写成配置项并记录测量时所用的接入点。设备身份不用出口地址表示。唤醒后的注册包与业务包分开，注册未完成不发送需要可靠到达的数据。入站需求在方案里明确改走触发或专线，避免开发后期才发现无法被叫。
同一设备对两个目的端口的外部映射可能不同，按其中一个打通的端口去连另一个服务器会失败。把这种现象记在联调说明里，避免现场反复更换天线。