webroot模式可批量签发、自动续期且不改Nginx配置、不中断服务；需全局统一配置location ^~ /.well-known/acme-challenge/指向共用验证目录，并通过分组循环执行certbot certonly实现多域名证书管理。
能批量签发、自动续期、不改 Nginx 配置、不中断服务——webroot 模式是目前管理几十上百个域名 HTTPS 证书最稳的路。它不依赖 certbot-nginx 插件自动重写配置，也不用停 Nginx 启 standalone 服务，所有验证都走现有 HTTP 流量，可控性高、故障面小。
location ^~ /.well-known/acme-challenge/ 必须全局统一配置
这个 location 是整个 webroot 模式的命脉。它不能写在某个 server 块里，也不能每个域名单独配一套路径，否则批量申请时会反复失败。
- 所有域名共用一个验证根目录，比如
/var/www/certbot，创建后确保 Nginx 进程可读：sudo chown nginx:nginx /var/www/certbot - 在全局配置（如
/etc/nginx/conf.d/common.conf或http块内）加一段固定规则：location ^~ /.well-known/acme-challenge/ { root /var/www/certbot; try_files $uri =404; } - 千万别用
alias——末尾斜杠处理不一致会导致 404；也别嵌套在location /里，优先级冲突会让验证文件压根不命中 - 验证是否生效：手动放个文件
echo test > /var/www/certbot/.well-known/acme-challenge/test，然后curl http://any-domain-you-have/.well-known/acme-challenge/test应返回test
certbot certonly --webroot 批量执行要按域名组拆开
certbot 不支持一次命令签发完全无关的域名（比如 a.com、b.net），但可以对同一主域下的多个子域（site1.com、www.site1.com、api.site1.com）打成一张证书。所以批量不是“全塞进一个命令”，而是“分组循环执行”。
- 把域名按归属分组，每行一组，写入
/opt/domains.txt：site1.com www.site1.com api.site1.com site2.com docs.site2.com example.com
- 用 while 循环调用，避免单点失败阻断全部：
while read -r domains; do certbot certonly --webroot -w /var/www/certbot \ -d $domains \ --email admin@$(echo $domains | awk '{print $1}') \ --agree-tos --non-interactive --quiet done < /opt/domains.txt - 每组成功后，证书存进独立目录：
/etc/letsencrypt/live/site1.com/，结构干净，后续 Nginxinclude或脚本轮询都方便
自动续期不能只靠 certbot renew + nginx -s reload
直接在 crontab 里写 certbot renew && nginx -s reload 是危险操作：续期成功但 reload 失败（比如配置语法错误），Nginx 就会退出，HTTPS 服务瞬间中断。
- 必须用
--deploy-hook把 reload 封装进原子流程：certbot renew --quiet --no-self-upgrade \ --deploy-hook "nginx -t && systemctl reload nginx"
- 检查 reload 是否真生效：hook 里加
nginx -t验证语法，再systemctl reload nginx，任何一步失败都不继续 - 测试续期逻辑是否通：先跑
certbot renew --dry-run，看日志里有没有Attempting to renew cert (site1.com)...和Deploying certificate - 注意证书实际续期时间：Let’s Encrypt 默认只在到期前 30 天内触发续期，
--dry-run不受此限，但真实 cron 任务得等够天数才动作
Nginx HTTPS 配置必须模板化 + 独立引用证书路径
不要为每个域名复制粘贴一整段 server { listen 443 ssl; ... }。证书路径、SSL 参数、业务逻辑要解耦，否则新增域名或调整 cipher 套件就得改几十个文件。
- 在
/etc/nginx/conf.d/ssl/下为每个域名建单独 conf：site1.com.conf，内容只含关键段：server { listen 443 ssl http2; server_name site1.com www.site1.com; ssl_certificate /etc/letsencrypt/live/site1.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/site1.com/privkey.pem; include /etc/nginx/conf.d/ssl/params.conf; # 公共 SSL 参数 location / { proxy_pass http://backend-site1; } } - 公共参数（TLS 版本、cipher、session 缓存）抽到
/etc/nginx/conf.d/ssl/params.conf，统一维护 - HTTP server 块里仍保留 301 跳转，但不用再重复写
location ^~ /.well-known/acme-challenge/——它已在全局配置里，复用即可
最常被忽略的是权限和 SELinux：CentOS/RHEL 上若启用了 SELinux，/var/www/certbot 目录可能需要额外打标 chcon -R -t httpd_sys_content_t /var/www/certbot，否则 Nginx 读不到验证文件；另外，certbot 续期后生成的新私钥默认权限是 600，但 Nginx worker 进程若非 root 启动，可能无权读取——建议用 --deploy-hook 顺手 fix：chmod 644 /etc/letsencrypt/live/*/privkey.pem。
