Nginx sub_filter 可在代理层精准替换 HTTPS 页面中第三方 HTTP 链接，需关闭压缩、扩展 sub_filter_types、启用多次替换，并锚定上下文如 src="http:// 替换为 src="https://，配合 proxy_redirect、CSP 头等实现全链路安全升级。
用 Nginx 的 sub_filter 在代理层自动修正 HTTPS 页面里的第三方 HTTP 资源链接，核心是“精准替换 + 全链路配合”。它不能解析 HTML，但能高效处理文本响应中的硬编码地址，适合零改动后端的紧急修复场景。
确保 sub_filter 能真正起作用
很多配置看似正确却无效，往往卡在这三步：
- 必须关闭响应压缩：在
location块中加gzip off;或proxy_set_header Accept-Encoding "";。压缩后的响应是二进制流，sub_filter完全无法识别； - 显式声明可处理类型：默认只处理
text/html，但脚本、样式、JSON 配置里也可能含 HTTP 链接，需补上sub_filter_types text/html text/javascript application/json text/css;； - 允许多次替换：加
sub_filter_once off;，否则一个页面里只改第一个http://，其余全部失效。
安全替换第三方资源链接
别直接全局搜 http:// —— 容易误改 JSON 字段值、JS 注释或 URL 参数。推荐锚定上下文：
sub_filter 'src="http://' 'src="https://';sub_filter "src='http://" "src='https://";sub_filter 'href="http://' 'href="https://';- 若第三方域名明确（如
cdn.example.com），优先写成sub_filter 'src="http://cdn.example.com/' 'src="https://cdn.example.com/';，更可控； - 对 CSS 中的
url(http://...)，确保sub_filter_types包含text/css，并匹配完整结构，例如sub_filter 'url(http://' 'url(https://';。
补全其他混合内容来源
sub_filter 只动响应体，头信息和动态请求还得靠配套措施：
- 用
proxy_redirect http:// https://;修正后端返回的Location或Refresh头； - 加
add_header Content-Security-Policy "upgrade-insecure-requests";，让浏览器自动把页面内所有http://请求升为https://，覆盖 JS 动态拼接等sub_filter无法触达的情况； - 若第三方资源通过
Referer校验，可加proxy_set_header Referer "";避免被拒； - 对内联 JS 中的字符串或 base64 数据，
sub_filter无能为力，此时 CSP 头就是关键兜底。
验证是否生效
别只看页面显示，要查原始响应：
- 用
curl -H "Accept-Encoding: identity" -s http://your-proxy/ | grep -o 'src="http://'确认是否还有残留； - 用
curl -I http://your-proxy/检查Content-Encoding是否为identity（不是gzip）； - 打开浏览器开发者工具 → Network → 找 HTML 请求 → 查看 Response 标签页，确认链接已变成
https://； - 注意缓存干扰：测试时加随机参数（如
?t=123）或禁用浏览器缓存。
