Certbot webroot 验证返回 404：确认挑战文件对应哪个站点目录

运行 certbot certonly --webroot 后，证书验证提示 unauthorized，并说明 /.well-known/acme-challenge/ 返回 404 Not Found。如果命令使用 -w /var/www/cert，实际 Nginx 站点却从 /var/www/html 提供文件，Certbot 写入的挑战文件就不一定能通过 HTTP 访问。

webroot 验证需要已有 Web 服务提供挑战路径，Certbot 不会因为收到一个目录参数就自动把它配置到 Nginx。先核对写入目录与请求落到的站点、location 映射，再决定修正 -w 还是单独配置挑战路径。

-w 是文件根目录，不是挑战目录本身

例如 -w /var/www/html 会让挑战文件位于 /var/www/html/.well-known/acme-challenge/ 下。若把 -w 直接指向这个最终目录，路径会再多出一层，不能按“哪里缺文件就填哪里”处理。

查看实际加载的 Nginx 配置，确认该域名的 80 端口 server 以及挑战 URI 的处理规则。root 指向 /var/www/html 只是一个线索；更具体的 location、alias、重写、反向代理或拒绝隐藏目录的规则都可能改变最终结果。

Nginx 配置输出可能含内部地址或敏感信息，检查时应在受控终端阅读，无须把完整输出贴到公开位置。容器部署还要分别核对 Certbot 与 Nginx 所见的路径、挂载是否对应同一批文件，宿主机目录相同不代表两个容器看见的内容相同。

用无敏感内容的临时文件确认映射

在预期根目录下的 .well-known/acme-challenge/ 中放置一个独立命名、无敏感内容的测试文件，保留已有挑战文件，别覆盖它们。从外部网络请求以下结构示例：

http://example.com/.well-known/acme-challenge/debug-path-check.txt

应返回测试文件的确切内容，不是首页、登录页、代理错误或自定义 404 页面。即使状态码是 200，内容不匹配也不能证明验证路径正确；测试完成后只删除自己创建的测试文件。

返回 404 时，结合访问日志判断请求是否进入了预期站点，再查文件根目录和 location 映射。403 需检查权限或访问规则；连接失败则需查服务与网络。DNS 指向其他主机或存在不同地址时，也要先确认请求落点，不能把它们当作同一个目录错误。

目录对齐后，先做测试申请

如果站点确实直接从 /var/www/html 提供挑战文件，可按当前 Certbot 使用实际根目录。以下是测试申请示例，域名为占位值：

certbot certonly --webroot -w /var/www/html -d example.com --dry-run

这里测试的是验证流程，不产生可用于正式服务的证书。测试仍可能执行已配置的 pre/post hooks；先核对它们是否会停启服务或修改文件，不能把 dry-run 当作完全无副作用。正式申请前去掉测试选项，并按原证书的名称和域名集合安排变更；不要借排查随意更换现有证书 lineage 或遗失它包含的其他名称。

多个域名不一定共用 webroot。使用重复的 -w 与 -d 配置时，后续名称采用最近指定的目录，要核对每个域名对应的站点。选用 Nginx 插件也需要插件可用且能识别实际配置，不能把换验证器当作路径未知时的保证。

webroot 方式通常无须停止现有 Web 服务。调整 Nginx 路由时，先保存配置、校验后按既有方式 reload，并确认没有改变其他业务路径；目录权限按服务实际需要设置，不要把整个站点改为任意用户可写。

验收应覆盖外部挑战内容、测试验证、正式签发及后续续期使用的验证配置。新证书还需按服务既有方式加载，不能把申请成功当作服务已更新。回退时恢复保存的站点配置与原证书部署，保留有效旧证书；仅恢复命令参数不会撤销已经生成的证书或其他配置变更。