CDN-非预期 302 问题，cdn-预期302问题


浅谈

访问 CDN 出现 302 的情况一般有几种可能；

  • CDN 有 302 的特殊配置，根据客户端请求的 URL，或者 http 强制跳转到 https；
  • CDN 透传回源后，源站给出的 302；
  • 客户端请求到 CDN 过程中被劫持，或者 CDN 回源站被劫持；

案例分析

案例：

客户请求到 CDN 出现 302，视频内容可以访问，但是经常出现方式失败，或者内容不对的情况。

image

分析：

  • 先固定 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 是 HIT
Via: 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 回源即可解决。

相关内容