最稳妥方式是sub_filter修改响应体+Content-Security-Policy升级协议；因重定向无法干预已加载页面中第三方域名的HTTP子资源请求，而sub_filter可精准替换src/href等属性中的http://为https://，配合CSP头实现双重防护。
直接在 Nginx 入口层修复混合内容，最稳妥的方式不是靠重定向（return 301 或 rewrite），而是用 sub_filter 修改响应体 + Content-Security-Policy 升级请求协议。因为浏览器拦截的是页面加载后发起的子资源 HTTP 请求，而这些请求的 URL 来自 HTML 文本本身——它不在 Nginx 的重定向作用范围内。
为什么不能靠重定向修复静态资源引用
重定向只对客户端主动发起的请求生效，比如用户输入 http://example.com，Nginx 可以 301 跳转到 HTTPS 主页。但当 HTTPS 页面已加载完成，其内部的 <img src="http://cdn.example.com/logo.png" alt="详解 Nginx 处理“混合内容”警告：通过重定向修复 HTTP 静态资源引用" > 会由浏览器直接发出新请求，此时该请求的 Host 是 cdn.example.com，根本不会经过你主站的 Nginx 配置。也就是说：
- 主站 Nginx 的
server { listen 443; }块无法干预第三方域名的 HTTP 请求 -
rewrite ^/.* http://$host$request_uri? permanent;这类规则对跨域资源无效 - 试图用
proxy_pass http://cdn.example.com再加 rewrite，会引入额外代理开销且难以维护
真正有效的两层修复策略
混合内容的本质是“HTTPS 页面里写了 HTTP 地址”，解决思路必须覆盖两个层面：让页面里写的地址变安全（响应体替换），同时兜底让浏览器自动升级（响应头指令）。
-
sub_filter 替换 HTML 中的硬编码 HTTP 链接：匹配
src="http://、href="http://、upgrade-insecure-requests"：这是浏览器原生支持的协议升级机制，只要响应头中存在该指令，浏览器会在发起任何子资源请求前，自动把 <code>http://替换为https://，无需修改页面源码
关键配置示例（可直接复用）
以下配置放在你的 HTTPS server 块内，适用于反向代理或静态文件服务场景：
location / {
# 关键：禁用压缩，否则 sub_filter 无法处理
proxy_set_header Accept-Encoding "";
gzip off;
<pre class="brush:php;toolbar:false;"># 启用 sub_filter 并精准匹配
sub_filter 'src="http://' 'src="https://';
sub_filter 'href="http://' 'href="https://';
sub_filter 'https://';
sub_filter_once off;
sub_filter_types text/html application/xhtml+xml;
# 清除可能干扰的缓存头
etag off;
add_header Cache-Control "no-cache";
# 兜底：强制浏览器升级所有不安全请求
add_header Content-Security-Policy "upgrade-insecure-requests; default-src 'self';";
# 若后端返回 Location 头含 HTTP，也一并修正
proxy_redirect http:// https://;}
哪些情况 sub_filter 会失效？如何补救
sub_filter 是纯文本替换，有天然局限。遇到以下情况需额外处理：
- 内联 JavaScript 中动态拼接的 URL（如
document.createElement('img').src = 'http://' + host）→ 无法替换，必须前端修复 - JSON 数据或注释里的
http://→ 易误替，建议用带引号的属性模式，避免全局替换http:// - 第三方 CDN 不支持 HTTPS → 即使替换成功也会 404，需联系对方启用 SSL 或更换源
- 页面含大量 SVG 内联代码或 Base64 图片 → 检查是否意外触发替换，必要时用
sub_filter_last_modified on控制作用范围
