Nginx 不提供一键替换 HTTP 链接功能，所谓“平滑升级”实为三重配合：① 通过 return 301 https://$host$request_uri 强制 HTTP→HTTPS 重定向；② 利用 sub_filter 替换响应 HTML 中的 http:// 为 https:// 防混合内容；③ 启用 HSTS 头 Strict-Transport-Security 实现浏览器自动 HTTPS 访问。
Nginx 本身不提供“一键平滑升级 HTTP 链接”的功能——它不能自动把旧系统里写死的 http:// 地址批量替换成 https://。所谓“将不安全 HTTP 链接平滑升级”，实际是指：让访问者通过 HTTP 发起的请求，被 Nginx 自动、无感地重定向到 HTTPS，同时确保原有服务不中断、页面资源不报混合内容（Mixed Content）错误。
这属于「强制 HTTPS」和「前端资源协议升级」两个层面的配合，不是单靠 Nginx 配置就能“一键”完成旧系统所有链接改造的魔法操作，但可以通过以下方式高效、平滑落地：
✅ 强制全站 HTTPS（服务端重定向）
在 Nginx 的 server 块中配置 301 重定向，把所有 HTTP 请求转到 HTTPS：
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}⚠️ 注意：
- 必须已部署有效 SSL 证书（如 Let's Encrypt），否则 HTTPS 会失败；
-
$request_uri保留原始路径和参数，保证跳转精准； - 此重定向对用户透明，浏览器地址栏自动更新，搜索引擎也会逐步替换索引链接。
✅ 防止混合内容（前端资源自动升级）
即使服务端强制了 HTTPS，如果旧网页 HTML 中写死了 http://xxx.js 或 <img src="http://...">，浏览器仍会拦截这些不安全资源，导致页面白屏或功能异常。
Nginx 可通过 sub_filter 模块做响应体替换（需编译时启用 --with-http_sub_module）：
location / {
proxy_pass https://backend;
proxy_set_header Host $host;
# 将响应 HTML 中的 http:// 替换为 https://（仅限文本型响应）
sub_filter 'http://' 'https://';
sub_filter_once off;
sub_filter_types text/html text/css application/javascript;
}? 说明：
- 这个替换只作用于 Nginx 代理返回的响应体（如后端吐出的 HTML），不修改源码；
- 不适用于二进制资源（图片、字体等），它们必须本身支持 HTTPS 访问；
- 替换是字符串级的，慎用于含
http://的 JSON 或注释中，可能误伤。
✅ 推荐搭配：HTTP Strict Transport Security（HSTS）
告诉浏览器“未来一段时间内，只允许用 HTTPS 访问本域名”，避免首次 HTTP 请求：
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
✅ 效果：
- 用户第一次访问
http://后跳转https://，之后只要在 max-age 期内再访问example.com，浏览器会自动改用 HTTPS，连 301 都省了； -
includeSubDomains覆盖所有子域名； -
preload可提交至浏览器 HSTS Preload List，实现首次访问即 HTTPS（需额外申请）。
❌ 不推荐的做法
- 用
rewrite ^(.*)$ https://$host$1 permanent;：功能等价但不如return 301高效（return更快、更安全）； - 在 Nginx 里尝试替换 JS/CSS 内部的
http://字符串：不可靠，易破坏代码逻辑； - 仅配 HTTPS 而不关 HTTP 端口：旧链接仍可访问，无法推动升级。
本质上，“平滑升级 HTTP 链接”是 服务端重定向 + 前端资源协议治理 + 浏览器策略加固 三者的组合。Nginx 承担的是最外层的流量调度和基础防护角色，真正彻底解决，还需推动业务方逐步清理硬编码 HTTP 地址。
