確かに、これは少し試行錯誤が必要でしたが、以下のように動作させることができました（これが最善の方法である保証はありません。実際、より良い方法があることは確信しています。そのため、修正や改善のご提案を大歓迎します）：
pfaffman さんが OP に移動させた手順
まず、Discourse インスタンスにアクセスする方法は 2 つあります。1. ポートを公開する、2. WebSocket を通じてアクセスする。このフォーラムのどこかで、WebSocket の方が高速で効率的であると学んだため、私はこれを使用していますが、ポートを公開する方がはるかに簡単です。したがって、ソケットが動作しない場合は、ポートを公開してみてください（詳細は後述します）。
まず、30 分の標準インストールを完了したと仮定します。また、リバースプロキシを使用する場合は、Discourse が Let’s Encrypt の証明書を取得する必要がないため、まだ取得していないと仮定します。NPM がそれを処理します。ただし、すでに証明書を持っている場合でも問題ありません。NPM は単に新しいものを取得します。
1. NPM のインストール
次のステップは、NPMをインストールすることです。これにより、NPM とそのデータベースコンテナの 2 つの追加 Docker コンテナが実行されるようになります。
次に、あなたが尋ねている難しい部分です。
最初の障害は、Discourse がデフォルトの Docker bridge ネットワーク上で実行されているのに対し、NPM はデフォルトで「ユーザー作成ネットワーク」（私の場合は npm_default と呼ばれます）上で実行されるため、NPM は Discourse を見ることができないという点です。
2. すべてのコンテナをデフォルトの bridge ネットワークに移動させる
Discourse をカスタムネットワークに移動できるかどうか、またその方法がわからない限り、NPM をデフォルトの bridge ネットワークに移動させる必要があります。これは、docker compose ファイル内の両方の NPM コンテナに network_mode: bridge を追加することで実現できます。
3. サービス名ではなく IP アドレスを使用する
次の問題は、単に bridge ネットワークに移動させただけでは、標準の docker compose ファイルが機能しなくなるという点です。NPM はデータベースコンテナを見つけられなくなります。これは、サービス名の内部 DNS 解決（docker-compose ファイルが依存しているもの）はユーザー作成ネットワークでのみ利用可能で、デフォルトの Docker ネットワークでは利用できないためです。そのため、ハードコードされた IP アドレスに頼る必要があります（コンテナの IP が変更された場合に機能しなくなるため、これは明らかに最適な解決策ではありません）。したがって、コンテナが機能しないことを知っていても起動し、NPM データベースコンテナの IP を確認してから、docker compose ファイル内の DB_MYSQL_HOST: "db" を DB_MYSQL_HOST: "<db_container_IP>" に置き換える必要があります。
これで、すべてのコンテナがデフォルトの bridge ネットワーク上にあり、NPM が Discourse とそのデータベースの両方を見られるようになります。
4. Discourse にアクセス可能にする
しかし、「Discourse を見る」ことと「アクセスできる」ことは同じではありません。したがって、NPM が転送するトラフィックを Discourse が受け入れるようにする必要があります。WebSocket を使用することにこだわらない場合、NPM を Discourse コンテナの IP のポート 80（443 ではない）に指すだけでよいでしょう。以下のように：
ただし、これはテストしていません。前述の通り、私は WebSocket 設定を使用しており、それにはさらにいくつかのステップが必要です。上記のホスト名/IP とポートは、WebSocket を使用する場合無視されます。
5. app.yml を設定して WebSocket を使用する
これはOP で説明されていますので、ここでは詳しく説明しません。
6. NPM コンテナに WebSocket をマウントする
NPM に WebSocket へのアクセス権を与えるために、これをボリュームとしてマウントする必要があります：- /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock。これがデフォルトの NPM docker compose ファイルへの最終的な変更です。以下が私にとって動作する最終バージョンです：
version: '3'
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: unless-stopped
network_mode: bridge
ports:
- '80:80'
- '81:81'
- '443:443'
environment:
DB_MYSQL_HOST: "172.17.0.6"
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "my-super-safe-pwd"
DB_MYSQL_NAME: "npm"
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
- /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock
db:
image: 'jc21/mariadb-aria:latest'
restart: unless-stopped
network_mode: bridge
environment:
MYSQL_ROOT_PASSWORD: 'my-super-safe-pwd'
MYSQL_DATABASE: 'npm'
MYSQL_USER: 'npm'
MYSQL_PASSWORD: 'my-super-safe-pwd'
volumes:
- ./data/mysql:/var/lib/mysql
7. NPM で WebSocket を使用するように設定する
最後のステップ：NPM に WebSocket を使用するように指示します。私の記憶では、「WebSocket サポート」をオンにするだけでは不十分だったため、OP からの NGINX 位置設定を「高度」タブにコピーしました。以下のように：
「カスタム場所」タブでは動作しませんでした。
8. SSL のアクティベーションを忘れないこと
NPM での SSL 設定については言及していません。それは非常に自明であるように思えるからです。また、プロセスのどの時点でアクティベートしても問題ないと思います。まだ行っていない場合は、私の設定は以下のようになります：
9. 最終的な免責事項
この投稿を書いている途中で、WebSocket を使用する際、NPM と Discourse は必ずしも同じ Docker ネットワーク上にいる必要はないのではないかという思いがふと浮かびました。現時点でこれを確認する時間はありませんが、もしこれが真実であれば、上記のステップ 2、3、4 を忘れるだけで動作するはずです。
サポートフォーラムの最も魅力的な側面は、問題をよく説明することで、質問を投稿しなくても解決策にたどり着くことがあるという点です。この場合、私は他の人の質問に答えつつ、自分自身の質問に対する答えも発見したかもしれません。