记一次HTTP2不规范Header导致Closed排错

提醒：本文已经超过 352 天未修改，其中某些信息可能已经过时，请谨慎使用！
你似乎正在查看一篇很久远的文章。
为了你这样的访客，我特地保留了我的历史博文。不要笑话过去的我，用温柔的目光看下去吧。

#故障

此次故障遇到了一个典型的 HTTP/2 配置问题，我为了加速自己的静态文件，并同时加速那些位于Jsdelivr上的静态资源，搭建了一个静态资源站点，为了模仿Jsdelivr，假装自己是Jsdelivr镜像，我将Jsdelivr特有的响应头复制到了我的静态资源站，但是因为疏忽忘记删除响应头中的“:”。

当我们在 Nginx 配置中使用 add_header 'x-jsd-version:' ... 时，Nginx 会在头部名称后自动添加分隔冒号，导致实际生成的是非法头部 `x-jsd-version::`。这种双冒号格式直接违反了 HTTP/2 的严格协议规范（RFC 7540）。
在本次故障处理中，发现只有一个使用if语句进行判断响应的目录会出现HTTP/2 Closed错误，而HTTP/1.1不会出问题，这影响了我的判断，导致我以为是if语句造成的异常（不推荐在Nginx中过多使用if语句进行判断，该站点创建于Jsdelivr备案吊销的2021年，那时候我对于Nginx的掌握并不深刻，而这么多年没出问题是因为腾讯云CDN和EO共用部分中间节点，CDN使用HTTP/1.1回源，不会遇到错误，最近遇到江苏山东地区IDC刷流/盗刷CDN 为了满足上下行流量比例而刷它人站点/BT种子资源不得好死。 ，停用了CDN而只使用EO暴露了问题点）
最迷惑的是服务器日志显示"200 OK"并返回等同于文件大小的成功响应，但客户端却报 HTTP/2 stream 0 was not closed cleanly 错误。这是因为服务器确实完成了请求处理，没有遇到异常，但非法头部导致 HTTP/2 协议栈在传输层触发强制中断，客户端收到不完整的数据流无法理解，只能异常关闭连接。

# 经验教训

• 1. HTTP/2 对头部格式有严格要求，双冒号Header会导致HTTP/2协议错误
• 2. if语句等动态逻辑可能改变 Nginx 的头部处理机制
• 3. 测试必须覆盖 HTTP/2 场景，不能只看 HTTP/1.1
• 4. 头部名称必须严格遵循 `[a-zA-Z0-9_-]` 格式
• 5. HTTP Server响应成功不等于协议层正常，不等于客户端成功收到数据

版权声明:转载时请以超链接形式标明文章原始出处和作者信息，来源孤影墨香
本文链接: https://www.gymxbl.com/4486.html
访问时间:2026-06-04 07:22:06