我在AWS Application Load Balancer后面的应用程序中遇到了相同的错误，使用命令：

curl "https://console.aws.example/api/xxx" -b "SESSION=$SESSION"

15：14：30卷发：（92）HTTP/2流% 1未完全关闭：PROTOCOL_ERROR（错误1）
我不得不强制使用HTTP/1.1，参数为--http1.1
所以最后的命令是：

curl "https://console.aws.example/api/xxx" -b "SESSION=$SESSION" --http1.1

AWS的Application Load Balancer（ALB）也有这个问题。问题是我将Apache配置为使用http 2，但在ALB后面。ALB默认支持http 2：
应用程序负载均衡器通过HTTPS侦听器提供对HTTP/2的本机支持。您可以使用一个HTTP/2连接并行发送多达128个请求。负载均衡器将这些请求转换为单个HTTP/1.1请求，并将它们分发到目标组中的健康目标中。因为HTTP/2更有效地使用前端连接，所以您可能会注意到客户端和负载均衡器之间的连接更少。您不能使用HTTP/2的服务器推送功能。1
因此，curl使用HTTP/2与ALB连接，然后ALB将其转换为HTTP/1请求。Apache在请求客户端Upgrade到HTTP/2的响应中添加了头，ALB刚刚将其传递回客户端，curl将其读取为无效，因为它已经使用了HTTP/2连接。我通过在Apache示例上禁用HTTP/2解决了这个问题。因为它总是在ALB后面，而ALB永远不会使用HTTP/2，所以没有必要拥有它。

修复或删除HTTP请求中的Content-Length标头。
我尝试连接到AWS网关时发生了此问题。我能够使用POSTMAN得到正确的响应，但如果我将相同的头复制到curl，它会给予我这个错误。
最终对我起作用的是删除Content-Length头，因为curl中的请求长度与POSTMAN中的不匹配。
因为在我的情况下，我只是在测试API，所以这很好，但我不建议在生产中删除这个头。如果在代码库中发生这种情况，请检查以确保长度计算正确。

使用Nginx，您可以通过让两个http 2虚拟主机侦听同一个服务器名称来在curl中遇到此错误。在nginx配置文件上运行一个检查会抛出一个警告，让你知道有些地方不对劲。修复/删除重复的列表可以解决此问题。

# nginx -t
nginx: [warn] conflicting server name "example.com" on 0.0.0.0:443, ignored
nginx: [warn] conflicting server name "example.com" on [::]:443, ignored

我这边的问题是在响应头"Upgrade"=h2,h2c中。例如，curl -v的扩展响应：

* http2 error: Invalid HTTP header field was received: frame type: 1, stream: 1, name: [upgrade], value: [h2,h2c]
* HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)
* stopped the pause stream!

我将这个头文件设置为空Upgrade: ""，http 2上的curl开始正常工作。