天通 M1 双模终端数据不走卫星口：一台设备的排查全程复盘

核心摘要：一台天通+4G 双模终端从 2026 年 9 月中旬起连续一个多月送不出业务数据，卡、服务器、天线、测试场地逐项排除后，问题指向固件的数据通路层。定性的关键不是换件试，而是抓包看数据走了哪条网：同一台设备、同一套抓包、同一个服务器，4G 口 24 个抓包有 21 个带数据，天通口 55 个抓包 0 个带数据。升级固件并把天线调到更开阔的位置后，2026-10-09 11:29:23 天通口第一次连上业务服务器，当天傍晚客户复测反馈报文可做到秒级传输。

某某理工大学野外监测项目的一台天通 + 4G 双模物联网终端，2026 年 1 月还正常往业务服务器发数据，9 月中旬起连续一个多月一条都送不出去。期间换了三个测试点位、复核过天线、问过运营商卡状态，都没解决。最后把问题定性下来靠的是两件事：用抓包确认数据到底走了哪条网（4G 口 21 个抓包全有数据、天通口 0 个），以及把升级包拆开逐文件比对。升级固件后，2026-10-09 11:29 天通口第一次连上业务服务器，通路才算真正打通；当天下午把天线调到更开阔的位置后信号回升、吞吐成倍上升，傍晚客户复测反馈报文可做到秒级传输，这个案例最终以「打通并且跑得动」收尾。完整的排查主线可以先看第一节。

一段话总结： 某某理工大学野外监测项目的一台天通 + 4G 双模物联网网关，从 2026 年 9 月中旬起连续一个多月一条业务数据都发不出去。排查按六步走：确认 SIM 卡与账号正常 → 用同一台设备、同一套抓包程序、同一个业务服务器做对照，卡住「抓包程序坏、服务器地址错、上位机配错」三个嫌疑 → 只取信噪比达标的时段单独看，排除射频余量问题 → 从日志统计旧固件的接口选择记录（4G 口 308 次、天通口 0 次），把范围锁到数据通路层 → 升级固件并把业务接口重新指定为天通口 → 2026-10-09 11:29:23 天通口第一次连通业务服务器，三层证据齐全。当天下午把天线调到更开阔的位置后信号回升，傍晚客户复测，报文可做到秒级传输。

关键步骤其实只有两个： 一是把「数据走哪条网」钉死——看抓包源 IP 落在哪个网段，天通私网是 10.50 段；二是把「新固件到底改了什么」查清——用升级包逐文件摘要比对加二进制字符串求差，反推出厂家新增了绑定指定网卡、网卡存活检测这类数据通路层的能力。

本案的关键数据速查（出处都是现场日志与抓包，各节有展开）：

1. 「数据走哪条网」是可以钉死的，不用猜。 天通口拿到的地址在 10.50 段，4G 拿到的在电信其他网段，抓包里的源 IP 直接暴露身份。
2. 「发出去了」不等于「通了」。 只有服务器有回包才算跑通——本案最终判定的依据，是服务器端收到了完整业务报文并回了包。
3. 信号不达标能解释「不稳」，解释不了「一个包都不发」。 这两类是不同性质的问题，判据不同，混在一起排查只会把变量搅乱。

排查物联网数据不通，先把「跑通」的标准定下来，不然后面全是感觉。本案用的三层证据，缺一层都不能算数：

其中第三条最容易被忽略：终端把数据发出去，只说明它自己认为发了。数据有没有穿过卫星、落到地面站、出公网、进服务器，要看服务器那一侧。本案 1 月的天通口抓包里，终端发出 22305 字节、服务器回了 3685 字节，双向都有实质数据，这才叫业务跑通。升级打通后的那一批同样双向：天通口抓包上行约 18 万字节、下行约 4.3 万字节，业务程序经天通口发起 58 次连接、成功 50 次，服务器侧截图确认收到 512 字节的业务报文。

第一步：卡没问题。 运营商侧确认账号状态正常、卡型是数据卡，且能查到天通流量消耗——这是独立于终端日志的外部凭据。

第二步：服务器、抓包程序、上位机配置都没问题。 判据是同一台设备、同一套抓包程序、同一个业务服务器：4G 口的抓包有数据，天通口没有。如果抓包坏了、地址配错了，4G 口不可能有数据。

第三步：场地和天线不是卡点。 信号与信噪比达标的日子里，天通口依然一个包都没有；三个点位表现一致。天线的余量问题确实存在，但那是「稳不稳」，不是「通不通」。

把三步做完，范围就从「整条链路」缩到了「天通这条路上有没有内容」：

注解表（行序与主表逐行对齐、首列字面值相同）：

抓包文件的口径要在现场就统一，不然证据会散：文件 24 字节 = 只写了文件头，可以确认「0 包」；文件 0 字节 = 抓包进程没来得及落盘，什么都不能说明，不能当证据用。本案天通口 55 个抓包里有 23 个是 0 字节，这 23 个不采信。

