首先，必须给予应有的赞赏：新的安装程序是一个巨大的改进。当它正常工作时（大多数情况下都是如此），它比旧的手动流程要友好得多，我也能够通过它完成干净的安装。运行安装程序，像往常一样完成注册/激活，然后调整 app.yml 以符合我的规范。轻而易举。非常感谢 @Falco 和团队！这与 Discourse 安装的老日子相比，真是天壤之别。
我发布这篇文章是因为我也遇到了一个让我头疼的主机名，我认为这段经历可能指出了安装程序可以在几个地方向自托管用户提供更清晰信息的地方。
成功之处
我使用以下配置在一台新服务器上成功安装了 Discourse：
- 自有域名：是
- SMTP：是
- 当前的安装程序流程
安装程序到达了：
Tallyho!
恭喜，您已安装 Discourse！
注册新账户以开始使用。
所以这不是一个“新安装程序坏了”的帖子。安装程序可以运行得非常顺利。
棘手的主机名
在另一次安装中，使用相同的一般路径，目标主机名是：
forum.domain.tld
安装程序命令是：
wget -qO- https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse | sudo bash
选项大致如下：
- 创建 2 GB 交换文件：是
- 使用自有域名：是
- 主机名：
forum.domain.tld - 配置 SMTP：是
- SMTP 提供商：SendGrid
- SMTP 端口：587
安装程序到达了：
[4/5] 验证域名配置
? 正在检查您的域名...
? 连接到 forum.domain.tld 成功。
然后它写入配置并重建应用。
但网站在浏览器中无法干净地启动。最终的症状是：
forum.domain.tld 拒绝连接
反复的重建/重试尝试未能解决此问题。
Discourse Doctor 结果
./discourse-doctor 找到了应用容器和预期的配置值。容器正在运行，端口 80/443 似乎已绑定。
但它报告：
forum.domain.tld 上的 Discourse 版本：未找到
稍后：
localhost 上的 Discourse 版本：未找到
这使得问题感觉不同于普通的公共 DNS 传播。
ACME 速率限制
在故障排除路径的早期，我也尝试使用 Discourse 服务辅助路径进行安装：
- DiscourseID
yoursite.discourse.diy流程
这就是发生重复服务器敲击/重试行为的地方，也是 ACME 日志显示 Let’s Encrypt 速率限制的地方：
type: urn:ietf:params:acme:error:rateLimited
status: 429
detail: 已为此标识符集颁发过多证书 (5)...
有用的日志路径是：
/shared/letsencrypt/acme.sh.log
这是一个重要的教训。从浏览器来看，故障看起来像是一个通用的可达性问题。但当时的真正障碍是证书颁发。
最令人困惑的部分是，安装完成/最终状态块没有将此作为可操作的错误显示出来。最终面向用户的症状只是网站拒绝浏览器连接。
稍后的检查更清楚地显示了故障链：
ACME 429 速率限制
-> /shared/ssl 下的零字节 .cer 文件
-> nginx 尝试加载零字节证书
-> nginx 启动失败
-> 端口 80/443 拒绝
-> 浏览器显示连接被拒绝
体验中隐藏的功能请求：
如果安装程序/重建例程在证书步骤之后检查 /shared/letsencrypt/acme.sh.log 并显示速率限制错误，将会非常有帮助，例如：
rateLimited
too many certificates
status: 429
例如：
此主机名触发了 Let's Encrypt 速率限制。
在重试之前，请等待 /shared/letsencrypt/acme.sh.log 中显示的 retry-after 时间。
反复重建可能无济于事。
这将使用户避免在 DNS、SMTP、app.yml 引用、Docker 或防火墙问题上浪费时间，而实际问题在于 ACME。
速率限制清除后
在 Let’s Encrypt 速率限制窗口清除后，我仍然看到了令人困惑的域名验证情况。
安装程序报告：
[4/5] 验证域名配置
? 正在检查您的域名...
? 连接到 forum.domain.tld 成功。
但本地 DNS 查找仍然显示：
Resolve-DnsName -Name "forum.domain.tld"
结果为：
Resolve-DnsName: forum.domain.tld : DNS 名称不存在。
这两件事如何共存？
我可以想象几种可能性：
- 服务器和工作站使用了不同的递归解析器
- 一个解析器缓存了过期的 NXDOMAIN
- 当时 DNS 传播不完整
- 安装程序检查的内容不同于普通的 DNS 查找
- 安装程序或相关服务缓存了验证状态
我并没有声称哪一个是正确的。我主要指出，从用户的角度来看，安装程序说“连接成功”会使后续的 DNS 或可达性错误更难解释。
DNS 隔离检查
为了测试这是否只是 Cloudflare 传播缓慢，我在同一区域中添加了另一个记录：
test.domain.tld
几分钟后，公共 DNS 检查器结果变为绿色。
这让我对一般的 Cloudflare 传播是全部问题这一观点信心不足。问题看起来更像是特定于 forum.domain.tld 的。
对比安装
我在另一个主机名上也有一次成功的安装：
discourse.domain2.tld
使用相同的一般安装程序路径。
另一个用于 DNS 诊断的测试主机名是：
forum.domain3.tld
对比安装使我远离“新安装程序坏了”的观点，转向“这里发生了特定于主机名的问题”。
当前理论
我目前的理论（未证实）是，forum.domain.tld 可能在服务器本身之外的某个地方具有一些特定于主机名的缓存/保留/记住的状态。
我怀疑的地方：
- DiscourseID
yoursite.discourse.diy流程- 安装程序侧的域名验证
- 先前设置尝试与主机名之间的某些缓存关系
我怀疑这些服务辅助路径的原因是，我之前曾使用相同的问题主机名尝试过它们，这也是最终触发 Let’s Encrypt 速率限制的重复尝试路径。
再次强调，这是一个假设，而不是结论。
问题
- 新安装程序在自有域名安装期间是否联系 Discourse 控制的服务？
- DiscourseID 或
discourse.diy流程是否保留、记住或缓存主机名？ - 对于在设置期间以前使用或尝试过的主机名，是否有任何释放/重置路径？
[4/5] 验证域名配置具体检查什么？- 安装程序是否可以在最终状态/结果块之前更清楚地显示 ACME 速率限制失败？
会有所帮助的事情
三件事会使故障排除路径更加清晰：
- 当
/shared/letsencrypt/acme.sh.log包含速率限制失败时，安装程序发出清晰的警告。 - 对域名验证步骤实际检查内容的简短解释。
- 如果存在任何 DiscourseID /
discourse.diy/ 安装程序侧的主机名缓存或保留，提供一种可见的方式来检查或释放该状态。
再次感谢对新安装程序的工作。它确实感觉是正确的方向。我以这种精神发布这篇文章：它在起作用时运行得非常完美，而这里的粗糙边缘似乎是更好的安装程序消息可以更轻松诊断的那种事情。
由我的新 BFF Codex 根据我的输入撰写。