仅在已通过 https 加载的页面中生效，作用是自动将站内 http 资源请求升级为 https，不触发跳转、不影响首次 http 访问，也不处理跨域或绝对 url。
upgrade-insecure-requests 这个 meta 标签只能在已通过 HTTPS 加载的页面中起作用，它不负责把 HTTP 页面跳转成 HTTPS，也不影响用户首次输入 http:// 的行为 —— 那是服务器或 CDN 层该干的事。
为什么 <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> 不会帮你跳转协议
这个标签本质是告诉浏览器：“当前页面已经是 HTTPS 了，请把所有站内相对路径、http:// 绝对路径的资源请求（比如图片、脚本、样式表）自动改成 https:// 再发出去。”
- 它只在 HTTPS 页面里生效；HTTP 页面加载时，该标签被忽略
- 它不触发任何重定向，也不会修改地址栏 URL
- 如果某个资源本身不支持 HTTPS（比如第三方图床没配证书），升级后会直接 404 或被拦截，而不是回退到 HTTP
- Chrome 80+ 对音视频类混合内容默认强制升级，但图片等仍可能被静默降级或报错，取决于 CSP 和浏览器策略
真正能“强制 HTTPS 访问”的地方在服务端或边缘节点
用户敲 http://example.com 进来，第一笔请求就是明文的 —— 这个瞬间，前端 HTML 还没开始解析，meta 标签根本没机会执行。必须靠更早一层的机制拦截并重定向：
- Web 服务器（如 Nginx）配置 301 重定向：匹配
http请求，返回Location: https://$host$request_uri - CDN 或边缘安全平台（如 EdgeOne、Cloudflare）开启「强制 HTTPS」开关，底层用 301/302 响应拦截 HTTP 流量
- HSTS 响应头（
Strict-Transport-Security）让浏览器记住“今后只许用 HTTPS”，但它对首次访问无效，且依赖上一次成功 HTTPS 请求才能写入
常见误用场景和坑点
很多开发者加了 upgrade-insecure-requests 就以为全站安全了，结果上线后仍出现混合内容警告、资源加载失败、甚至部分功能白屏 —— 原因往往出在这几个细节：
- 开发环境跑在
http://localhost:3000，但 HTML 里硬写了http://api.example.com接口地址，CSP 标签无法升级跨域请求，只能升级同源或相对路径资源 - 后端模板渲染时拼接了
http://开头的静态资源链接（如<img src="http://cdn.example.com/logo.png?x-oss-process=image/resize,p_40">），这类绝对 URL 不会被upgrade-insecure-requests改写 - 用了
preload或prefetch，但资源 URL 是http://，这些预加载指令在 CSP 升级前就已发出，导致请求被直接阻止 - 测试时只看了 Chrome，但 Safari 对某些混合内容更严格，尤其涉及
fetch()或XMLHttpRequest时，不会自动升级，需手动改 URL 协议
该用什么，取决于你要解决的具体问题
如果你的目标是：
- 防止 HTTPS 页面加载 HTTP 图片/JS/CSS 报错 → 加
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">，放里，确保页面本身是 HTTPS - 让用户无论怎么输入都进 HTTPS → 配置服务器 301 重定向，或开启 CDN 的强制 HTTPS 功能
- 避免用户首次访问被劫持 → 启用 HSTS，并提交到浏览器 preload list（注意：子域名、有效期、
includeSubDomains、preload缺一不可）
meta 标签包打天下；协议升级这件事，从网络层到应用层，每层职责不同，漏掉哪一层都可能出问题。