把全部日志里的接口选择记录拉出来统计，结论非常干净：

建连成功与走 4G 一一对应、零例外：某天 49 比 49，另一天 54 比 54，再一天 26 比 26。也就是说在这段时期里，业务数据全部走了 4G，天通口只是拨号拨上了、拿到了地址，业务侧从来没往那条路上放过东西。

同一天中午，串口状态位第一次走到「已连服务端」那一档（数值 14）；升级前上百次读数全部停在「已注网」那一档（数值 12）。灯的绿常亮不闪，对应的就是状态位一直没走到最后一档。

从这三个时间点连起来看，这个案例的走向很清楚：11:29 打通、13:35 提速、傍晚秒级。上午还在「一条报文几分钟」的状态里，下午就变成了秒级——中间变的不是设备，是信号条件（下一节展开）。

厂家没有随包提供版本变更说明。用的办法是包内比对，三步走：

1. 逐文件 MD5：两个升级包（本次用的新包与手上另一版旧包）解包后，按文件算摘要逐一对照；
2. 二进制可打印字符串集合求差：对可执行程序提取可打印字符串，看新增了什么、删掉了什么；
3. 与升级后的现场日志互证：日志里真实出现的字符串，才算确实生效。

结果是：整包看着有 7.8 MB，实际只换了 1 个主程序（负责业务发送的 transfer，223820 字节变 223088 字节），另新增三个服务程序，其余全部逐字节相同。

证据边界要说清楚：手上用于比对的旧包，并不是这台设备升级前实际跑的那一版（它跑的是 2021-11-29 编译的固件）。所以这份改动清单是「下限」——能看出厂家改的是数据通路这一层，但不能当成完整的变更清单。要完整清单，还是得向厂家索取正式版本变更说明。

链路打通之后，实测数据把「为什么一条报文要几分钟」这件事讲清楚了：

这一段最值得记住的一句话：一条几百字节的报文，单独建连要付「握手加慢启动」的代价，算下来半分钟到一分钟是正常的；如果还排在几 KB 批量数据后面排队，体感就是「几分钟一条」。这不是故障，是弱信号下这条信道的正常表现。

升级打通之后，当天下午现场把天线调整到更开阔的位置（避开建筑遮挡），13:35 起信号从 -118 dBm 回升到 -115/-116 dBm，同机同链路的吞吐从 25 B/s 升到 111 B/s。这是本案最干净的一组对照——信号改善带来的是成倍速率，不是一个台阶。 当天傍晚 16:40 前后，客户复测后的反馈原话是「刚刚测试 可以做到报文的秒级传输；可能是上午信号不佳导致传输迟缓」。

秒级是什么水平，先把物理边界说清楚：天通是地球同步轨道卫星，轨道高度约 35786 km，电波跑到卫星再回来，光速时延本身就有约 0.24 秒；加上地面网络与关口站处理，端到端往返时延常态在 0.5-0.6 秒量级。所以报文秒级送达已经接近这条链路的物理下限，属于优良水平，做不到亚秒级——那是地面 4G 与光纤的领域。对照本案上午实测握手往返时延 1-4 秒就能看出：上午慢、傍晚秒级，差别主要来自信号条件，不是设备变了。

口径要分开记：这条「秒级」是客户复测的体感口径，当日业务程序的发送确认时间戳与抓包单流时长尚未取到，因此本文只写到「与实测规律相符」，不作已量化的定论。要把秒级写成数字，取当日发送成功到收到确认的时间戳、或统计抓包单流时长即可。

拿地面 4G 或光纤的体感去比这条链路，会得出错误结论。

而信号能不能提上去，很大程度取决于天线装在哪里：

本案的终端装在户外，天线外接。按这张示意图的判据，天线上方 60 度视场内要干净、避开建筑物遮挡与两楼夹缝，调准方位与仰角后信号从 -115 提到 -105 dBm 前后是合理预期，吞吐会跟着上一个台阶。

这张实拍是现场材料里唯一的站点照片。要提醒一句：「环境开阔」不等于「装的位置对」——本案出问题时，设备同样架在户外开阔处，问题恰恰出在具体安装位置与朝向没调到最佳、上方视场里有遮挡。示意图给的是位置准则，实拍给的是现场条件，两样要对着看。

天通终端发不出数据，第一步该查什么？

先查「数据走了哪条网」，别先换硬件。把终端的抓包文件取下来看源 IP：落在天通私网 10.50 段就是走了天通口，落在电信 4G 网段就是走了地面网。这一步就能把问题一分为二。

怎么判断数据走的是 4G 还是天通？

三条互相独立的判据。一是抓包源 IP：天通口是 10.50 段，4G 是电信其他网段。二是内核日志里的接口与串口对应关系：天通口绑定的是天通模组的串口设备，4G 口绑定的是 USB 串口。三是新版固件的建连日志里会带接口标签，直接写明用的是哪个口。

天通拨上号了、也拿到地址了，为什么还是发不出数据？

