Docker コンテナ外で動作する nginx のレート制限の設定を、どなたか共有していただけませんか？（Discourse をソケットでセットアップしています）ありがとうございます。
適切に調整できず、有効なトラフィックまで制限されてしまっているようです。
本来制限すべきでないトラフィックが制限されているという意味ですか、それとも制限すべきトラフィックが制限されていないという意味ですか？
その通りです。まず、コンテナ内部のテンプレートを使用し、それを外部へ移動させました。外側の nginx に対するレート制限の推奨設定があるかどうかはわかりません。
絵文字やアバターは、他のトラフィックとは異なる制限が適切のようです。
ブンプ…本当に、外部 Nginx のレート制限に関するコツを共有してくれる人がいないのでしょうか？あらかじめありがとうございます！
トピックをバンプしないでください。もし誰かがあなたに答えを持っていたなら、きっと自発的に提示したはずです。
ここでメタの他のガイドに従い、nginx が正しく設定されてクライアント IP をコンテナに渡していることを前提として、これは本当に Discourse の問題でしょうか？
a) 認識している限りでは、コンテナの外に nginx を配置することが推奨されています。b) Discourse の要件に合わせてカスタマイズされるべきです。
したがって、はい、これは Discourse に関連する問題だと考えています。
これは本当に事実であり、推奨される実践方法なのでしょうか？
レート制限テンプレート templates/web.ratelimited.template.yml は Docker 設定から削除し、代わりに外側の nginx インスタンスでレート制限を設定する必要があります。
いいえ、Discourse はコンテナ外部で Nginx を必要としません。
Nginx はすでにコンテナ内部に存在し、自動的に設定されます。標準的なインストール手順に従っていれば、ゼロタッチで動作します。
ホスト上で他のサービスを実行していない場合、外部の Nginx インスタンスは全く不要です。
申し訳ありませんが、20 分以上もアプリの再構築に時間がかかり、オフラインページも用意されていないのは、トラフィックの多いサイトにおいては良い慣行だとは思えません。
ダウンタイムを伴う手動のリビルドは、年に1〜2回発生します。/admin/upgrade を介してアップグレードを行う場合、アップグレードはシームレスに行われます。
2コンテナ構成でのインストールにより、リビルド時間を大幅に短縮できます。nginx を使用しているかどうかに関わらず、この構成を検討することをお勧めします。
2コンテナ構成のインストールは良さそうですね。ただ、こちらのフォーラムではそのドキュメントが見つかりません 
..
いいえ、そうではありません。可能ではありますが、標準的な推奨事項ではありません。
こちらがガイドです。
再構築時のダウンタイムが主な懸念であれば、これが最善策です。セットアップのサポートが必要な場合は、Marketplace の誰かがお手伝いできます。