Certbot 续期无法绑定 80 端口：检查 standalone 验证与现有服务

执行 certbot renew --dry-run 时出现 Could not bind TCP port 80 because it is already in use，而网站的 Nginx 正常监听 80，通常是续期仍在使用 standalone 验证器。它需要自己启动临时 HTTP 服务，不能与现有监听者争用同一个地址和端口。

本文针对 Linux 上的 Certbot HTTP-01 续期。端口绑定失败发生在本机，不等于挑战文件被外网防火墙拦截；换 DNS 记录或重复申请证书，不能让被占用的端口空出来。

先确认这张证书的续期方式

下面是只读检查示例；需要相应权限才能看到完整进程信息：

certbot --version
certbot certificates
sudo ss -ltnp 'sport = :80'

certificates 用于确认实际证书名称。它可能与某个域名不同，后面的 --cert-name 要使用列出的名称。再查看对应的 /etc/letsencrypt/renewal/CERTNAME.conf 中的 authenticator 和已配置的 hooks，不要直接改这个文件。

续期会复用先前保存的插件和选项。最初签发时没有 Web 服务、使用 standalone，后来加了 Nginx，就可能在定时续期时暴露冲突。

监听信息若仍显示 Nginx，应确认哪个进程、配置与服务管理方式在承担流量。一个 Nginx master 带多个 worker 很正常，不能仅凭多个 PID 就认定启动了重复实例。若停止 systemd 服务后仍有监听，要查是否有容器、手动启动的实例或其他管理器；不要直接杀掉所有 Nginx 进程。

已有 Nginx 时，改用能配合它的验证器

如果 Nginx 就在 Certbot 所在主机，由当前账户和插件管理，且配置受到插件支持，可以选择 Nginx 验证器。使用前备份 Nginx 配置、证书续期配置和现有部署方式，并确认 Nginx 当前正常运行。插件可能临时调整和重新加载配置。

Certbot 2.3.0 及以上支持 reconfigure。下面是更改单张证书验证方式的示例，example.com 需替换为证书名称，且 Nginx 插件必须已经安装：

sudo certbot reconfigure --cert-name example.com --authenticator nginx

该命令先用测试服务器检验新续期选项，成功后保存，供以后续期使用。它不是绕过端口检查，也不是已签发新的生产证书。操作前核对这张证书原来的 hooks，避免仍保留“停止 Nginx”之类与新验证器冲突的安排。

Certbot 2.2.0 及更早版本没有这条流程。可先对指定证书使用新选项做 dry-run，再按旧版规则完成一次成功的真实续期来持久保存。不要把一次 dry-run 当作已经更改定时续期配置；真实强制续期涉及 CA 频率限制，应在确认方案后安排一次，而非反复重试。

如果 Web 服务在别的容器或机器，Nginx 插件不能因为域名相同就自动管理它。可考虑 webroot：Certbot 写出的 /.well-known/acme-challenge/ 文件必须由实际公网入口提供，多个域名的路径也要逐个核对。不要把应用目录随意当成 webroot。

必须 standalone 时，把停启安排做完整

没有可用的 Web 集成、仍需 standalone 时，要确认停服窗口和真实监听者。暂停服务会影响网站访问；验证结束或失败后，都应恢复原服务并检查健康状态。续期前后 hooks 应由部署的实际服务管理器执行，不能假定一个 systemctl stop nginx 能停止容器或手动实例。

不要通过给 Certbot 换一个本地端口，就假定 CA 会访问那个端口。HTTP-01 的公网验证入口仍是 80；特殊转发部署需要明确配置和验证这条路径。

处理后对指定证书做续期模拟，检查插件、hooks 和 Nginx 状态，并确认未来自动任务使用已保存的设置。真实续期还要核对证书有效期和公网服务实际提供的新证书；renew 返回 0 也可能只是没有证书需要续期。配置或服务异常时，恢复备份及原停启安排，并保留原证书，避免在修复过程中失去现有 HTTPS。