全站HTTPS升级需统一缓存入口：强制301重定向至标准HTTPS域名（如example.com），禁用$host防攻击；响应头设upgrade-insecure-requests与immutable缓存策略；清理旧HTTP/WWW缓存并刷新代理及浏览器缓存。
全站从 HTTP 升级 HTTPS 后，浏览器缓存若仍按旧协议（http://）或混合域名（如 www 与非 www）分别缓存，会导致同一资源被重复存储、更新不同步、甚至触发混合内容警告。规范唯一缓存入口的核心是：**让所有客户端请求都归一到同一个协议+域名组合，并通过响应头明确控制缓存行为**。
强制统一访问入口，避免协议/域名分叉
在 HTTP server 块中，用 return 301 将所有请求重定向至标准 HTTPS 地址，且固定主域名（如强制 example.com，不带 www 或反之）：
- 使用
$request_uri保证参数完整保留，不丢?a=1&b=2 - 避免用
$host拼接，防止攻击者伪造 Host 头导致跳转到非法域名；改用配置中写死的可信域名，如https://example.com$request_uri - 多域名场景下，先白名单校验再跳转：
if ($host ~* ^(www\.example\.com|example\.com)$) { return 301 https://example.com$request_uri; }
不匹配的 Host 直接return 403
响应头统一声明缓存策略与协议升级
在 HTTPS server 块中，对静态资源（JS/CSS/图片等）主动下发标准化缓存指令，并启用协议自动升级：
- 用
add_header Content-Security-Policy "upgrade-insecure-requests"，让浏览器自动把页面内所有http://资源请求改为https:// - 配合
expires 1y或add_header Cache-Control "public, immutable, max-age=31536000"，确保资源长期缓存且不会因协议差异产生多个副本 - 若资源使用内容哈希命名（如
app.a1b2c3.js），可放心设为immutable，避免浏览器重复验证
清理历史缓存歧义，防止旧入口残留
升级初期，用户本地可能已缓存大量 http:// 或 www.example.com 下的资源。需主动干预：
- 上线后要求运维或发布系统触发一次全局缓存刷新（如通过
ngx_cache_purge模块清除代理层旧缓存） - 前端 HTML 中添加
<meta http-equiv="Cache-Control" content="no-cache">（仅首屏 HTML），强制重新拉取最新版本，避免旧 HTML 继续引用http://资源 - 提醒用户清除浏览器缓存，或在测试阶段用
curl -I验证响应头是否已统一为https://example.com/xxx和正确Cache-Control
不复杂但容易忽略
