申请SSL证书时，选择standalone本想省掉Web服务器配置，结果先撞上“端口已被占用”。换成8080后，本地不报错，域名验证却仍失败。这里有两把锁：本机能不能启动临时服务，以及公网验证请求能不能走到它。只打开其中一把，证书不会自己出现。
一、standalone负责什么，不负责什么
Certbot的standalone插件会独立启动验证服务，不依赖已有Web服务器。官方用法是certonly加–standalone；默认HTTP-01监听80端口，因此可能与正在运行的Web服务冲突。每个申请域名还必须能从互联网到达相应验证入口。[1]
certonly是获取证书，不等于把证书安装到Nginx、容器或负载均衡。本文给出准备顺序与隔离实验；没有调用真实CA，没有为示例域名申请证书，也没有停止任何生产服务。
图示仅限HTTP-01，两行是检查维度而非完整签发流程，箭头不表示左项通过便保证右项。公网入口可能经代理或端口映射到本地监听端；仍须CA验证与签发，拿到证书后还要部署与验收。
二、先查版本、插件与现有证书
certbot –version
certbot plugins
certbot certificates
certbot –help standalone
先确认实际调用的是哪套Certbot、standalone插件是否可用，以及已有Certificate Name。上面是只读检查模板；本文仅验证Shell语法与参数，没有把参数捕获替身算作Certbot实跑。已有证书的续期不要未经核对就反复新建申请。
端口占用要按监听地址、协议族、进程和运行环境查。宿主机、容器和不同网络命名空间的视角不能混用；只在容器里没看到80，并不能推出宿主机端口可用。确认服务归属后再安排变更，不要看到一个PID就直接结束它。
三、80端口空闲只是第一道检查
占用来源可能是Nginx、Apache、容器端口发布，或另一轮尚未结束的申请。应先确定哪个入口承载业务、是否允许短暂停机，再选择维护窗口；如果业务不能停，优先评估现有Web服务可配合的webroot或适合的DNS验证方案。
Certbot官方还说明：默认先尝试IPv6全部接口，再尝试IPv4，只要至少一次绑定成功便继续。多数Linux系统上IPv6监听也可能接收IPv4流量，第二次绑定失败可能是预期行为。因此不能只截取某条bind报错就判整次失败，要结合完整日志和最终结果。[1]
四、http-01-port不改变CA的公网入口
–http-01-port只改变Certbot本地监听端口，符合协议的ACME服务仍访问80端口。把它设为8080，既不会让CA改访问8080，也不会自动建立反向代理或端口映射。[1]
如果确实使用高位本地端口，就必须另行配置并验证“公网域名80端口→挑战路径→临时服务”的完整路由。普通业务路径能返回首页不够；也不要把该参数理解成绕过运营商、防火墙或安全组限制的开关。
Let’s Encrypt的HTTP-01挑战从80端口开始，允许有限的HTTP/HTTPS重定向，目标端口限80或443；它不支持通配符证书。不能把“可重定向”改写成任意端口均可验证。[2]
五、先做测试申请，但别把测试当无副作用
certbot certonly –standalone \\
–preferred-challenges http \\
–dry-run -d example.com
这是操作模板，不要原样对example.com执行。替换为自己有授权的域名，先核查全局及用户配置、ACME server设置与钩子，再在受控窗口操作。dry-run默认使用测试服务器且不保存测试证书，但server配置可改变实际目标；挑战和钩子仍可能产生真实操作。[1]
测试申请成功不能替代正式签发，正式签发也不能替代服务加载。记录实际CA、申请名称、证书路径及命令结果；正式步骤去掉测试选项之前，先确认不会把测试CA或错误域名带进正式配置。
六、用回环实验看清绑定冲突与释放
下面完整代码只用Python标准库。本文在Linux、Python 3.14.3运行，系统分配随机回环端口，不使用80，不发出HTTP请求，也不接触Certbot。socket的bind绑定地址，listen启用监听，with结束关闭套接字。[3]
import errno
import socket
host = "127.0.0.1"
with socket.socket() as first:
first.bind((host, 0))
port = first.getsockname()[1]
first.listen(1)
with socket.socket() as second:
try:
second.bind((host, port))
except OSError as exc:
if exc.errno != errno.EADDRINUSE:
raise
print("occupied: EADDRINUSE")
else:
raise RuntimeError("expected bind conflict")
with socket.socket() as third:
third.bind((host, port))
third.listen(1)
print("released: bind succeeds")
本次输出依次为occupied: EADDRINUSE和released: bind succeeds。第一个监听仍在时，第二个普通IPv4套接字绑定同地址同端口失败；关闭后重新绑定成功。代码没有启用SO_REUSEPORT等共享选项，因此不是所有复用配置的行为说明。
如果同机其他进程抢占已释放端口，最后一步也可能失败，应保留错误而非硬写成功。这个实验只证明本地套接字边界，不证明IPv6双栈、容器映射、互联网可达、CA验证或HTTPS已经正常。
七、把失败停在哪层记清楚
| 完整日志确认监听失败 | 占用、权限、地址与命名空间 | 一定是CA拒绝 |
| 本地服务可监听 | DNS、公网80、防火墙、代理路径 | 域名验证通过 |
| 挑战路径返回错误内容 | 入口节点、转发规则与实际响应 | 只需换监听端口 |
| 正式证书已生成 | 部署目标、加载、外部握手和业务 | 网站已使用新证书 |
多节点、CDN和代理入口尤其要看请求实际落点。一个节点能访问，不代表其他入口都返回同一挑战内容。Let’s Encrypt可能从多个视角重复取验证内容；多Web服务器须保证验证内容在相关入口可用。[2]
八、续期窗口与最终验收清单
手动申请时腾出端口，不代表之后定时续期也会自动腾出。若采用停服务窗口，应明确谁负责停、何时恢复、失败告警及异常中断后的恢复；不要直接复制带停机副作用的钩子命令。对不能中断的业务，先改变验证方案再谈自动化。
- 申请前：版本和插件可用，域名授权明确，端口占用与入口路由已查。
- 验证时：核对实际server与完整日志，不以本地监听成功代替CA结果。
- 签发后：核对最终证书名称、有效期和材料路径，部署至准确服务。
- 上线后：检查真实公网入口的名称、链、有效期及HTTP业务，另验续期窗口。
参考资料：
- [1] Certbot使用文档：standalone与命令参数
- [2] Let’s Encrypt挑战类型
- [3] Python socket文档
