Nginx多台服务器SSL证书自动化同步核心是内容一致、路径统一、权限合规、更新原子、验证闭环；需主节点集中操作，通过rsync+SSH密钥原子推送证书目录，同步后比对指纹、nginx -t校验并reload，私钥权限强制600、路径绝对统一。
只在主节点操作，推送至所有备节点
避免多点并发更新引发冲突。所有证书生命周期操作（申请、续期、替换）必须集中于一台可信主节点（如运行 Certbot 或 Lego 的机器），再通过安全通道推送到其他节点：
- 用 certbot renew --deploy-hook 或 lego run --renew-hook 触发同步脚本，而不是依赖定时任务轮询
- 脚本中明确列出所有目标服务器 IP 或主机名，支持批量推送
- 禁用密码登录，使用 SSH 密钥认证，并限制该密钥仅能执行 rsync 命令（通过
command="rsync --server..."在~/.ssh/authorized_keys中约束）
用 rsync 实现原子化同步
rsync 是最轻量、可靠、可验证的同步工具，关键在于参数和流程设计：
- 使用
rsync -avz --delete --checksum --progress：保证内容比对（非仅修改时间）、删除备机残留旧文件、显示进度 - 同步整个证书目录（如
/etc/nginx/ssl/example.com/），而非单个文件，避免符号链接断裂（尤其 Let’s Encrypt 的 live 目录） - 同步后立即校验：在目标节点执行
openssl x509 -in fullchain.pem -noout -fingerprint，与主节点输出比对 SHA256 指纹 - 若校验失败，自动退出并告警，不执行后续 reload
同步后必须精准重载 Nginx
证书文件更新 ≠ 服务生效。Nginx 不会自动感知文件变化，必须主动触发重载，且要防止中间状态：
- 先完成 rsync 同步并校验成功，再执行
ssh user@backup "systemctl reload nginx" - 重载前加
nginx -t验证配置语法，失败则记录日志并停止流程 - 避免使用
systemctl restart nginx，reload 更轻量、无连接中断 - 若为 Keepalived + Nginx 架构，确保 reload 不影响 VIP 状态；可加
sleep 1避免高并发 reload 冲突
权限与路径必须严格统一
同步内容只是基础，路径、属主、权限出错同样导致 Nginx 启动失败或拒绝加载私钥：
- 证书路径必须绝对一致（如
/etc/nginx/ssl/example.com/fullchain.pem），不能用相对路径或软链替代 - 私钥文件权限强制设为 600，证书链为 644；目录权限建议
700（chmod 700 /etc/nginx/ssl） - 属主统一设为
root:root，Nginx 工作进程以非 root 用户（如www-data）读取，依赖文件系统权限控制 - 所有节点提前执行：
mkdir -p /etc/nginx/ssl/example.com && chown root:root /etc/nginx/ssl/example.com
