状況についてアップデートしたいと思います。
いくつか調査した結果、コンテナ1つでマルチサイト設定が必要だと判断しました。外部のnginxサイトで設定を説明し、個別のDiscourseサイトへの誘導とトラフィックを処理します。これにより、list1のユーザーがlist2の内容を気にする必要なく、両方のサイトを読み取り専用（およびウェブクローラー向け）に公開できます。ウェブクローラーを満足させるためにrobots.txtを調整する必要があるかもしれません。
マルチサイト設定の例は参考になりましたが、Unixソケットでは動作しませんでした（ゲートウェイエラー）。そのため、別のポートに転送し、そのポートをコンテナ内の443にリダイレクトすることにしました。
app.ymlファイルでは、SSLテンプレートを有効にしましたが、letsencryptは有効にしませんでした。
テスト環境のサイトは動作するようになりました。今後は、今月後半か来月に予定している本番サイトへの移行時に発生する可能性のある問題を探しています。
証明書の問題は外部サーバー側で対応していますが、「安全でない」という問題に遭遇しました。これは、コンテナ内でhttpsを必須にすることで修正しました。cronで実行するタスクがあり、最新の証明書とキーをコンテナの/shared/sslディレクトリにコピーします（ssl.crtとssl.keyとして）。証明書が変更されたとき（おそらく7月）、コンテナ内のnginxを強制的にリロードして新しい証明書がロードされるようにする必要があるかどうかはまだわかりません。
Discourseの落とし穴が1つありました。
コンテナ内の/etc/nginx/conf.d/discourse.confファイルに、次のコード断片があります（ドメイン名は変更しています）。
if ($http_host != 'site1.my.domain') {
rewrite (.*) https://site1.my.domain$1 permanent
}
これはsite2.my.domainをsite1.my.domainにリダイレクトしていたため、コメントアウトする必要がありました。
注：コンテナを再構築すると、この編集をやり直す必要があります。これを回避する方法はありますか？
そして、ブラウザの落とし穴につながりました。Firefoxがそのリダイレクトを永続的であるとフラグ付けしたため、ブラウザのキャッシュを削除する必要がありました。（これは理解するのに非常に時間がかかりました！）
もう1つ奇妙なことがわかりました。
テスト環境のサイトでは、httpsを必須にするパラメータはどちらのサイトでもチェックされていませんでした。本番サイトでは、そのパラメータは設定ファイルにさえ存在しません。これは、2つのサイト間の違いに関連しているのではないかと推測しています。