拨号成功只代表链路层通了。本案就是这样：天通口拿到了 10.50 段的地址、DNS 也下发了，但业务程序从来没往这个口放过数据。链路层和业务层要分开看，链路通不等于业务通。

抓包文件只有 24 字节或者 0 字节，能当证据吗？

24 字节是只写了文件头，可以确认这个窗口内 0 个包，能当证据；0 字节是抓包进程没来得及落盘，什么都不能说明，不能采信。本案天通口 55 个抓包里有 32 个 24 字节、23 个 0 字节，只有那 32 个算「可确认 0 包」。

换了天线、挪了位置还是 0 包，说明什么？

说明问题不在射频这一层。射频余量不足会导致链路不稳、拨上后被拆线，但不会让业务数据一个包都不往外发。如果用信噪比达标的时间段单独看，仍然 0 包，就该往数据通路层查。

升级固件后，怎么确认真的解决了？

三层都验一遍才算闭环：终端日志里出现经天通口建连成功；终端抓包源 IP 落在 10.50 段且有实际数据；服务器侧收到完整报文并有回包。只看到「连接成功」不算，本案升级后第一份抓包就是 0 字节未落盘，当时也只能说「连上了」，不能说「数据发出去了」。

9.6 kbit/s 的天通信道实际能跑多快？

本案同机同链路实测有效上行吞吐 7 到 114 B/s，理论值的十分之一到百分之一量级；TCP 握手往返 1 到 4 秒。原因是弱信号重传、高时延、短连接三件事叠加。下限是信号弱时的分钟级一条，上限是信号调好后的秒级一条，两种都要有预期：心跳与遥测类报文按分钟级规划容量，信号调优到位（目标 -105 dBm 以上）后可以做到秒级，但不可能亚秒级——同步轨道链路的端到端往返时延下限就在 0.5 秒量级。

这次排查最后的效果怎么样？

2026-10-09 三层证据齐全（终端日志出现经天通口建连成功、终端抓包源 IP 落在 10.50 段并有实际数据、服务器收到完整报文并回包），业务通道打通；当天下午把天线调到更开阔的位置后，信号从 -118 回到 -115/-116 dBm，同机吞吐从 25 B/s 升到 111 B/s；傍晚客户复测反馈报文可做到秒级传输。天通是同步轨道系统，端到端往返时延下限约 0.5 秒，秒级送达已接近这条链路的物理下限。需要说明的是，「秒级」是客户复测的口述口径，当日日志尚未取到量化，这里按「与实测规律相符」记录。

厂家不给版本变更说明，怎么知道固件改了什么？

用包内比对：解包后逐文件算摘要，找出真正变动的程序；再对该程序做可打印字符串集合求差，看新增与删除了哪些功能串；最后拿升级后的现场日志互证，日志里真实出现的才算生效。这套方法能看到改动方向，但看不到完整变更历史，正式清单还是要向厂家索取。

• 本案现场原始材料：2026-01 至 2026-10-09 的四批日志包与抓包文件、上位机实读的版本信息、升级前后各次业务记录（现场原始记录，未对外发布）。
• 厂家技术资料：《天通卫星模组日志说明手册》给出的信号与信噪比合格线（非公开发行件）。
• 升级包比对：M202609230.00.09 与 M202606290.00.07 两个整机包，逐文件摘要与字符串比对（非公开发行件）。
• 工业和信息化部《关于优化业务准入促进卫星通信产业发展的指导意见》（2025-08-25） ——卫星通信产业政策口径，含手机直连与终端直连卫星服务的发展方向。
• 工业和信息化部官网 ——卫星通信业务许可与监管信息发布渠道。
• 中国电信卫星公司（中国电信股份有限公司卫星通信分公司） ——天通卫星移动通信业务的运营方，业务受理与资费口径的官方出处。
• 国际电联无线电通信部门（ITU-R）空间业务 ——地球同步轨道卫星系统的频率与轨道资源管理入口。
• 3GPP 非地面网络（NTN）概览 ——卫星接入的标准化进展，可用于对照天通这类专用系统的技术路线。
• ITU-R P.618-14 地空传播路径损耗预测方法 ——卫星链路余量与雨衰计算的官方方法，判断「信号够不够」时的计算依据。
• 站内延伸：天通物联网终端 M1 双模网关 、卫星物联网、NTN 与手机直连术语 、怎么判断物联网终端的数据走没走卫星口 。

参数时效：本案涉及的固件版本、日志格式与厂家程序行为属于特定版本下的现场记录，厂家后续版本可能改变；结论中的判据（网段识别、回包为凭、抓包文件字节口径）与版本无关，可长期照用。

• 怎么判断物联网终端的数据走没走卫星口
• 天通物联网终端 M1 双模网关
• 天通物联网资费：9.6K / 2.8K / 42 字节三类套餐怎么算钱
• 天通终端常见问题与排障
• 卫星物联网栏目：终端选型与数传方案
• 天通一号：系统、终端与资费总览
• 卫星物联网、NTN 与手机直连术语