Node.js Net模块TCP Socket无法向Kemper放大器发送数据问题排查

• 应用层数据不被硬件识别：你提到的UUID差异（安卓是4740，Node.js是4749）是核心诱因。Kemper放大器大概率依赖这个UUID验证请求合法性，收到不匹配的UUID时会直接忽略请求，不返回任何确认（ACK）或响应包。Node.js的TCP栈因长时间收不到对端ACK，就会触发重传机制。
• 数据格式不匹配：网卡添加的头部、硬件返回的00尾缀，说明硬件对通信数据格式有严格要求。如果Node.js发送的数据未包含正确头部（或错误处理了头部），或者缺少硬件期望的结束标识，硬件无法正确解析数据包，同样不会回复，进而引发TCP重传。

• 修正UUID字节：立即将Node.js代码中发送的UUID部分替换为抓包得到的4740（对应十六进制0x47 0x40）。务必用Buffer精确构造这部分数据，避免字符串编码转换导致的字节偏差，示例：

  // 正确构造UUID字节
  const uuidBuffer = Buffer.from([0x47, 0x40]);
  

• 对齐数据包格式：
  1. 对比安卓抓包的完整发送数据包（含网卡头部），确认头部是APP主动添加还是网卡自动插入。如果是APP发送内容本身包含头部，Node.js发送时必须完全复制这部分头部字节；如果是网卡自动添加，只需保证Payload部分和安卓一致。
  2. 检查安卓发送的数据包是否带有00尾缀，若有，Node.js发送数据时也要追加该字节，确保硬件能识别数据包结束。
• 逐字节校验收发数据：把Node.js发送的Hex数据和安卓抓包的Hex数据做逐字节对比，除了UUID，还要排查是否存在其他字节差异（比如数据长度、校验位、编码方式）。可在Node.js中打印发送Buffer的十六进制形式：

  socket.send(sendBuffer);
  console.log('Sent hex:', sendBuffer.toString('hex'));
  

• 增强Socket调试：在Node.js代码中监听error、data、close事件，打印所有收发的原始数据和错误信息，方便定位问题：

  socket.on('data', (data) => {
    console.log('Received hex:', data.toString('hex'));
  });
  socket.on('error', (err) => {
    console.error('Socket error:', err);
  });
  

内容的提问来源于stack exchange，提问作者kraab