再構築は何も変化させず、HTTPS の接続は依然として拒否されたままです。さらに、HTTP 側では NGINX のウェルカムページが表示されるようになりました。
nginx がインストールされていることは間違いありません。
apt purge nginx または
dpkg -l | grep nginx
を試されましたか？
nginx を停止した後、./discourse-doctor はどのようなメッセージを表示しますか？
返答：nginx はインストールされていません
返答：なし
すべての入力項目（メールアドレスや Web アドレスなど）が空白です
また、ポート 80→80、443→443、2222→22 で 2 つのコンテナが実行されています
Discourse コンテナアプリが実行中と表示されています
Discourse バージョンは「未検出」と表示されています
おっと、下にスクロールしていなかったね。出力テキストを読んで、何と書かれているか確認しよう。
編集：同じことが書かれているようだ。
./discourse-setup を実行してこのスレッドを開始しましたか？
それらは何ですか？
セットアッププロセスを踏んだ（踏んだ）という意味ですか、それとも私が実行したのは ./discourse-doctor だったという意味ですか？
私の間違いです。一つだけありました。それは 4efab95a60b8 です。
HTTPのページは、データを送信しなかったと表示するだけで、もはやNGINXのページさえ表示されません。
編集：NGINXのページに戻りました
編集2：気にしないでください、戻っていません。
docker ps は何を表示しますか？
テキストファイルと全く同じコンテナ。
もしかしたら、このシナリオでは caddy を使ったリバースプロキシの方が良いかもしれませんか？
それが何だったのか、その名前が知りたかったのです。この番号には意味がありません。
過去に Caddy で成功した経験はありますが、おそらく同じ問題に直面するでしょう。
提案があります。
DigitalOcean の $5 ドロプレットに登録してください。インストールガイドを一字一句守り、追加の証明書などをコピーしないようにしてください。
DO のドロプレットは比例配分課金です。ガイドに従えば（所要時間は 30 分以内）、インストールの検証にかかる費用は $0.02 です。その後インスタンスが必要なければ、破棄ボタンを押すだけで構いません。
それでも失敗する場合は、トラブルシューティングを始めることができます。
成功すれば、これは Discourse の問題ではないことが証明されます。より複雑な環境を選択する場合は、残念ながらそれによって生じる追加の課題についても責任を負うことになります。標準的なインストールは DO の Ubuntu イメージで実証済みであり、同社のネットワークポリシーは Let’s Encrypt と問題を引き起こしません（ただし、メール送信には中程度の修正が必要な場合があります）。
なお、同じ証明書名を繰り返し要求している場合、Let’s Encrypt がその FQDN をクールダウン期間中に置いている可能性があります。
ついにできました。やったことを説明します。Caddy をインストールし、URL からのすべての接続を localhost:444 にリダイレクトするプロキシを設定しましたが、それだけではダメでした。app.yml を開き、Port を以下のように変更しました。
- "81:80" - HTTP をポート 81 に移動して Caddy 用に確保
-"444:443" - Caddy が HTTPS を処理
その後、ウェブサイト accessed すると、HTTPS への接続拒否が表示されず、正常に読み込まれます！
お手伝いしてくださったり、提案を残してくださった皆様に感謝します！
もし Discourse を再インストールする必要があるなら、絶対にこれをやるつもりです。