使用HTTPS调用接口时Axios/Postman报HPE_INVALID_CONSTANT错误原因排查

核心问题本质 #

这个错误是HTTP解析器在响应最开头没找到HTTP/协议标识导致的，结合curl正常、Postman/Axios异常的差异，主要排查以下几个方向：

1. HTTP协议版本不兼容 #

curl会自动适配服务器支持的HTTP版本（比如HTTP/1.1、HTTP/2），但Postman和Axios可能默认强制使用了服务器不兼容的版本——比如强制启用HTTP/2，但服务器实际仅支持HTTP/1.1，返回的响应格式不符合HTTP/2规范，直接触发解析失败。
验证方法：在Postman中手动将HTTP版本切换为1.1，或在Axios配置中添加httpVersion: '1.1'参数后重试。

2. HTTPS层的协议混淆 #

服务器的HTTPS端口可能存在协议复用问题：比如同时监听HTTP和HTTPS请求，但对Postman/Axios的TLS握手处理异常，返回了未加密的纯HTTP响应；或者服务器TLS配置存在缺陷，curl的容错性更高可以正常处理，但Postman/Axios的解析逻辑更严格，直接报错。

3. 请求头差异触发异常响应 #

curl的默认请求头与Postman/Axios存在差异：比如User-Agent标识、Connection头的设置不同，服务器可能对特定头的客户端返回异常响应——比如识别到非curl的UA时，返回的响应开头缺失HTTP/标识。
验证方法：将curl的请求头原封不动复制到Postman中（包括User-Agent: curl/xxx），再发起请求测试。

4. 服务器对204响应的格式错误 #

204 No Content要求响应头结束后必须包含两个空行，但如果服务器返回的响应仅包含头、未添加空行，或者头的格式本身存在问题，curl可以容错处理，但Postman/Axios的解析器会直接判定为无效响应。

快速排查动作 #

• 用Wireshark抓包，对比curl和Postman的HTTPS响应内容，确认服务器返回的响应开头是否存在HTTP/标识；
• 在Axios配置中添加maxRedirects: 0禁用重定向，避免重定向过程中出现协议混淆；
• 在Postman中关闭「自动跟随重定向」选项，查看原始响应的格式。

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