http/2头部压缩自动启用且不可配置，前提是启用http/2协议（如listen 443 ssl http2;）、支持tlsv1.2+与alpn协商；可通过chrome devtools观察伪头部及header体积缩小来验证hpack生效，并通过统一域名、精简header、合理缓存提升压缩收益。
HTTP/2 的头部压缩是自动启用的，Nginx 本身不提供可调参数来干预 HPACK 压缩过程。只要启用了 HTTP/2 协议，HPACK 就会默认生效，无需额外配置压缩级别、字典大小或动态表容量。
确认 HTTP/2 已启用
这是头部压缩生效的前提：
- 确保监听 HTTPS 端口时添加 http2 关键字，例如：
listen 443 ssl http2; - 使用支持 TLSv1.2+ 的证书和加密套件（如
ECDHE-ECDSA-AES128-GCM-SHA256），HTTP/2 要求 ALPN 协商成功 - 禁用 TLSv1.0/v1.1，避免协议降级导致 HTTP/2 不被协商
验证头部是否被压缩
实际效果可通过浏览器开发者工具观察：
- 打开 Chrome DevTools → Network → 任一请求 → Headers 标签页
- 若看到以
:method、:path、:scheme开头的伪头部，且原始 Header（如 Cookie、User-Agent）体积明显缩小（典型从 800+ 字节降至 200 字节内），说明 HPACK 正在工作 - 注意：Cookie 值过长仍会拖慢首字节时间（TTFB），这不是压缩问题，而是传输量本身过大 —— 建议前端构建时剥离非必要 Cookie，改用 localStorage + API 显式携带
配合优化提升头部压缩收益
压缩效果取决于 Header 冗余度，以下做法能放大收益：
- 统一域名请求，让 Nginx 动态 HPACK 表在多个请求间复用（避免跨子域导致表重置）
- 精简请求 Header：后端接口关闭不必要的中间件注入（如 X-Powered-By、Server）、前端避免在每个请求中重复发送大体积自定义 token
- 对静态资源采用短缓存 + ETag，减少带完整 Header 的重复请求（协商缓存只传校验头，不传正文）
不复杂但容易忽略：头部压缩不是靠“配参数”实现的，而是靠协议升级 + 请求模式优化共同起效。
