これはDiscourseインスタンスを停止させているようです。「Oops…」という高負荷のメッセージを越えられません。
Create new order error. Le_OrderFinalize not found. {
"type": "urn:ietf:params:acme:error:rateLimited",
"detail": "too many certificates (5) already issued for this exact set of identifiers in the last 168h0m0s, retry after ....
理由はどうあれ、他の人もこれに遭遇しているようですが、解決策はありますか？
数時間待ってから再試行するだけで済むと思います。記憶が正しければ、レートリミットは1時間ごとにリセットされます。また、ドメインに www プレフィックスをリクエストして新しい証明書を取得し、カウントをリセットすることもできます。
そのヒントをありがとうございます。数時間経っているので、今から再構築を試してみます。
@Ed_S のこちらの投稿によると、待機期間は7日間のようです！
再構築（Rebuild）では解決しませんでした。
www を追加して新しい証明書を取得するためにウィザードセットアップを再実行しました。一見するとうまくいったように見えますが、443 がアクセスできないというエラーを回避するために、@pfaffman の提案に従って接続チェックを無効にする必要がありました。
しかし、現在は証明書の読み込みに失敗しています。ログには以下が出力されています：
...PEM_read_bio_X509_AUX() failed (SSL: error:0480006C:PEM routines::no start line:Expecting: TRUSTED CERTIFICATE)
これは 443/80 ポートがクローズされている問題に関連している可能性があります。これは私が確認している別の一般的な問題でもあります。
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 72556/docker-proxy
tcp6 0 0 :::443 :::* LISTEN 72564/docker-proxy
外部のチェッカーでポートをスキャンすると、クローズ状態と表示されます 
OK、復元されたDBバージョンを備えた別のサーバーに戻しました。そのサーバーではポート80/443が開いていました。続行する前に、外部のポートスキャナーで確認しました。
./launcher discourse-setup を実行すると、ポート443がアクセスできないというエラーが発生しました。
そこでサーバーを再スキャンし、ポート80と443を確認したところ、今度は閉じていると表示されました。
ウィザードを実行する行為自体がポートを閉じてしまうようです?!
ウィザードは複数のドメイン名をサポートしていないと思いますが、最後に使ったのがかなり前なので確実ではありません。
おそらくこれが問題の原因です。DNS が設定されていないか、受信トラフィックがブロックされている可能性があります。
こんにちは、ありがとうございます。はい、別のトピックで見つけたアドバイスに従って「grey clouds」を元に戻したことで、上記の PEM_red… エラーを解決することができました。
ウィザードを実行した際、www. 付きのドメインを入力しただけですが、これが間違いでしょうか？ これはレートリミットを回避するためにそうしました。
いずれにせよ、その PEM エラーを過ぎると、次はこれにぶつかりました：
fail: nginx: runsv not running
[Wed Sep .... UTC 2026] Reload error for :
C=US, O=Let's Encrypt, CN=YR1
error 2 at 1 depth lookup: unable to get issuer certificate
error fullchain.cer: verification failed
C=US, O=Let's Encrypt, CN=YE2
error 2 at 1 depth lookup: unable to get issuer certificate
error fullchain.cer: verification failed
しかし、これは軽度のエラーのように見えます。なぜなら、ログには以前「grey clouds」を設定する前には発生しなかった証明書更新の成功メッセージが連続して出力されているからです。
また、ポート 80 と 443 はオープン状態を示しています。
さらに、ログの末尾に以下が複数回出力されているのを見かけます：
X-Accel-Mapping header missing
もう少し文脈を補足しますと、インスタンスはドメインに解決され、ログインを許可しています。ログイン画面（ログインのみに設定）が表示され、認証情報と2要素認証を受け入れますが、成功するとまた「Oops…」画面、つまり「またか」という状態に戻ります。
つまり、私は最初の出発点に戻ってしまいました。
元のサーバーインスタンスでは何も変更されていませんでした。突然、数日間パフォーマンスが低下する状態が続きました。この間、メトリクスは異常なレベルを超える奇妙な周期的なサーバー負荷を示していました。まるでアクセルを踏んでいるのに進まないような状態でした。最終的に、恒久的な「Opps」状態に陥ってしまいました。
そこで対処を開始しました。一つの解決策は、バックアップをとり、新しい Discourse にリストアすることでした。これが現在の状況です。つまり、ログインは可能ですが、また「Opps」に戻っている状態です。
また、過去の経緯として、以前は Full または Full (strict) で問題がありました。Full (strict) は常に動作せず、Full に戻す必要がありました。これは余談ですが。
あちゃ 
はい、成功を確認しました。以前使っていた非管理者ユーザーでログインできました。
どうやらこれがずっと問題の原因だったのに、ずいぶん回り道をしてしまいました！