# 新安装程序运行良好，但有一个主机名让我头疼

**URL:** <https://meta.discourse.org/t/new-installer-works-well-but-one-hostname-gave-me-fits/407204>\
**Category:** Self-hosting\
**Created:** [2026年七月9日 18:29 UTC](https://meta.discourse.org/t/new-installer-works-well-but-one-hostname-gave-me-fits/407204 "2026-07-09T18:29:23Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![philh](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/philh/32/532740_2.png) [@philh](https://meta.discourse.org/u/philh)\
**Post date:** [2026年七月9日 18:29 UTC](https://meta.discourse.org/t/new-installer-works-well-but-one-hostname-gave-me-fits/407204/1 "2026-07-09T18:29:24Z")

</div>

首先，必须给予应有的赞赏：新的安装程序是一个巨大的改进。当它正常工作时（大多数情况下都是如此），它比旧的手动流程要友好得多，我也能够通过它完成干净的安装。运行安装程序，像往常一样完成注册/激活，然后调整 `app.yml` 以符合我的规范。轻而易举。非常感谢 @Falco 和团队！这与 Discourse 安装的老日子相比，真是天壤之别。

我发布这篇文章是因为我也遇到了一个让我头疼的主机名，我认为这段经历可能指出了安装程序可以在几个地方向自托管用户提供更清晰信息的地方。

## 成功之处

我使用以下配置在一台新服务器上成功安装了 Discourse：

- 自有域名：是
- SMTP：是
- 当前的安装程序流程

安装程序到达了：

```plaintext
Tallyho!
恭喜，您已安装 Discourse！
注册新账户以开始使用。

```

所以这不是一个“新安装程序坏了”的帖子。安装程序可以运行得非常顺利。

## 棘手的主机名

在另一次安装中，使用相同的一般路径，目标主机名是：

```plaintext
forum.domain.tld

```

安装程序命令是：

```plaintext
wget -qO- https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse | sudo bash

```

选项大致如下：

- 创建 2 GB 交换文件：是
- 使用自有域名：是
- 主机名：`forum.domain.tld`
- 配置 SMTP：是
- SMTP 提供商：SendGrid
- SMTP 端口：587

安装程序到达了：

```plaintext
[4/5] 验证域名配置
? 正在检查您的域名...
? 连接到 forum.domain.tld 成功。

```

然后它写入配置并重建应用。

但网站在浏览器中无法干净地启动。最终的症状是：

```plaintext
forum.domain.tld 拒绝连接

```

反复的重建/重试尝试未能解决此问题。

## Discourse Doctor 结果

`./discourse-doctor` 找到了应用容器和预期的配置值。容器正在运行，端口 80/443 似乎已绑定。

但它报告：

```plaintext
forum.domain.tld 上的 Discourse 版本：未找到

```

稍后：

```plaintext
localhost 上的 Discourse 版本：未找到

```

这使得问题感觉不同于普通的公共 DNS 传播。

## ACME 速率限制

在故障排除路径的早期，我也尝试使用 Discourse 服务辅助路径进行安装：

- DiscourseID
- `yoursite.discourse.diy` 流程

这就是发生重复服务器敲击/重试行为的地方，也是 ACME 日志显示 Let’s Encrypt 速率限制的地方：

```plaintext
type: urn:ietf:params:acme:error:rateLimited
status: 429
detail: 已为此标识符集颁发过多证书 (5)...

```

有用的日志路径是：

```plaintext
/shared/letsencrypt/acme.sh.log

```

这是一个重要的教训。从浏览器来看，故障看起来像是一个通用的可达性问题。但当时的真正障碍是证书颁发。

最令人困惑的部分是，安装完成/最终状态块没有将此作为可操作的错误显示出来。最终面向用户的症状只是网站拒绝浏览器连接。

稍后的检查更清楚地显示了故障链：

```plaintext
ACME 429 速率限制
-> /shared/ssl 下的零字节 .cer 文件
-> nginx 尝试加载零字节证书
-> nginx 启动失败
-> 端口 80/443 拒绝
-> 浏览器显示连接被拒绝

```

体验中隐藏的功能请求：

如果安装程序/重建例程在证书步骤之后检查 `/shared/letsencrypt/acme.sh.log` 并显示速率限制错误，将会非常有帮助，例如：

```plaintext
rateLimited
too many certificates
status: 429

```

例如：

```plaintext
此主机名触发了 Let's Encrypt 速率限制。
在重试之前，请等待 /shared/letsencrypt/acme.sh.log 中显示的 retry-after 时间。
反复重建可能无济于事。

```

这将使用户避免在 DNS、SMTP、`app.yml` 引用、Docker 或防火墙问题上浪费时间，而实际问题在于 ACME。

## 速率限制清除后

在 Let’s Encrypt 速率限制窗口清除后，我仍然看到了令人困惑的域名验证情况。

安装程序报告：

```plaintext
[4/5] 验证域名配置
? 正在检查您的域名...
? 连接到 forum.domain.tld 成功。

```

但本地 DNS 查找仍然显示：

```plaintext
Resolve-DnsName -Name "forum.domain.tld"

```

结果为：

```plaintext
Resolve-DnsName: forum.domain.tld : DNS 名称不存在。

```

这两件事如何共存？

我可以想象几种可能性：

- 服务器和工作站使用了不同的递归解析器
- 一个解析器缓存了过期的 NXDOMAIN
- 当时 DNS 传播不完整
- 安装程序检查的内容不同于普通的 DNS 查找
- 安装程序或相关服务缓存了验证状态

我并没有声称哪一个是正确的。我主要指出，从用户的角度来看，安装程序说“连接成功”会使后续的 DNS 或可达性错误更难解释。

## DNS 隔离检查

为了测试这是否只是 Cloudflare 传播缓慢，我在同一区域中添加了另一个记录：

```plaintext
test.domain.tld

```

几分钟后，公共 DNS 检查器结果变为绿色。

这让我对一般的 Cloudflare 传播是全部问题这一观点信心不足。问题看起来更像是特定于 `forum.domain.tld` 的。

## 对比安装

我在另一个主机名上也有一次成功的安装：

```plaintext
discourse.domain2.tld

```

使用相同的一般安装程序路径。

另一个用于 DNS 诊断的测试主机名是：

```plaintext
forum.domain3.tld

```

对比安装使我远离“新安装程序坏了”的观点，转向“这里发生了特定于主机名的问题”。

## 当前理论

我目前的理论（未证实）是，`forum.domain.tld` 可能在服务器本身之外的某个地方具有一些特定于主机名的缓存/保留/记住的状态。

我怀疑的地方：

- DiscourseID
- `yoursite.discourse.diy` 流程
- 安装程序侧的域名验证
- 先前设置尝试与主机名之间的某些缓存关系

我怀疑这些服务辅助路径的原因是，我之前曾使用相同的问题主机名尝试过它们，这也是最终触发 Let’s Encrypt 速率限制的重复尝试路径。

再次强调，这是一个假设，而不是结论。

## 问题

1. 新安装程序在自有域名安装期间是否联系 Discourse 控制的服务？
2. DiscourseID 或 `discourse.diy` 流程是否保留、记住或缓存主机名？
3. 对于在设置期间以前使用或尝试过的主机名，是否有任何释放/重置路径？
4. `[4/5] 验证域名配置` 具体检查什么？
5. 安装程序是否可以在最终状态/结果块之前更清楚地显示 ACME 速率限制失败？

## 会有所帮助的事情

三件事会使故障排除路径更加清晰：

1. 当 `/shared/letsencrypt/acme.sh.log` 包含速率限制失败时，安装程序发出清晰的警告。
2. 对域名验证步骤实际检查内容的简短解释。
3. 如果存在任何 DiscourseID / `discourse.diy` / 安装程序侧的主机名缓存或保留，提供一种可见的方式来检查或释放该状态。

再次感谢对新安装程序的工作。它确实感觉是正确的方向。我以这种精神发布这篇文章：它在起作用时运行得非常完美，而这里的粗糙边缘似乎是更好的安装程序消息可以更轻松诊断的那种事情。

由我的新 BFF Codex 根据我的输入撰写。

---

<div class="post-metadata">

**Author:** ![philh](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/philh/32/532740_2.png) [@philh](https://meta.discourse.org/u/philh)\
**Post date:** [2026年七月9日 18:36 UTC](https://meta.discourse.org/t/new-installer-works-well-but-one-hostname-gave-me-fits/407204/2 "2026-07-09T18:36:53Z")

</div>

我被 Let’s Encrypt 的速率限制封禁，直到：

```plaintext
2026-07-09 23:25:18 UTC

```

而且，就像阿尔卡特拉斯岛监狱一样，越狱是不可能的。我将稍后恢复测试并汇报进展。

如果 Discourse 方面有谁能帮忙检查 `forum.domain.tld` 在 DiscourseID / `discourse.diy` / 安装程序流程中是否有任何缓存、保留或记忆的状态，那将非常有帮助。

---

<div class="post-metadata">

**Author:** ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)\
**Post date:** [2026年七月9日 21:17 UTC](https://meta.discourse.org/t/new-installer-works-well-but-one-hostname-gave-me-fits/407204/3 "2026-07-09T21:17:13Z")

</div>

关于 Let’s Encrypt，当有人在短时间内尝试签发过多证书时，这是一个非常常见的问题。通过简单方式一次性完成安装的用户永远不会受到影响，但对于在测试过程中进行多次安装的用户来说，这是一个反复出现的问题。

我的计划是尽快让我们从 acme.sh 迁移到 nginx 原生的 ACME 支持，这应该能更轻松地暴露此问题。

这取决于 [Update to trixie - Pull Request #1048 - discourse/discourse\_docker - GitHub](https://github.com/discourse/discourse_docker/pull/1048)

---

<div class="post-metadata">

**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\
**Post date:** [2026年七月10日 15:20 UTC](https://meta.discourse.org/t/new-installer-works-well-but-one-hostname-gave-me-fits/407204/4 "2026-07-10T15:20:12Z")

</div>

> [@philh](#):
>
> 突破限制并非选项

您可以添加第二个子域名，并为两者申请证书，这将构成一个新的请求。虽然等待要容易得多，但确实存在一种解决方案。😉

我认为这个主题描述了具体操作方法。

[配置 Let’s Encrypt 以支持多域名 / 重定向](https://meta.discourse.org/t/set-up-let-s-encrypt-with-multiple-domains-redirects/56685)

---

<div class="post-metadata">

**Author:** ![philh](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/philh/32/532740_2.png) [@philh](https://meta.discourse.org/u/philh)\
**Post date:** [2026年七月11日 23:01 UTC](https://meta.discourse.org/t/new-installer-works-well-but-one-hostname-gave-me-fits/407204/5 "2026-07-11T23:01:44Z")

</div>

> [@Falco](#):
>
> 这绝不会影响那些通过简单路径一键安装的人，

除非你像我一样，看不懂关于使用哪个电子邮件的警告，并且对使用 DiscourseID 和 yoursite.discourse.diy 流程一无所知。😆  
感谢更新你的计划，听起来不错，而且 Trixie 更新也很有趣。总是有什么新花样，嗯？

> [@pfaffman](#):
>
> 你可以添加第二个子域名，并为两者请求证书，这将构成一个新的请求。

谢谢，这可能会有用。

所以我以为我没事了，运行了 ./discourse-setup，结果进了禁闭室。考虑过使用 Jay 的双域名解决方案，但我在 Group W 的长椅上交了一些好朋友，所以我想我会耐心地等待假释。