一次 CDN 厂商切换引发的血案：从华为云到火山引擎的 gzip 填坑实录

标签：CDN · 运维排障
日期：2026-08-12
阅读时长：约 10 分钟
声明：本文所有域名、IP、路径均已脱敏，仅为排查过程演示。

一、问题现象：切完 CDN 后资源下载全线失败

某游戏资源 CDN 域名（下称 cdn-game.example.com）从华为云切到火山引擎后，Android 客户端在下载热更资源时大量失败，日志中反复出现如下错误：

[09:01:57] [Log] Download failed:
  https://cdn-game.example.com/<资源URL_已脱敏>
  -> /storage/emulated/0/Android/data/com.example.game/files/data/48/48c71e13.dat,
  Unrecognized content-encoding

[09:01:58] [Log] Retry failed: ... Retry: 3
[09:02:05] [Log] Retry failed: ... Retry: 3
[09:02:07] [Log] Retry failed: ... Retry: 3

关键信息：所有失败的文件都是 .dat 后缀的资源文件（Spine 动画、沙盘地形 LOD 等），重试 3 次后放弃。而切回华为云 CDN 一切正常。同样的源站、同样的文件，只是 CDN 厂商变了，行为就不同了。

🎯 错误关键词：Unrecognized content-encoding

这个错误来自 Unity 的 UnityWebRequest 下载处理器（DownloadHandler）。当 HTTP 响应头中包含 Content-Encoding 但值不是 Unity 能处理的格式（如 gzip），或者 body 实际编码与 header 声明不一致时，就会抛出此错误。这说明 CDN 返回给客户端的响应中，带了 Content-Encoding: gzip 头。

二、排查过程：从 DNS 到 curl 实测

2.1 DNS 链路分析

该域名同时配置了三家 CDN，分别覆盖海外、国内旧线路、国内新线路。首先确认各家的 CNAME 链路，确保测试时能分别打到对应的 CDN 节点：

2.2 curl 实测：用 Accept-Encoding: gzip 复现问题

Unity 的 UnityWebRequest 默认会携带 Accept-Encoding: gzip 请求头。我用 curl 模拟这个行为，通过 --resolve 分别将请求指向三家 CDN 的节点 IP（下文 IP 均为脱敏后的文档示例 IP），对比响应头差异：

# 携带 Accept-Encoding: gzip，分别请求三家 CDN
curl -sS -k -D - -o /dev/null \
  -H "Accept-Encoding: gzip" \
  --resolve "cdn-game.example.com:443:<CDN_IP>" \
  "https://cdn-game.example.com/<资源URL_已脱敏>"

测试结果（同一个文件，同一个源站，唯一变量是 CDN 厂商）：

Akamai CDN — 正常 ✅

HTTP/1.1 200 OK
Server: nginx
Content-Type: application/octet-stream
Content-Length: 310617
ETag: "66a31e2f-4bd59"
# 无 Content-Encoding 头
# Co