nginx自动化脚本生成http/2配置需前置校验openssl≥1.0.2e、nginx含http_v2_module、tlsv1.2+启用，并固化listen 443 ssl http2、证书路径与权限、alpn验证及失败回滚机制。
在自动化运维脚本中为 Nginx 生成 HTTP/2 配置，关键不是“加一行 http2 on”，而是确保整个 HTTPS+HTTP/2 链路在生成阶段就满足全部运行前提，并能被验证、可回滚。手动写配置容易漏掉 OpenSSL 版本校验、ALPN 协商条件或 TLS 协议限制，而自动化脚本必须把这些隐性依赖显性化、检查前置化。
生成前先确认底层支持能力
脚本执行生成动作前，必须主动探测目标主机是否真正支持 HTTP/2，而不是假设“装了新版本 nginx 就行”。建议在配置生成流程开头插入校验步骤：
- 调用 nginx -V 2>&1 | grep -q 'with-http_v2_module'，失败则中断并报错“Nginx 未编译 HTTP/2 模块”
- 解析 nginx -V 输出中的 OpenSSL 路径，用 openssl version -d 和 ldd $(which nginx) | grep ssl 确认动态链接的是 ≥1.0.2e 的库
- 若为离线部署（如内网环境），需提前将校验结果缓存为变量（如 HTTP2_READY=true），避免每次重复检测
模板中强制绑定必要指令组合
server 块模板不能只留占位符，而要固化 HTTP/2 生效的最小合法结构。Jinja2 或 Shell 变量替换时，直接输出合规 listen 行：
- listen {{ https_port }} ssl http2;（IPv4）和 listen [::]:{{ https_port }} ssl http2;（IPv6）必须同时存在
- ssl_protocols TLSv1.2 TLSv1.3; 必须显式声明，禁用 TLSv1.0/1.1 —— 这是 ALPN 协商成功的硬性前提
- ssl_ciphers 建议预设强密码套件（如 ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256），避免因旧 cipher 导致协商降级
证书路径与权限同步处理
HTTP/2 不会因证书路径错误而报错，只会静默退回到 HTTP/1.1。脚本需把证书准备纳入原子操作：
- 若使用 Let’s Encrypt，调用 certbot certonly --webroot 后，自动将 fullchain.pem 和 privkey.pem 复制到预设目录（如 /etc/nginx/ssl/{{ domain }}/）
- 生成配置时，ssl_certificate 和 ssl_certificate_key 的路径必须基于该目录拼接，且脚本需执行 chown root:root && chmod 600 确保密钥文件权限安全
- 对自签名证书场景，脚本可内置 openssl 命令链一键生成（含 Common Name 校验），避免人工填错域名导致 h2 不生效
生成后立即触发端到端验证
配置写入磁盘只是第一步，脚本必须包含“是否真通 h2”的闭环验证：
- 执行 nginx -t 通过后，立刻用 curl -I --http2 -k https://{{ domain }} 检查响应头是否含 HTTP/2 200
- 失败时，自动回滚到上一版 conf 文件，并输出诊断建议（例如：“ALPN 未通告 h2，请检查 OpenSSL 版本或 CDN 是否终止 HTTP/2”）
- 可选增强：集成 openssl s_client -alpn h2 -connect {{ domain }}:443 2>/dev/null | grep ALPN，直连验证服务端 ALPN 响应
