Azure CDN返回ERR_HTTP2_PROTOCOL_ERROR错误的原因及修复方法

已知前提 #

• 刚启用Azure CDN服务，仅部分用户反馈访问异常
• 源站可正常返回请求的CSS文件
• 已收集到单用户的问题截图，暂未获取更多通用故障细节
• 源站返回的响应头如下：

Accept-Ranges: bytes
Access-Control-Allow-Origin: https://www.google.com
Cache-Control: max-age=31536000
Content-Encoding: gzip
Content-Length: 1956119
Content-Type: text/css
Date: Tue, 16 Feb 2021 18:44:10 GMT
ETag: "011889dd7ffd61:0"
Expect-CT: max-age=604800, enforce,
Feature-Policy: autoplay 'none'; camera 'none'
Last-Modified: Wed, 10 Feb 2021 18:07:38 GMT
strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block

可能触发原因 #

结合源站响应头特征，大概率是以下几类问题：

• 压缩配置冲突：Azure CDN节点默认的压缩规则与源站自带的Content-Encoding: gzip响应不兼容，常见为节点同时开启了「源站压缩直通」+「动态压缩」，导致文件被二次压缩、或损坏成无法解析的格式。
• Vary头缓存规则未生效：源站明确返回Vary: Accept-Encoding，但Azure CDN未正确识别该头，出现两类错配：
  • 将gzip压缩的版本返回给不支持gzip的老旧客户端
  • 将未压缩的版本缓存给支持gzip的客户端，导致解析异常
• ETag校验不兼容：源站使用的是IIS格式的带冒号ETag，Azure CDN部分节点会对ETag做格式改写，导致缓存命中校验出错，返回截断的不完整文件。
• Content-Type改写异常：源站返回Content-Type: text/css且带X-Content-Type-Options: nosniff，若Azure CDN节点在缓存时篡改了Content-Type值，浏览器会直接拒绝按CSS解析该资源，触发样式异常。
• 大文件分片缓存缺陷：该CSS文件压缩后大小约1.9MB，超出部分Azure CDN旧边缘节点的默认分片缓存阈值，导致缓存内容不完整。
• 跨域配置不匹配：源站Access-Control-Allow-Origin仅允许https://www.google.com，若用户实际站点域名不在白名单内，CDN未透传或修改CORS头时，会触发浏览器跨域拦截。

对应修复方案 #

• 调整Azure CDN的压缩配置：
  • 若选择源站负责压缩，关闭CDN侧的「动态压缩」开关，仅开启「源站压缩直通」
  • 若选择CDN负责压缩，关闭源站的gzip压缩，由CDN统一处理压缩逻辑
• 强制CDN识别Vary头：在Azure CDN的规则引擎中添加自定义规则，强制将源站返回的Vary: Accept-Encoding透传给用户，同时禁止节点改写该头
• 调整ETag规则：在规则引擎中配置「忽略源站ETag」，由Azure CDN根据缓存内容自动生成统一格式的ETag，避免兼容问题
• 校验响应头透传规则：确认CDN的规则引擎未配置改写Content-Type、X-Content-Type-Options的规则，强制透传源站返回的对应值
• 临时豁免大文件缓存阈值：在规则引擎中针对该CSS路径，调高分片缓存的大小上限，或直接配置该路径不缓存，等待节点版本升级
• 修正CORS白名单：将实际需要加载该资源的用户站点域名加入源站的Access-Control-Allow-Origin白名单，同时配置CDN透传CORS头

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