排查Nginx中Certbot续期失败需分四层：环境一致性（cron路径/变量）、ACME挑战可达性（.well-known路由与响应）、Nginx证书加载有效性（配置路径、权限、SELinux）、多源日志时间线关联分析。
排查 Nginx 中自动化续期脚本（如 Certbot）执行失败的深层原因，关键不是只看报错信息，而是要分层验证：从脚本运行环境、ACME 协议交互、Nginx 配置耦合性，到证书文件权限与加载时机。下面按实际排查路径梳理几个核心环节。
检查脚本执行上下文是否与手动执行一致
很多失败源于“能手动跑通，但 cron 里失败”。这是因为 cron 默认使用极简环境（PATH 狭窄、无用户 profile、HOME 可能为空）。
- 在 crontab 中显式指定完整路径：比如用 /usr/bin/certbot renew --quiet --post-hook "/usr/sbin/nginx -s reload"，而非只写 certbot
- 在脚本开头加上 source /etc/environment 或直接导出必要变量（PATH=/usr/local/bin:/usr/bin:/bin）
- 用 run-parts --test /etc/cron.daily 确认脚本是否被识别；加日志重定向（> /var/log/certbot-cron.log 2>&1）捕获真实输出
验证 ACME 挑战阶段是否真正可达
续期失败常卡在 HTTP-01 或 TLS-ALPN-01 挑战环节——不是 Certbot 问题，而是 Nginx 没把挑战请求正确转发或响应。
- 临时启用 Certbot 的调试模式：certbot renew --dry-run --debug-challenges，观察它生成的 token 和 key-authz 路径
- 手动用 curl 测试：比如访问 http://yourdomain.com/.well-known/acme-challenge/xxx，确认返回内容与 Certbot 生成的一致，且 HTTP 状态码为 200
- 检查 Nginx 是否拦截了 .well-known 路径：确认 server 块中没有 location ^~ /.well-known { deny all; } 这类误配；若有 rewrite 或 proxy_pass，需确保该路径被显式放行
确认 Nginx 加载的是新证书，且无配置语法/路径错误
脚本可能成功获取证书，但 Nginx 没生效——常见于 reload 失败、证书路径写死、或 SELinux/ACL 限制。
- 在 post-hook 中不要只执行 nginx -s reload，应加判断：nginx -t && nginx -s reload || echo "Nginx config test failed" >> /var/log/certbot.log
- 检查 Nginx 配置中 ssl_certificate 和 ssl_certificate_key 指向的路径是否为 Certbot 实际写入的位置（如 /etc/letsencrypt/live/example.com/fullchain.pem），而非旧的硬编码路径
- 用 ls -lZ /etc/letsencrypt/ 查看 SELinux 上下文（RHEL/CentOS），若 context 异常（如 unconfined_u），可用 restorecon -Rv /etc/letsencrypt 修复；Debian/Ubuntu 则注意 www-data 用户是否有读取私钥权限（建议设为 640，属组包含 www-data）
抓取完整时间线：从日志串联整个流程
单看 certbot 日志容易漏掉前置依赖失败（如磁盘满、时间不同步、API 限频）。需横向比对多源日志。
- 查系统时间：timedatectl status，ACME 要求时间误差 ≤5 分钟，否则会报 “urn:ietf:params:acme:error:badNonce” 或 “connection refused”
- 看内核和系统日志：journalctl -u cron -n 50 + journalctl -u nginx -n 30 + tail -20 /var/log/letsencrypt/letsencrypt.log，按时间戳对齐三者输出
- 如果用 DNS-01，额外检查 DNS API 凭据是否过期、调用频率是否超限（Certbot 不报具体错误，只显示 “Failed authorization procedure”）
不复杂但容易忽略——真正的深层原因往往藏在环境差异、权限边界和配置耦合里。每次失败都值得顺一遍这四条线，比反复重试更省时间。
