Nginx不支持http2_push_preload指令，该指令不存在于官方版本中；实际应使用add_header Link实现rel=preload预加载，或谨慎使用已弃用的http2_push指令。
必须先确认 Nginx 版本 ≥ 1.13.9、OpenSSL ≥ 1.0.2，且编译时启用了 http_v2_module，否则 http2_push 和 http2_push_preload 会直接被忽略，配置不报错但完全无效。
检查 HTTP/2 基础是否就绪
很多用户卡在“明明加了 http2_push 却没推送”，根本原因是底层 HTTP/2 还没真正跑起来。先验证三件事：
- 运行
nginx -V 2>&1 | grep -o with-http_v2_module，输出必须是with-http_v2_module（不是空或报错） - 运行
nginx -V 2>&1 | grep -i openssl，确认 OpenSSL 版本 ≥1.0.2；若显示1.0.1e或更低，即使 Nginx 版本够也白搭 - 用浏览器开发者工具的 Network 面板刷新页面，看协议列是否显示
h2；若仍是http/1.1，说明 ALPN 协商失败，http2_push不会触发
启用 Server Push 的两种写法与适用场景
http2_push 是硬编码推送，http2_push_preload 是响应式推送，行为差异很大：
-
http2_push /style.css;：只要匹配该location，无论客户端是否请求过/style.css，每次响应都强制推送。适合首页固定资源（如/logo.svg、/main.js），但滥用会导致带宽浪费 -
http2_push_preload on;：只对响应头中含Link: </style.css>; rel=preload; as=style的请求才推送。需在 HTML 中手动加<link rel="preload" href="/style.css" as="style">，更可控，推荐用于动态页面 - 二者不能混用在同一
location块里，Nginx 会静默忽略后者
容易被忽略的兼容性与性能陷阱
Server Push 不是开箱即用的银弹，几个关键点常被跳过：
- 推送路径必须是绝对路径（以
/开头），比如http2_push /static/css/app.css;；相对路径或带查询参数（/style.css?v=1）会被丢弃 - 若后端是 PHP-FPM 或 proxy_pass 到其他服务，
http2_push只在 Nginx 自己返回静态文件时生效；动态内容需由上游服务生成Link头再配合http2_push_preload - 推送资源若返回 4xx/5xx 状态码，Nginx 仍会推送帧，但浏览器会丢弃，造成无效流量；建议搭配
try_files或前置校验 -
http2_max_concurrent_streams默认是 128，高并发下推送可能被限流；实测电商首页推 5 个资源时，建议设为256或更高
验证推送是否生效的可靠方式
别只信浏览器 Network 面板的 “Initiator” 标注——它有时显示不准。用以下组合判断：
- Chrome DevTools → Network → 右键表头 → 勾选
Protocol和Connection ID；同一Connection ID下出现多个h2请求，且部分Initiator显示Push，才是真推送 - 命令行抓包：
curl -I --http2 -k https://example.com/，观察响应头是否有link: </style.css>; rel=preload; as=style（仅http2_push_preload触发） - 服务端日志加
log_format记录$http2和$request_length，推送成功时$http2为h2，且请求长度明显大于普通请求
最麻烦的点在于：HTTP/2 推送效果高度依赖客户端缓存状态和网络条件。首次访问可能推送成功，第二次因资源已缓存，浏览器会直接复用，不再触发推送——这不是配置失败，而是协议设计使然。
