Nginx sub_filter可在网关层将HTTP资源链接升级为HTTPS以修复混合内容，需禁用压缩、显式启用、限定MIME类型、关闭单次替换，并通过属性上下文精准替换，配合proxy_redirect、CSP头等实现完整防护。
用 Nginx 的 sub_filter 在网关层修复混合内容，核心是把 HTML 响应里硬编码的 http:// 资源链接升级为 https://，让浏览器不再报“不安全内容”警告。它不改后端、不碰代码，只在响应流出前做一次轻量文本替换，适合快速兜底。
确保替换能真正生效
sub_filter 不是开箱即用的功能，必须满足几个前提条件：
- 响应不能被压缩：后端若返回
Content-Encoding: gzip，sub_filter 就读不到明文 HTML。在 location 块中加proxy_set_header Accept-Encoding "";，或配gunzip on;主动解压 - 必须显式启用替换：Nginx 默认不开启，需写
sub_filter 'http://' 'https://';这类规则 - 要处理 HTML 类型：默认只认
text/html，若页面含内联 JSON 或 JS 字符串，可追加sub_filter_types text/html application/json application/javascript; - 允许多次替换：设
sub_filter_once off;，否则只改第一个http://，漏掉大量资源
提高替换准确性和安全性
纯字符串替换容易误伤，比如把 https:// 里的 http:// 也替了，或改到注释、JS 变量里。推荐这样控制范围：
- 限定属性上下文：用
sub_filter 'src="http://' 'src="https://';，比宽泛替换更稳妥 - 补充常见属性：再加一条
sub_filter 'href="http://' 'href="https://';，覆盖 CSS、跳转链接 - 避开敏感区域：如果页面有内联脚本含
http://字符串（非真实 URL），可单独用location ~ \.html$ { ... }限定作用范围，或临时关闭该 location 的 sub_filter - 测试是否生效：用
curl -sI https://yoursite.com | grep Content-Encoding确认没压缩；再curl -s https://yoursite.com | grep 'src="http'检查是否还有残留
配合其他机制形成完整防护
sub_filter 只修响应体，而混合内容还可能来自响应头、重定向或浏览器策略，需要协同处理：
- 修正 Location 头：加
proxy_redirect http:// https://;，防止 302 跳转回 HTTP - 兜底升级策略：加
add_header Content-Security-Policy "upgrade-insecure-requests";，让浏览器自动把所有不安全请求升为 HTTPS - 清理 Referer：某些第三方图床会因 HTTP Referer 拒绝加载，可用
proxy_set_header Referer "";或proxy_hide_header Referer; - 避免缓存污染：替换后的 HTML 若被 CDN 缓存，可能把
https://错误缓存成固定值。建议加add_header Cache-Control "no-store, no-cache";或按需设置缓存键
不推荐但偶尔要用的进阶技巧
遇到特殊场景时，可以稍作变通，但需清楚代价：
- 替换带端口的地址：如
sub_filter 'http://example.com:8080' 'https://example.com';，注意端口号要完全匹配 - 映射 CDN 域名：把
http://static.old.com换成https://cdn.new.com，适合静态资源迁移 - 使用正则（Nginx ≥1.9.4）：写成
sub_filter /http:\/\/[^"'\s>]+/ '$scheme://$host$1';，但正则性能略低，且不支持捕获组反向引用，实际仍建议用字面量+多条规则 - 变量仅用于右侧：$scheme、$host 可出现在替换值里，但不能用于匹配模式（左侧必须是静态字符串）
