现象：一句“连接成功”，把人带进沟里
一位运维工程师在电话里的原话是：“数采仪屏幕上一路绿灯，连接状态显示成功，心跳也在跳，可平台上那个数据表就是空的，一条都没有。”这种描述，在启用SM4国密加密的现场几乎每周都能听到。
结论先说：九成以上不是网络掉线，而是报文进了平台、平台解不出来，或者设备根本没把CP数据段换成密文。前者是密钥、工作模式、填充方式这三件事对不上，后者是加密开关开了但报文结构没跟着变。这两类问题在设备端看起来完全一样，都是“连接成功”。
加密一开，最先坏掉的为什么总是CP段
HJ 212 报文的骨架没变：QN 请求编码、ST 系统编码、CN 命令编码、PW 访问密码、MN 设备唯一编号、Flag 标志位、CP 数据段，末尾是 && 加四位 CRC16 校验。国密改造动的地方通常只有一处——把 CP 段整体加密后塞回报文，或者只加密其中几个关键字段。于是链路层和业务层就被切开了：TCP 是通的，但 CP 段是密文，平台解不开就是空数据。
协议层：报文格式没跟着加密一起变
- CP 段还是明文，但平台侧加密开关是开的，平台按密文去解，全部失败；
- 密文编码不一致：设备侧输出 HEX（大写或小写），平台按 Base64 解；或者反过来；
- SM4 工作模式不一致：常用 ECB 和 CBC，设备出厂默认 ECB，平台要求 CBC；
- CBC 模式下 IV 初始化向量对不上：一方用全零固定 IV，一方每包随机 IV 却没随包带过去；
- 填充方式不一致：PKCS#7 补齐到 16 字节，还是零填充，还是要求明文长度正好是 16 的整数倍不填充；
- 密钥长度不对：SM4 密钥必须是 128 位，也就是 32 个十六进制字符。现场最容易犯的错，是把 16 位 ASCII 口令直接当密钥喂进去；
- 大小写和空格：从平台复制密钥时末尾多了一个空格，或者十六进制被转成了大写；
- CN 命令码还在用旧的 1014 提取分钟数据、2000–2999 历史数据补传，而这两条通道在加密改造后数据段结构变了，补传没同步改。
网络层：心跳 9011 通了不代表业务通
- 9011 心跳包体积小、字段少，多数平台对心跳不做解密校验，所以心跳永远是绿的；
- TCP 长连接被 NAT 或防火墙按超时策略断开，设备重连后没有重新协商密钥；
- 端口是通的，但平台只放行了未加密的 2011 实时上传，加密通道走的是另一个端口。
设备层：加密模块起来了，但没走到数据上
- 固件版本偏低，界面上有加密菜单，实际不生效；
- 密钥写进去了，没保存、没下发、没重启；
- 设备时钟和平台差得太多，加密包里带时间戳的，时间差一大平台直接丢弃；
- 多个 MN 共用一套密钥，平台按 MN 分表存密钥，配错一个就一台不传。
平台层：设备没问题，平台侧配置没对上
- 平台侧该设备的密钥还是上一批的，没随设备一起换；
- 平台按 MN 下发密钥，设备上报的 MN 大小写或前后空格不一致，对不上表；
- 平台对 2011 实时、2051 分钟、2061 小时几个上传命令的加密策略不一样，设备一刀切全加了。
排查顺序：从平台往回倒推，比从设备往前试快得多
顺序本身就是知识。建议的顺序是：先看平台侧解密日志，再看设备发出的原始报文，接着核对密钥、模式、填充，最后才查网络和时钟。
- 平台侧的解密日志，是唯一能直接告诉你“这包能不能解”的证据，一次就能把问题定位到协议层还是别的层；
- 抓设备侧原始报文，看 CP 段是不是真的变了样：还是明文，问题在设备；已是密文但平台解不开，问题在密钥；
- 密钥、模式、填充这三项是配置项，核对成本最低，几分钟能排完，不该放到最后；
- 网络和时钟放最后，因为它们的典型表现是“断”和“丢”，不是“连上了但没数据”。一旦看到连接成功，这两项的嫌疑已经掉了一大半。
每一步怎么判断、怎么处置
- 现象：平台日志显示“报文接收成功、解密失败”。判断：密文进了平台，但密钥或模式不对。动作：先在平台侧核对该 MN 的密钥是否为 32 位十六进制，再确认工作模式和 IV。
- 现象：平台日志里压根没有报文。判断：设备根本没发，或发的明文被平台拒绝。动作：抓包看 CP 段首字符，密文一般是 Base64 的字母数字，或 HEX 的 0-9A-F。
- 现象：密文长度不是 16 的整数倍（HEX 应为 32 的倍数，Base64 应为 4 的倍数）。判断：填充方式不一致，或报文被截断。动作：统一用 PKCS#7，Base64 编码时确认没有换行符。
- 现象：只有 2051 分钟数据不传，2011 实时数据正常。判断：平台对不同 CN 命令的加密策略不同。动作：逐个命令核对，别一次性全改。
- 现象：换密钥后前台显示已保存，重启后平台侧仍是旧密钥。判断：密钥没真正下发到加密模块。动作：断电重启后在设备参数页回读一次，别只看保存提示。
- 现象：偶尔能传几条，多数丢。判断：时间戳偏差，或 IV 随机但未同步。动作：先校时，再统一 IV 策略为固定或随包携带。
三个最容易误判的坑
坑一：把“连接成功”当成“链路没问题”
设备上的连接状态只反映 TCP 三次握手和心跳。9011 心跳包通常只有 QN、ST、CN、MN 几个字段，平台不一定对它做解密校验。所以心跳一直是绿的、业务数据一条没有，这两件事完全能同时成立。
坑二：拿在线工具解出来了，就认定设备没问题
网上那些在线 SM4 解密工具，默认参数大多是 ECB 模式加 PKCS#7 填充、密钥按十六进制解析。设备这边可能是 CBC 加零填充、密钥按 ASCII 解析。同一段密文，工具能解、平台解不了，是常态。判断时必须让工具参数和平台完全一致，否则这个结论一点用都没有。
坑三：凭密文长度判断“设备发的是空的”
明文 100 个字符，Base64 之后长度涨三分之一左右，HEX 之后翻倍，再算上 16 字节分组的补齐，变化更大。看到报文变长就以为设备在乱发数据，或者看到长度不是整数倍就怀疑设备故障，其实只是编码和填充的差异。
关于 SM4国密加密 的几个常见问题
问：我这个情况到底要不要上国密？
看两点。一是属地生态环境部门对上传通道有没有加密要求，二是你的数据接的是哪一级平台。部分省份的省级平台已经在要求国密通道，市县平台还没跟上；这种情况一般按最严的那一级来配，不然改一次要停一次数。拿不准就直接找平台运维方要一份接入参数说明，里面会写清楚加密方式和密钥下发方式。
问：数采仪显示连接成功，平台就是没数据，是不是国密的问题？
先别急着归到国密。最快的判断办法是看平台侧有没有收到报文、收到后报什么错。平台显示“接收成功、解密失败”，那基本是密钥或模式的问题；平台连报文都没收到，那要先查设备有没有真的把数据发出去，可能压根没走到加密这一步。
问：密钥换了之后要不要重启？
要。大多数数采仪的加密模块是在进程启动时加载密钥的，前台点“保存”只写进了配置文件，没进内存。换完密钥断电重启一次，再回参数页确认读回来的密钥是一致的。
问：平台那边说解密失败，我这边能自己验证吗？
能，但参数必须对齐。找平台要一份完整接入参数：算法、工作模式、填充方式、IV 取值、密文编码、密钥的字符集解析方式。然后拿设备发出的一段原始报文，用同样参数在本地解一次。能解开说明设备侧没问题，问题在平台配置；解不开就顺着参数一项项对，通常卡在填充方式和 IV 上。
问：一台设备能不能同时写两套密钥？
可以，但要按 MN 分开配。常见做法是主备两个平台各一套密钥，设备按上报通道切换。要注意切换通道时密钥得跟着切，否则就会出现这条通道通、那条通道空的情况。切换逻辑最好在设备侧配好，别靠人工改。