hsts 不能自动清除旧 http 链接，真正清除需三步协同：服务端 301 跳转、响应内容动态替换（如 sub_filter）、启用 hsts 响应头固化浏览器行为。
Nginx 中开启 HSTS 后，并不能“自动清除”旧的 HTTP 链接——HSTS 只是告诉浏览器：今后一段时间内，强制用 HTTPS 访问该域名，它不修改网页源码、不重写响应内容、也不删除已存在的 http:// 硬编码链接。所谓“彻底清除不安全旧链接”，实际是三步协同落地：服务端跳转 + 响应内容修正 + 浏览器策略固化。
注意：HSTS 本身不是重定向指令，也不能替代 301；它是响应头，作用对象是浏览器，不是服务器或爬虫。
强制 HTTP → HTTPS 重定向（用户和爬虫第一道防线）
这是最基础、最关键的一步。所有 HTTP 请求必须无条件跳转到对应 HTTPS 地址：
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
-
$host保持原始域名（避免跨域风险），$request_uri完整保留路径和参数 - 此配置确保搜索引擎逐步替换索引中的 HTTP 链接，用户输入
http://也会被立即跳转
替换 HTML 中残留的 http:// 资源链接（防混合内容）
即使全站跳了 HTTPS，如果页面里还写着 <script src="http://cdn.example.com/js.js"></script>，浏览器会拦截这些资源，导致白屏或功能异常。Nginx 可用 sub_filter 动态替换：
location / {
proxy_pass https://backend;
sub_filter 'http://example.com/' 'https://example.com/';
sub_filter 'http://cdn.example.com/' 'https://cdn.example.com/';
sub_filter_once off;
sub_filter_types text/html application/xhtml+xml;
}
-
sub_filter_once off：替换全部匹配项，不止第一个 - 必须搭配
proxy_pass使用（即 Nginx 作反向代理时才生效） - 不适用于静态文件直出（如
root /var/www/html），这类需手动修复源码或构建流程
启用 HSTS 头（固化浏览器行为，防止协议降级）
在 HTTPS 的 server 块中添加响应头：
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
-
max-age=31536000表示一年内浏览器自动把所有对该域名的 HTTP 请求升级为 HTTPS -
includeSubDomains扩展到所有子域名（如 api.example.com） -
preload是可选，用于提交至浏览器 HSTS 预加载列表（需满足更严要求） -
always确保 301/4xx/5xx 响应也携带该头（避免仅 200 返回）
⚠️ 重要提醒：HSTS 一旦启用且 max-age 较大，无法临时回退 HTTP。调试阶段建议先设 max-age=300（5分钟），验证无误后再调高。
清除已缓存的不安全访问行为（终端用户侧补救）
HSTS 和 301 都会被浏览器强缓存，若旧链接曾被访问过，可能长期跳转失败或跳错：
- Chrome/Edge：访问
chrome://net-internals/#hsts→ 输入旧域名 → Delete - Firefox：访问
about:config→ 搜索network.http.strict-transport-security.enabled→ 设为false临时禁用 - 终极验证方式：用
curl -I http://example.com查看是否返回301+Location: https://...，绕过浏览器干扰
基本上就这些。HSTS 是加固手段，不是清理工具；真正“清除不安全链接”的动作，靠的是重定向兜底、响应内容修正、以及前端源码持续治理。
