そのコミットは、あなたが依存していた設定エラーを修正しましたが、同時にエンドユーザーがそのヘッダーを設定してIPアドレスをスプーフィングすることを可能にしたかもしれません。
他の何ものもあなたのコンテナにアクセスできないと確信している場合、ソケットを使用しないより簡単な方法があります。私はちょうど書きましたこの方法についてのガイドです。
@CLOUD_PHTのセットアップの場合、コンテナ定義にこれを追加する必要があります（runセクションが既に存在する場合は、これらのディレクティブを追加し、そうでなければrunセクションを追加します）：
run:
- file:
path: /etc/nginx/conf.d/outlets/server/real-ip-header.conf
chmod: 644
contents: |
real_ip_header x-forwarded-for;
- file:
path: /etc/nginx/conf.d/outlets/server/set-real-ip-from-host.conf
chmod: 644
contents: |
set_real_ip_from 172.17.0.1;
また、以下も必要になるかもしれません：
- file:
# ホストとCloudFlareから少なくとも2つのエントリがあるため、再帰を有効にする必要があります
path: /etc/nginx/conf.d/outlets/server/real-ip-recursive.conf
chmod: 644
contents: |
real_ip_recursive on;
サーバー上で実行されているnginxが、エンドユーザーの実際のIPを決定するためにCloudflareのヘッダーを処理しているか（推奨）、それとも単にそれ自体のものを追加しているかによって異なります。詳細は https://meta.discourse.org/t/handling-the-chain-of-trust-of-the-end-users-real-ip/406372#p-2001772-more-than-one-proxy-7 を参照してください。
他の読者: このディレクティブには注意してください
run:
- file:
path: /etc/nginx/conf.d/outlets/server/set-real-ip-from-host.conf
chmod: 644
contents: |
set_real_ip_from 172.17.0.1;
これはすべてのセットアップに適しているわけではありません。このIPからのDiscourseコンテナへの接続がすべて信頼できる場合にのみ、これを行ってください。
具体的には、IPv6セットアップで知られている問題は、サーバーへのIPv6接続がdockerによってIPv4経由で転送されることです。その方法により、すべての接続がホストのdocker0 IPアドレスから来ているように見えます。上記のディレクティブをセットアップに適用すると、IPv6で接続しているすべてのユーザーが自由にIPアドレスをスプーフィングできるようになります。