Nginx 当前稳定版不支持原生 HTTP/2 Server Push，因官方已移除 http2_push 指令且实践表明其存在缓存冗余、阻塞关键请求及浏览器弃用等问题；推荐改用 Link 响应头实现 preload 预加载。
HTTP/2 Server Push 在 Nginx 中并非通过 http2_push 指令实现——Nginx 官方从 1.13.9 版本起已移除该指令，且至今未恢复支持。当前稳定版 Nginx（包括 1.24.x、1.25.x）**不支持原生的 Server Push 功能**，所谓“配置 http2_push”属于常见误解，源于早期测试版或第三方补丁的残留信息。
为什么 Nginx 不再支持 http2_push？
Server Push 在实践中暴露多个问题：
- 推送资源难以精准匹配客户端缓存状态（如已缓存 CSS，再推就是冗余）
- 推送阻塞关键请求（如推送大图可能延迟 HTML 解析）
- 浏览器厂商逐步弱化甚至废弃 Push 支持（Chrome 96+、Firefox 97+ 已禁用）
- Nginx 官方认为“应用层更清楚该推什么”，推荐由后端（如 PHP、Node.js）通过
Link响应头声明推送意图，再由支持 Push 的反向代理（如 Envoy）执行
替代方案：用 Link 头 + 应用层控制（推荐）
虽然 Nginx 不推，但可配合后端生成标准 Link 响应头，让兼容的客户端（如旧版 Chrome）识别并预加载：
- PHP 示例（在输出 HTML 前）：
header('Link: </style.css>; rel=preload; as=style, </app.js>; rel=preload; as=script'); - Nginx 可透传该头（默认即透传），无需额外配置
- 注意：
rel=preload是现代标准，语义明确、浏览器支持好，且不依赖 HTTP/2 Push 机制
若仍需模拟 Push 效果（不推荐但可行）
可通过 Nginx 的 sub_filter 模块，在返回 HTML 时内联关键资源（如小 CSS、字体）或提前加载：
- 启用 sub_filter：
sub_filter '</head>' '<link rel="preload" href="/style.css" as="style"></head>';<br>sub_filter_once on;
- 仅适用于静态 HTML，动态内容需后端处理
- 本质是资源预加载（Preload），非真正的 Server Push，但效果接近且更可控
验证是否生效（无论用哪种方式）
打开 Chrome DevTools → Network 标签页 → 刷新页面 → 查看请求列表中的 Initiator 列：
- 若看到
preload或link，说明Link头或<link rel="preload">生效 - 在 Headers → Response Headers 中搜索
link:，确认头存在 - 不会看到 “push” 类型请求 —— 因为 Nginx 确实不推送
