ESP32上传图片至AWS后无响应 多跳转NodeJS请求异常排查

按出现概率从高到低排序：

• TCP连接未做写方向半关闭：当前ESP32逻辑是把UART收到的请求字节全部写入socket后直接等待响应，没有调用shutdown(sock, SHUT_WR)关闭TCP连接的写通道。HTTP/1.1默认使用长连接（Connection: keep-alive），大量服务端框架（尤其是NodeJS生态、多层跳转的微服务网关、反向代理）会等待客户端主动关闭写方向，确认请求全部发送完成后才会返回响应；部分代理甚至会在未收到写关闭信号时，直接缓存住后端已经返回的200响应不转发给客户端。小体积请求因为发送速度快、部分服务端有快速路径处理逻辑不会触发问题，大体积POST、多层跳转的请求大概率踩这个坑，和观察到的「服务端已处理成功返回200但客户端收不到响应」的现象完全吻合。
• 实际发送的请求长度与Content-Length声明值不匹配：构造multipart/form-data请求时如果换行符错误使用\n而非HTTP协议要求的\r\n、二进制图片数据长度计算时遗漏了换行/边界符长度、UART传输大请求时出现字节丢失导致实际发送的body长度比Content-Length短，服务端会持续等待剩余请求内容；部分容错性好的服务端等到超时阈值后会强行处理已收到的请求并返回200，但此时ESP32端因为长时间等待已经处于异常状态，无法正常接收响应。
• 响应解析逻辑存在缺陷，无法正确识别响应结束边界：如果等待响应的逻辑是靠「socket连接断开」判断响应接收完成，在长连接场景下服务端返回响应后不会主动断开连接，会一直保持连接等待下一个请求，ESP32就会一直阻塞在读取操作上直到超时。另外如果逻辑没有处理Transfer-Encoding: chunked分块传输、3xx跳转响应的头部解析，遇到这类响应时无法正确计算响应总长度，也会出现一直等不到响应结束的问题。
• UART传输大流量时的缓存溢出问题：ESP32的UART硬件接收缓存通常只有几百字节，如果SBC侧高速发送请求字节流没有做流控，大体积请求传输时会出现UART缓存溢出丢字节，导致请求格式损坏，服务端和客户端的HTTP状态机不同步，后续的响应读取逻辑完全失效。

按排查优先级从高到低操作：

1. 优先在ESP32端写完所有请求字节后，立刻添加写方向半关闭逻辑，以ESP-IDF的socket API为例，其他SDK接口逻辑一致：

// 仅关闭写方向，读方向不受影响，可正常接收服务端响应
shutdown(sock, SHUT_WR);

80%以上的同类嵌入式HTTP POST问题，加完这行即可解决。
2. 校验请求发送字节数：在ESP32端统计实际写入socket的总字节数，和从UART收到的请求长度、请求头里Content-Length标注的body长度做对比，三个值必须完全匹配。重点检查multipart请求的所有换行是不是\r\n，最后一个结束边界--WebKitFormBoundary7MA4YWxkTrZu0gW--后面必须跟一对\r\n。
3. 补全响应解析逻辑：不要靠连接断开判断响应结束，严格按照HTTP协议规范解析：

• 先读取完整响应头部，解析出Content-Length就按对应长度读取body内容
• 如果头部存在Transfer-Encoding: chunked标识，按分块格式逐块读取，直到读到长度为0的结束块
• 如果收到3xx状态码，要么按Location头自动跟随跳转，要么读完当前3xx响应直接回传给SBC，不要一直阻塞等待

4. 排查UART传输可靠性：给UART传输加简单流控，比如SBC每发128字节就等ESP32回一个确认字节再发下一段，避免高速发送时ESP32缓存溢出丢包；大请求传输时可以打印每一段收到的字节校验和，确认没有字节丢失。
5. 临时验证可在请求头里加Connection: close，告诉服务端返回响应后直接断开连接，简化响应结束的判断逻辑，快速验证是不是长连接处理逻辑导致的问题。

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