浅谈
访问 CDN 出现 302 的情况一般有几种可能；
- CDN 有 302 的特殊配置，根据客户端请求的 URL，或者 http 强制跳转到 https；
- CDN 透传回源后，源站给出的 302；
- 客户端请求到 CDN 过程中被劫持，或者 CDN 回源站被劫持；
案例分析
案例：
客户请求到 CDN 出现 302，视频内容可以访问，但是经常出现方式失败，或者内容不对的情况。
分析：
- 先固定 CDN 不通的节点进行测试，用户可以通过 IPIP.net 看下其他地区解析的 CDN IP ，然后固定访问。看是普片的都是 302 还是部分地区。
- 检查自己的 CDN 控制台上是否有特殊的 302 条转配置，比如 http 跳转 https ，或者自己有过特殊的 302 需求。
- 固定原站进行测试看是否有 302 的情况，或者自己原站是否有 302 的配置。
以上步骤都测试过没有发现问题，我们在看下 header 进行分析，通过 header 可以看到，访问 CDN 时已经发原站的域名显示出来，并且 location 的 IP 并不是 CDN 以及原站的 IP，那么基本可以知道是被劫持了。
那么是请求 CDN 被劫持，还是 CDN 回源被劫持了呢？
主要我们分析下请求 CDN 返回的 response 头信息。如果带有以下信息，从右往左成对出现，L1 tengine L1 swift ，L2 tengine L2 swift，如果都是 MISS 的情况下，说明是回源了。如果发现是有 HIT 的情况，说明是访问 CDN 的过程中被劫持了。
M 是 MISS
H 是 HITVia: cache20.l2eu6-1[311,206-0,M], cache1.l2eu6-1[312,0], cache18.cn949[0,206-0,H], cache13.cn949[45,0]
如果 response 信息中没有上面的 via 信息，但是直接看到了原站的 IP 或者域名，说明是在回源过程中被劫持的，本案例看到的 location 已经解析了回源 IP ，说明是在回源被劫持的。
出现这种劫持的情况，用户只要把回源端口改成 443 回源即可解决。
