核心是控制信任链切换节奏、隔离变更影响、保障多节点状态一致；需逐站梳理结构，采用双证书并行+分批灰度，解耦DNS/CDN与证书更新，并通过自动化注入与秒级回滚兜底。
在 Nginx 中实现 HTTPS 服务的平滑迁移，核心不是“换证书”或“改配置”本身，而是控制信任链切换节奏、隔离变更影响、保障多节点状态一致。整个过程可不中断服务，用户无感知。
一、先理清当前 HTTPS 部署结构
几十到万级站点的迁移失败，往往源于对现状缺乏统一视图。需逐站确认：
- 证书来源（Let’s Encrypt / 商业 CA / 内部 PKI）、有效期、密钥类型（RSA/ECC）、是否含 SAN 或通配符
- SSL 终止位置：是直接部署在 Nginx 源站？还是由 CDN、WAF、云负载均衡（ALB/CLB）卸载？
- 是否启用 OCSP Stapling、HSTS、CRL 检查等增强机制；这些功能在新环境必须完整继承
- 证书路径、文件权限（如 600）、所属用户（如 www-data）是否与旧环境严格一致
二、采用双证书并行 + 分批灰度策略
拒绝一次性全量切换。推荐按风险分组，例如首批选 2–3 个低流量、结构清晰的站点：
- 在 Nginx 中为同一 server 块同时加载新旧证书（支持 SNI 的 OpenSSL ≥1.0.2 可自动协商）
- 通过 DNS 权重、LB 流量比例或 Nginx 的 map + if 控制灰度范围（如仅放行指定 IP 段或请求头）
- 用 curl -v --tlsv1.2 --ciphers ... 和 openssl s_client 主动验证握手路径与证书链完整性
- 监控真实 TLS 握手成功率、OCSP 响应时间、HTTP 状态码分布，确认无降级或连接失败
三、解耦证书更新与 DNS/CDN 变更
证书生命周期和流量调度必须独立管理：
- 若使用云厂商托管证书（如 AWS ACM、阿里云 SSL 证书），先完成域名预验证与证书签发，再切 DNS 流量
- CDN/WAF 层务必提前刷新 HTTPS 缓存（如 Cloudflare 设置 Cache Level Bypass，阿里云开启“强制刷新 HTTPS 证书”）
- 避免因 CDN 缓存旧 OCSP 响应或 stapled 数据，导致客户端校验失败
四、自动化注入 + 秒级回滚兜底
手动操作几十个站点极易出错。应构建脚本化流水线：
- 调用宝塔 API 或自研平台批量获取站点列表与路径信息
- 根据域名自动生成标准化 SSL 配置块，并注入新证书路径与 cipher 套件（注意 TLS 1.3 专用套件不能混用 TLS 1.2）
- 每批次切换后触发健康检查脚本；若异常率超阈值（如握手失败 > 0.5%），自动回滚至旧证书配置并告警
