HTTPS重定向本身不改变CDN缓存行为，但错误配置会干扰缓存命中、引入协议失真、导致缓存污染或跳转循环；关键在于跳转发生层级、原始意图是否透传及响应头是否一致。
HTTPS 重定向本身不改变 CDN 缓存行为，但错误配置会干扰缓存命中、引入协议失真、甚至导致缓存污染或跳转循环——关键不在“是否跳转”，而在“跳转发生在哪一层、是否透传原始意图、响应头是否一致”。
重定向位置决定 CDN 是否感知跳转
CDN 缓存的是它实际收到并返回给用户的响应。如果重定向发生在 CDN 层（如 Cloudflare 的“始终使用 HTTPS”），CDN 会把 301 响应缓存下来，后续请求直接返回跳转，不触达 Nginx；如果重定向由 Nginx 执行（80 端口 return 301），CDN 收到的是 HTTP 请求，再转发给 Nginx，此时跳转逻辑完全暴露在 CDN 路径中。
- 推荐做法：让 CDN 处理协议升级（启用“始终使用 HTTPS”+ Full (Strict) 模式），Nginx 专注业务层重定向（如裸域→www）
- 避免 Nginx 对已走 HTTPS 的请求再做 301 跳转（例如 443 端口内又跳 https://），这会破坏 CDN 缓存键一致性，还可能触发 HSTS 强制刷新问题
- 若必须由 Nginx 控制跳转，请确保
$http_x_forwarded_proto判断准确，并统一硬编码目标域名，防止 CDN 回源时因$server_name解析异常生成非法 URL
跳转响应头影响 CDN 缓存决策
CDN 对 301/302 响应也会缓存，但策略与普通资源不同：多数 CDN 默认缓存 301 较长时间（如 1 小时以上），而 302 通常不缓存或仅缓存数秒。若 Nginx 返回的跳转响应中缺失 Cache-Control，CDN 可能按自身规则缓存，导致跳转逻辑长期生效，难以快速回滚。
- 对永久跳转（301），显式设置
add_header Cache-Control "public, max-age=3600";，既控制 CDN 缓存时长，也避免被浏览器过度缓存 - 对临时跳转（302），建议加
Cache-Control: no-cache, must-revalidate，确保每次请求都重新评估跳转逻辑 - 避免在跳转响应中返回
Set-Cookie或敏感头，CDN 缓存后可能造成信息泄露或状态错乱
HTTPS 重定向与缓存键冲突风险
CDN 缓存键（Cache Key）通常默认包含 Host、URL、QueryString，但不包含协议（HTTP/HTTPS）。当用户通过 HTTP 访问，被 Nginx 301 跳转到 HTTPS 后，CDN 实际缓存的是跳转响应；而同一 URL 的 HTTPS 直连请求则可能命中另一份内容（如静态资源）。这种分离会导致缓存分裂，尤其在混合内容场景下更易触发浏览器警告。
- 解决方案：在 CDN 侧开启“基于协议区分缓存键”（如 Cloudflare 的 Cache Key customization → include protocol），或统一入口只走 HTTPS
- Nginx 配置中避免对同一路径同时支持 HTTP 和 HTTPS 的不同行为（例如 /api 返回不同数据），否则 CDN 无法可靠识别语义一致性
- 静态资源建议直接禁用 HTTP 入口（80 端口只做跳转，不提供任何 content-type 响应），从源头减少缓存歧义
SEO 与缓存协同需同步处理
搜索引擎爬虫会缓存并遵循 301 跳转，但 CDN 若提前缓存了跳转响应，而源站尚未完成权重迁移或 canonical 标签更新，可能导致索引混乱。这不是 Nginx 单独能解决的问题，而是 CDN 缓存、Nginx 响应头、HTML 内容三者需保持一致。
- 在跳转页面 HTML 中补充
<link rel="canonical" href="https://www.example.com/>，强化语义指向 - 配合
Cache-Control: public, max-age=3600，既保障爬虫及时发现变更，又避免 CDN 长期锁定旧跳转 - 上线新跳转规则后，主动在 Search Console 提交 URL 检查，加速索引更新，而非依赖 CDN 自然过期
