SSL本身不压缩HTTP头部，HTTP/2通过HPACK机制实现安全头部压缩，所有Header经TLS加密传输；需禁用TLS压缩、启用TLS 1.2+及前向保密套件，并配置http2_max_field_size等参数防范侧信道与资源耗尽风险。
HTTP/2 启用后，SSL 层本身不直接处理头部压缩；真正负责头部压缩的是 HTTP/2 协议内置的 HPACK 机制，它运行在加密通道（TLS）之上，与 SSL/TLS 是分层协作关系。所谓“SSL 头部压缩安全防护”，实际是指在启用 HTTP/2 的前提下，如何正确配置 TLS 和 HPACK，避免因配置不当引入信息泄露、降级攻击或兼容性风险。
HPACK 压缩本身是安全的，但需防侧信道泄露
HPACK 使用静态表 + 动态表 + Huffman 编码压缩 Header，不加密 Header 内容，但所有数据均经 TLS 加密传输，因此网络中间人无法解密原始 Header。不过，压缩后的帧长度可能间接暴露敏感信息（如 Cookie 长度变化可推断登录状态），这属于 压缩侧信道攻击（如 CRIME 攻击的变种）。Nginx 本身不提供 HPACK 级别的长度掩码或填充控制，防御依赖于上层 TLS 配置：
- 禁用 TLS 压缩（
ssl_prefer_server_ciphers on+ 显式关闭 TLS-level compression）——CRIME 攻击利用的是 TLS 层压缩，而非 HPACK； - 使用 TLS 1.2 或更高版本，并禁用弱密码套件（如不含 RC4、EXPORT、NULL）；
- 启用
ssl_session_tickets off，防止会话票据被重放后辅助推测 Header 模式。
Nginx 中与 HPACK 相关的关键配置项
Nginx 不暴露 HPACK 参数调优接口（如动态表大小、编码策略），其行为由所链接的 OpenSSL/BoringSSL 库决定。但以下配置直接影响 HPACK 的安全性与稳定性：
-
http2_max_field_size：限制单个 Header 字段最大字节数（默认 4KB），防止恶意超长字段耗尽 HPACK 解码内存； -
http2_max_header_size：限制整个请求 Header 总大小（默认 16KB），避免大 Header 触发 HPACK 解压异常； -
http2_max_requests：单连接最大请求数（默认 1000），配合 TLS 会话复用，降低长期连接中动态表积累敏感 Header 的风险。
必须搭配的 TLS 安全加固项
HTTP/2 强制要求 TLS，且主流浏览器仅支持 ALPN 协商下的 TLS 1.2+。若 TLS 配置松散，即使启用了 HTTP/2，也会削弱整体安全性：
- 强制使用 TLS 1.2 / 1.3：
ssl_protocols TLSv1.2 TLSv1.3;（禁用 TLS 1.0/1.1）； - 选用前向保密套件：
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;； - 开启 OCSP Stapling：
ssl_stapling on; ssl_stapling_verify on;，减少证书状态查询暴露； - 设置合理会话缓存：
ssl_session_cache shared:SSL:10m; ssl_session_timeout 4h;，平衡性能与密钥生命周期。
验证是否真正启用安全的 HTTP/2 + HPACK
不能只看 Nginx 配置中有 http2，还需确认端到端生效：
- 用 Chrome DevTools → Network → 检查某资源的 Protocol 列是否显示
h2； - 用
curl -I --http2 https://yourdomain.com查看响应头是否含alt-svc或直接返回 200； - 抓包分析（如 Wireshark + TLS 解密）观察 Frame 类型：应出现
HEADERS、CONTINUATION帧，Header 字段以整数索引+Huffman 编码形式存在，而非明文； - 检查 Nginx 错误日志，确认无
http2 stream error或header size too large类警告。
