使用pycurl发HTTP2 POST请求随机报流未关闭错误 原生curl访问ALB后Nginx正常

你遇到的(92, 'HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR')是典型的客户端与负载均衡层HTTP2实现兼容性问题，和后端Nginx配置没有关系，按以下方向逐一排查即可定位： #

1. 优先验证libcurl版本匹配性 #

• 你当前使用的pycurl 7.43.0.6是2020年发布的旧版本，编译时绑定的libcurl为早期HTTP2实现版本，和系统中原生curl对应的新版libcurl存在核心行为差异。你在代码中强制使用CURL_HTTP_VERSION_2_PRIOR_KNOWLEDGE模式，跳过了TLS ALPN协商环节，旧版libcurl在这种非标准模式下的HTTP2帧构造、空POST处理、连接复用逻辑存在已知bug，触发概率远高于正常ALPN协商的HTTP2流程；而系统原生curl对应的新版libcurl已经修复了这些bug，这也是“原生curl稳定、pycurl随机报错”的核心原因。
• 验证方式：
  • 在pycurl代码中增加版本打印逻辑：

    print(pycurl.version_info())
    

  • 在系统终端查看原生curl对应的libcurl版本：

    curl --version
    

  两个版本的libcurl小版本差超过3个以上，即可确认是版本不一致导致的兼容性问题，升级pycurl到绑定新版libcurl的版本即可解决大部分问题。

2. 对齐原生curl的空POST请求行为 #

你当前代码仅设置了curl.setopt(pycurl.POST, 1)，未显式定义请求体相关元数据，和原生curl的空POST行为存在差异：

• 原生curl执行不带请求体的POST时，会主动携带Content-Length: 0头，明确告知服务端请求无内容，完全符合HTTP2规范。
• 旧版libcurl在HTTP2 prior knowledge模式下，仅设置POST标记不指定请求体时，会漏发Content-Length: 0头，或未正确标记HTTP2 DATA帧的结束位；ALB后端由多个独立的HTTP2处理节点组成，不同节点对不规范请求的容忍度不同，请求被随机调度到严格校验规范的节点时就会返回流级INTERNAL_ERROR，调度到容忍度高的节点时即可正常返回，这刚好对应你遇到的“部分请求成功、部分失败”的随机现象。
• 对应修复代码（补充到现有pycurl配置中）：

  # 显式设置空请求体，对齐原生curl的空POST行为
  curl.setopt(pycurl.POSTFIELDS, '')
  # 显式补充Content-Length头，避免libcurl漏发标准请求头
  curl.setopt(pycurl.HTTPHEADER, ['Content-Length: 0'])
  

3. 临时排查连接复用实现bug #

旧版libcurl在HTTP2 prior knowledge模式下存在已知的连接复用缺陷：会复用已经被ALB半关闭的无效TCP连接，发送到无效连接上的请求流无法被正常匹配处理，就会触发“流未干净关闭”的错误。

• 可临时增加以下配置禁用连接复用，验证是否为这类bug：

  curl.setopt(pycurl.FRESH_CONNECT, 1)  # 每次请求强制新建独立TCP连接
  curl.setopt(pycurl.FORBID_REUSE, 1)   # 请求完成后主动关闭连接，不放入全局连接池
  

  如果加上上述配置后报错概率大幅下降，即可确认是旧版libcurl的连接复用实现问题。

注：你编写的Nginx配置不存在逻辑问题，只要请求能正常到达后端，就可以返回预期的200 JSON响应，不需要调整Nginx规则。

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