背景：
用户的服务架构是
Client -> CDN -> OSS
当客户端下载 CDN 内容是如果出现 Content 和用户源站 （OSS） 不一致的情况时可以按照如下步骤进行排查。x-oss-request-id via content-length lastmodify
- 先固定 CDN 节点下载 object 确认出现问题的节点，测试的响应头中我们要保留的几个排障信息。
HTTP/1.1 200 OK
Server: Tengine
Content-Type: application/vnd.android.package-archive
Content-Length: 12763521
Connection: keep-alive
Date: Sun, 18 Nov 2018 07:23:07 GMT
Cache-Control: max-age=3600
Expires: Sun, 18 Nov 2018 08:23:07 GMT
x-oss-request-id: 5BF1135B94D2DCB3BEB5EC9B
Accept-Ranges: bytes
ETag: "53184A3BF5AF6ED719B7EB05EBE72758"
Last-Modified: Wed, 14 Nov 2018 14:01:55 GMT
x-oss-object-type: Normal
x-oss-hash-crc64ecma: 11413790404635767721
x-oss-storage-class: Standard
Content-MD5: UxhKO/WvbtcZt+sF6+cnWA==
x-oss-server-time: 63
Via: cache32.l2cm9[0,304-0,H], cache13.l2cm9[42,0], kunlun2.cn2364[0,200-0,H], kunlun5.cn2364[34,0]
Age: 3210
Ali-Swift-Global-Savetime: 1542225117
X-Cache: HIT TCP_HIT dirn:11:175092793
X-Swift-SaveTime: Sun, 18 Nov 2018 07:29:51 GMT
X-Swift-CacheTime: 3600
Timing-Allow-Origin: *
EagleId: 7250bb1915425289976144403e- 在固定源站 OSS 测试看下 content-length，经过确实原站的 OSS 是正确的，但是为什么 CDN 上存储的是错误的呢？
HTTP/1.1 200 OK
Server: AliyunOSS
Date: Sun, 18 Nov 2018 08:25:58 GMT
Content-Type: application/vnd.android.package-archive
Content-Length: 12766521
Connection: keep-alive
x-oss-request-id: 5BF12216F3150D6E6CB16E7F
Accept-Ranges: bytes
ETag: "53184A3BF5AF6ED719B7EB05EBE72758"
Last-Modified: Wed, 14 Nov 2018 14:01:55 GMT
x-oss-object-type: Normal
x-oss-hash-crc64ecma: 11413790404635767721
x-oss-storage-class: Standard
Content-MD5: UxhKO/WvbtcZt+sF6+cnWA==
x-oss-server-time: 90既然找到了 CDN 上存储的资源是错误，我们还要确认其他节点存储的资源是否一致，可以通过 17测 等测试网络批量测试一下 CDN 存储的 Content-length 是否和原站一致。
- 如果一致，那么问题就是出现在客户端的请求上，比如客户是 206 的请求，range 的范围不是合法的，不在文件的长度范围内。
- 或者客户端使用的是 http 访问出现截图导致文件下载是错误的文件。这种情况客户端可以采用 https 的方式访问 CDN 可以方式被劫持篡改内容的情况
-
如果不一致：
- 首先将测试看下是有多少个节点出现不一致的情况，保留好证据，然后在 CDN 的控制台上调用刷新接口将 CDN 存储的错误文件刷新调。
- 如果是部分节点存储的 content-length 正确，部分不正确，说明客户端再请求 CDN 回源到 OSS 时节点拉取到的是错误文件，所以导致边缘的 CDN 拿到的也是错误，这种情况可以联系阿里云工程师处理 CDN 节点缓存错误内容的问题。