@ariznaf さん、
はい、sidekiq プロセスが追加のアバターの画像やプロフィール画像を再構築する十分な時間が経過した後も、このカスタムアバターの問題が再び発生しているのを確認しています。ただし、これは nginx を Unix ドメインソケットへのリバースプロキシとして設定した場合 のみです。
小さなアイコンのアバターは問題ありませんが、プロフィールカードやプロフィールページでは機能しません（以前にキャッシュされ、そのキャッシュがまだ有効な場合を除く）。
以下の操作を行うとすぐに、
nginx -s stop; ./launcher start web-only
カスタムアバター画像の問題は解消されます（ブラウザでまだ表示/キャッシュされていない画像の場合）。
そして、すぐに以下の操作を行うと、
./launcher stop web-only; nginx
カスタムアバター画像の問題が、まだ表示/キャッシュされていない画像に対して再び発生します。
HTTPS にエラーはなく、これは force_https のせいでもありません（全く無関係です）。
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
79 | force_https | 5 | t | 2020-04-16 05:51:13.165124 | 2020-04-16 05:51:13.165124
(1 row)
この問題は、モバイル（iOS、最新バージョン）、デスクトップ、Chrome（最新）、Safari（最新）など、すべての環境で確認されています。
nginx を Unix ソケットへのリバースプロキシとして使用すると、カスタムアバター画像に奇妙な影響が生じています。
現時点では、@ariznaf さんにお知らせするのは恐縮ですが、私たちは問題を特定できず、解決策も持っておりません。
nginx を Unix ソケットへのリバースプロキシとして設定した場合、Discourse アプリ（コンテナ）が、nginx を Unix ドメインソケットへのリバースプロキシとして使用しない設定の場合のように、これらのカスタムアバター画像を再構築していない「ように感じられます」。
もしかすると、sidekiq が nginx を Unix ソケットへのリバースプロキシとして設定 した環境を好まず、この再構築プロセスのスケジューリングや実行を拒否しているのでしょうか？（笑） @riking さん？
奇妙ですね。