Nginx sub_filter可代理层自动将http://替换为https://以解决混合内容警告，需同时禁用压缩、显式声明MIME类型、关闭单次替换，并注意模块启用、location覆盖、状态码限制及生效验证。

用 Nginx 的 sub_filter 在代理层把页面里硬写的 http:// 链接自动改成 https://，是解决混合内容警告最直接的方式。它不改后端代码，也不动前端资源，只在响应发出前做一次轻量文本替换。

核心配置三要素

要让替换真正生效，必须同时满足以下三点：

• 禁用响应压缩：后端若返回 gzip 内容，sub_filter 就读不到明文。加这行：proxy_set_header Accept-Encoding "";
• 显式声明 MIME 类型：默认只处理 text/html，但 CSS、JS、JSON 里的链接也常出问题。建议写：sub_filter_types text/html text/css application/javascript application/json;
• 开启全文替换：默认只换第一个匹配项。加 sub_filter_once off; 才能修复所有 http://

典型 HTTPS 修正写法

常见硬编码形式包括协议头、完整 URL、相对路径拼接等，对应替换策略如下：

• 统一协议升级：sub_filter 'http://' 'https://';（注意末尾斜杠，避免误替 http://example.com 中的 http）
• 修复跳转地址（如 meta refresh 或 JS location）：sub_filter "http://$host" "https://$host";（用变量更安全，避免影响其他域名）
• 补全协议缺失的资源：sub_filter 'src="/js/' 'src="https://$host/js/';（需配合引号和路径边界，防止误替）

容易忽略的关键细节

很多配置看似正确却失效，往往卡在这几个环节：

• 模块是否启用：运行 nginx -V 2>&1 | grep -o with-http_sub_module，无输出说明未编译该模块
• location 范围是否覆盖：sub_filter 只在当前 location 块内有效。若静态资源走独立路径（如 /static/），需单独配或用通配 location / { ... }
• 响应状态码限制：默认只处理 200、201、204、206、301、302、303、304、307、401、403、404、405、410、411、413、414、415、494、495、496、497、499、500、501、502、503、504、505 等状态码。若后端返回非标准码（如 299），需用 sub_filter_last_modified on; 或调整逻辑

验证是否生效的方法

别只看页面是否显示正常，要确认替换真的发生了：

• 用 curl -s https://yourdomain.com/page.html | grep http:// 检查原始响应里是否还有 http://
• 浏览器打开开发者工具 → Network → 点开 HTML 请求 → 查看 Response 标签页，搜索关键词
• 临时加一行 sub_filter 'body>' 'body><!-- sub_filter active -->';，刷新后源码中出现注释即表示模块工作正常