HTTP/2不改变Nginx缓存机制，但需显式配置Vary头、禁用硬性Cache-Control覆盖、开启gzip_vary，并确保推送资源带有效Cache-Control头，以实现缓存与HTTP/2协同。
HTTP/2 本身不改变 Nginx 缓存机制，但它的多路复用、头部压缩和服务器推送特性，会影响缓存行为与配置逻辑。Nginx 的 proxy_cache、fastcgi_cache 等缓存功能在 HTTP/2 下仍完全可用，但需注意协议层变化带来的兼容性细节——尤其是缓存键生成、Vary 头处理、以及推送资源与缓存的协同。
确保缓存指令与 HTTP/2 兼容
HTTP/2 不要求额外开启缓存模块，但以下配置项必须显式设置，否则可能因默认行为导致缓存失效或降级：
-
显式声明
Vary头：HTTP/2 允许客户端在单连接中并发多个请求，若响应依赖 User-Agent、Accept-Encoding 等头字段，必须通过add_header Vary或proxy_cache_key显式纳入缓存键。例如：proxy_cache_key "$scheme$request_method$host$request_uri$http_accept_encoding$http_user_agent"; -
禁用不安全的缓存覆盖头：避免使用
add_header Cache-Control "no-cache"这类硬性覆盖，它会干扰 HTTP/2 的流优先级调度；应改用expires或proxy_cache_valid统一控制。 -
保持
gzip_vary on：HTTP/2 原生支持头部压缩（HPACK），但若后端返回未压缩内容且 Nginx 启用了gzip，则必须开启gzip_vary on，否则同一 URI 的压缩/未压缩版本可能被错误复用。
适配服务器推送（Server Push）与缓存联动
HTTP/2 Server Push 是可选特性，Nginx 本身不主动推送，但可通过 http2_push 指令手动触发。推送资源若已缓存，需确保其缓存策略允许被复用：
- 被推送的资源（如
/style.css）必须有明确的Cache-Control响应头（如public, max-age=31536000），否则浏览器不会缓存推送内容。 - 在 server 块中启用推送时，建议配合缓存验证：
http2_push /style.css;<br>http2_push_preload on;
其中http2_push_preload on可让 Nginx 自动将Link: </style.css>; rel=preload转为推送，前提是该资源已在本地缓存命中或可被缓存。 - 避免推送动态内容（如
/api/status?ts=...），这类 URI 通常带随机参数，无法有效缓存，反而浪费连接带宽。
避免缓存与 ALPN 协商冲突
HTTP/2 依赖 TLS 层的 ALPN 扩展协商协议，而某些缓存配置可能意外干扰协商过程：
- 不要在
location块中对/使用proxy_cache_bypass $http_upgrade类逻辑——Upgrade头在 HTTP/2 中已废弃，保留它可能引发协商异常。 - 若使用
proxy_cache_use_stale，避免启用error timeout updating以外的选项，防止在 TLS 握手阶段返回过期缓存，导致 ALPN 通告失败。 - 检查日志中是否出现
upstream sent no valid HTTP/1.0 header类报错——这往往意味着上游返回了不兼容 HTTP/2 的响应头（如重复的Connection头），而缓存又将其原样返回，破坏了 ALPN 流程。
验证缓存 + HTTP/2 是否协同生效
仅看 curl -I --http2 返回 200 并不够，需确认缓存真正参与且未降级：
- 在响应头中查找
X-Cache: HIT（或你自定义的缓存标识头），同时 Network 面板 Protocol 列显示h2—— 两者共存才说明缓存与 HTTP/2 同时工作。 - 用
curl -I --http2 -H "User-Agent: test-vary" https://yoursite.com和-H "User-Agent: test-vary-2"分别请求，观察X-Cache是否分别为 HIT/HIT 或 HIT/MISS —— 可验证Vary是否正确影响缓存键。 - 对推送资源执行
curl -I --http2 -H "Accept: text/css" https://yoursite.com/style.css，确认响应含Cache-Control且无no-store，再刷新页面查看 DevTools 的 Initiator 是否为Push。
