まず、適切な感謝を表明します：新しいインストーラーは大きな改善です。動作する時（ほとんどそうです）は、従来の手動フローよりもずっと親しみやすく、クリーンインストールを完了できました。インストーラーを実行し、いつも通り登録/アクティベーションを完了し、その後 app.yml を私の仕様に合わせて調整するだけです。簡単です。@Falco とチームに心から感謝します。Discourse のインストールが昔と比べてどれほど違うか！
この投稿を書くのは、別のホスト名でつまずいた経験があり、その経験がインストーラーがセルフホスティングユーザーに情報をより明確に表示できるいくつかの箇所を示唆していると思うからです。
成功したケース
以下の設定で、新しいサーバーに Discourse を正常にインストールしました：
- 独自ドメイン：あり
- SMTP：あり
- 現在のインストーラーフロー
インストールは以下まで到達しました：
Tallyho!
Congratulations, you installed Discourse!
Register a new account to get started.
つまり、これは「新しいインストーラーが壊れている」という投稿ではありません。インストーラーは非常にうまく動作します。
問題のホスト名
別のインストールでは、同じ一般的な手順を用いましたが、対象ホスト名は以下でした：
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] Verifying domain configuration
? Checking your domain name...
? Connection to forum.domain.tld succeeded.
その後、設定を記述し、アプリを再構築しました。
しかし、ブラウザでサイトが正常に表示されませんでした。最終的な症状は：
forum.domain.tld refused to connect
でした。
再構築/再試行を繰り返しても解消されませんでした。
Discourse Doctor の結果
./discourse-doctor はアプリコンテナと期待される設定値を検出しました。コンテナは実行中で、ポート 80/443 はバインドされているように見えました。
しかし、以下を報告しました：
Discourse version at forum.domain.tld: NOT FOUND
そしてその後：
Discourse version at localhost: NOT FOUND
これにより、問題は通常の公開 DNS の伝播だけでは説明できないように感じられました。
ACME のレート制限
トラブルシューティングの初期段階で、Discourse サービス支援パスを使用したインストールも試みました：
- DiscourseID
yoursite.discourse.diyフロー
ここで、サーバーへの反復的な叩き/再試行の動作が発生し、ACME ログに Let’s Encrypt のレート制限が表示されました：
type: urn:ietf:params:acme:error:rateLimited
status: 429
detail: too many certificates (5) already issued for this exact set of identifiers...
有用なログパスは：
/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 時間を待ってください。
再構築を繰り返しても効果がない場合があります。
これにより、実際の問題が ACME であるにもかかわらず、ユーザーが DNS、SMTP、app.yml の引用符、Docker、またはファイアウォールの問題を追うことを防げます。
レート制限解除後
Let’s Encrypt のレート制限ウィンドウが解除した後、まだ混乱するドメイン検証状況に直面しました。
インストーラーは以下を報告しました：
[4/5] Verifying domain configuration
? Checking your domain name...
? Connection to forum.domain.tld succeeded.
しかし、ローカル DNS 検索は依然として以下を示しました：
Resolve-DnsName -Name "forum.domain.tld"
そして：
Resolve-DnsName: forum.domain.tld : DNS name does not exist.
これらの2つの事実はどう共存できるのでしょうか？
いくつかの可能性が考えられます：
- サーバーとワークステーションが異なる再帰リゾルバーを使用している
- 1つのリゾルバーが古くなった 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] Verifying domain configurationは正確に何をチェックしますか？- インストーラーは、最終ステータス/結果ブロックの前に ACME レート制限障害をより明確に表示できますか？
役立ったであろうこと
以下の3つが、トラブルシューティングの経路をずっと明確にしていたでしょう：
/shared/letsencrypt/acme.sh.logにレート制限失敗が含まれている場合の明確なインストーラー警告。- ドメイン検証ステップが実際に何をチェックするかについての簡潔な説明。
- DiscourseID /
discourse.diy/ インストーラー側のホスト名キャッシュまたは予約が存在する場合、その状態を検査または解放するための目に見える方法。
新しいインストーラーへの作業に再び感謝します。本当に正しい方向に進んでいると感じます。この投稿は、その精神で行っています：動作した時は美しく動作し、ここでの粗い縁は、より良いインストーラーメッセージングで診断しやすくできるようなもののように思えます。
私の入力に基づいて、私の新しい親友 Codex が書きました。