HTTP/2 POST请求启用gzip压缩触发ERR_HTTP2_PROTOCOL_ERROR 200排查

我的应用中，仅使用 HTTP/2 且开启 Gzip 压缩的 POST 请求会失败，其他请求（如 GET、关闭压缩的 POST）均正常运行。报错信息为模糊的 ERR_HTTP2_PROTOCOL_ERROR 200 (OK)，curl 执行请求时添加 --compressed 参数会触发 HTTP/2 stream 1 was reset 错误。关闭自身服务侧的压缩后请求恢复正常，但无法操作前端的 Nginx 服务器，希望明确问题原因及调试修复方法。

失败请求示例（curl 命令） #

'https://some.domain/api/route1/route2' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'accept-language: en-GB,en-US;q=0.9,en;q=0.8' \
  -H 'cache-control: no-cache' \
  -H 'content-type: application/json' \
  -H 'cookie: some cookies' \
  -H 'language: en' \
  -H 'origin: https://some.domain' \
  -H 'pragma: no-cache' \
  -H 'referer: https://some.domain' \
  -H 'sec-ch-ua: "Google Chrome";v="123", "Not:A-Brand";v="8", "Chromium";v="123"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "macOS"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: same-origin' \
  -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36' \
  -H 'x-domain: some.domain' \
  --data-raw '{"ids":"319743"}'

响应头 #

Content-Encoding: gzip
Content-Type: application/json; charset=utf-8
Date: Wed, 27 Mar 2024 07:29:26 GMT
Expect-Ct: max-age=0
Server: nginx/1.20.1
Strict-Transport-Security: max-age=15552000; includeSubDomains
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Strict-Transport-Security: max-age=31536000; includeSubdomains;
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Dns-Prefetch-Control: off
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
X-Xss-Protection: 0

curl 添加 --compressed 参数的错误输出 #

* We are completely uploaded and fine
< HTTP/2 200 
< server: nginx/1.20.1
< date: Wed, 27 Mar 2024 07:30:56 GMT
< content-type: application/json; charset=utf-8
< x-dns-prefetch-control: off
< expect-ct: max-age=0
< strict-transport-security: max-age=15552000; includeSubDomains
< x-download-options: noopen
< x-content-type-options: nosniff
< x-permitted-cross-domain-policies: none
< x-xss-protection: 0
< vary: Accept-Encoding
< content-encoding: gzip
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< strict-transport-security: max-age=31536000; includeSubdomains;
< 
* HTTP/2 stream 1 was reset

调试步骤 #

• 抓包分析 HTTP/2 流细节：用 Wireshark 或 tcpdump 捕获请求包，重点查看 HTTP/2 的 DATA 帧是否存在格式错误、长度不匹配或压缩内容损坏。HTTP/2 对帧的校验比 HTTP/1.1 严格，任何不符合规范的帧都会触发流重置。
• 验证压缩内容完整性：若有权限关闭 Nginx 压缩，获取原始响应后手动用 gzip 压缩，对比与 Nginx 返回的压缩包是否一致。若不一致，说明压缩过程中出现数据损坏。
• 检查 Nginx 配置兼容性：确认 Nginx 的 http2 模块与 gzip 模块是否兼容，尤其是 Nginx 1.20.1 这类旧版本，可能存在 HTTP/2 下 gzip 压缩的帧处理 Bug。同时排查是否存在双重压缩（后端服务已压缩，Nginx 再次压缩）。
• 多客户端测试：用不同浏览器、curl 版本测试，确认是否仅特定客户端触发问题；同时测试 GET 请求开启压缩是否正常，缩小问题范围。

修复与解决方案 #

1. 避免双重压缩（核心修复） #

问题大概率是后端服务（BFF节点）与 Nginx 同时开启了 gzip 压缩，导致响应内容被两次压缩。HTTP/2 对内容长度的校验严格，双重压缩会让实际内容长度与响应头声明的长度不匹配，触发流重置。

• 确保仅一层开启压缩：要么后端服务关闭压缩，由 Nginx 统一处理；要么 Nginx 关闭该路由的压缩，由后端负责。若无法操作 Nginx，强制后端关闭对应路由的压缩即可（如你已验证的方案）。

2. 调整 Nginx 压缩配置（若有权限） #

针对 Nginx 1.20.1 版本，优化 HTTP/2 下的压缩配置：

http {
  http2 on;
  
  gzip on;
  gzip_types application/json text/plain;
  # 禁止对已压缩的内容再次压缩
  gzip_disable "msie6";
  gzip_vary on;
  # 确保 HTTP/2 下的压缩帧符合规范
  gzip_http_version 1.1;
}

3. 临时路由级规避 #

若无法修改 Nginx 配置，可在后端服务中针对该 POST 路由，返回时移除 Accept-Encoding 响应头，或强制返回未压缩内容，避免 Nginx 触发压缩。

问题根源解释 #

HTTP/2 采用二进制帧传输，每个帧都有严格的长度和格式校验。当响应被双重压缩后，实际内容长度远大于响应头中 Content-Length 声明的值（或 HTTP/2 帧的长度字段），客户端/服务器检测到帧格式错误后会直接重置流，返回模糊的 ERR_HTTP2_PROTOCOL_ERROR 错误。而 HTTP/1.1 对这类错误的容忍度更高，可能不会直接报错，这也是其他请求正常的原因。

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