Nginx中实现资源预加载应使用add_header Link指令声明rel=preload，路径须为绝对路径、as属性需匹配资源类型，且必须在HTTPS下配置并确保证书有效、无混合内容；http2_push已遭主流浏览器弃用，不可依赖。
在 HTTPS 环境下配置 Nginx 实现资源预加载，核心是通过标准 HTTP 响应头 Link 声明 rel=preload，而不是依赖已淘汰的 http2_push。Nginx 本身不支持 http2_push_preload 这类指令——它根本不存在于任何官方版本中。
用 add_header Link 实现可靠预加载
这是当前最推荐、兼容性最好、语义最清晰的方式。它适用于 HTTP/1.1 和 HTTP/2，且浏览器缓存策略明确，不会造成带宽浪费。
- 在对应 location 块中添加
add_header，路径必须以/开头（绝对路径），as属性需准确匹配资源类型：
location /index.html {
add_header Link '; rel=preload; as=style';
add_header Link '; rel=preload; as=script';
add_header Link '/inter.woff2>; rel=preload; as=font';
}
- 多个资源可链式添加，每条
Link单独一行；单引号必须包裹整个值，注意空格与分号格式 - 确保目标资源本身可通过 HTTPS 直接访问（如
https://example.com/style.css返回 200），否则预加载失败 - 不要在
server或http块顶层加，避免误作用于所有响应（比如 JSON 接口不该 preload CSS）
避免使用 http2_push（已不推荐）
Nginx 的 http2_push 指令虽存在，但现代浏览器已基本弃用：Chrome 自 96 版起完全移除 Server Push 支持，Firefox 也已停用。它存在明显缺陷：
- 无法感知客户端缓存状态，容易重复推送已缓存资源
- 与 HTML 中的
<link rel="preload">竞争，可能干扰浏览器调度 - 仅限 HTTP/2 连接生效，HTTP/1.1 用户完全无感知
- 配置后难以调试，DevTools 中不再显示 “Push” 标识
HTTPS 前提必须稳固
预加载依赖安全上下文，若 HTTPS 配置有漏洞，Link 头可能被忽略或失效：
- 确保 SSL 证书覆盖所有
server_name域名（含www和裸域），且未过期 - 禁用 TLS 1.0/1.1，只启用 TLS 1.2+；推荐 cipher suite 如
ECDHE-ECDSA-AES128-GCM-SHA256 - 确认站点无混合内容（HTTP 资源），否则浏览器会阻止预加载行为
- 若启用了 HSTS，确保
add_header Strict-Transport-Security ... always;在server块顶层，不影响Link头发送
验证是否生效
打开 Chrome DevTools → Network → 刷新页面 → 找到目标资源（如 style.css）：
- 在 Headers 标签页查看
Response Headers，确认存在Link: </style.css>; rel=preload; as=style - 在 Timing 标签页观察其发起时间：理想情况下应早于 HTML 解析完成（initiator 显示为 “Other” 或 “parser”）
- 用命令行快速验证：
curl -I https://example.com/index.html | grep Link
