Proxy Protocol導入時に必ずハマる罠（通信断・誤判定の正体）

URLをコピーしました！

ロードバランサ（LB）配下でクライアントIPを保持するために、

「Proxy Protocolを有効にしました」

──その直後から、

通信できなくなった
アプリが応答しない
ログが壊れた

というトラブルに直面するケースは非常に多いです。

Proxy Protocolは便利ですが、

「理解せずに入れると確実に事故る仕組み」

でもあります。

本記事では、

Proxy Protocolの正体
必ずハマる典型的な罠
判断基準と正しい解決方法

を、実務視点で丁寧に解説します。

そもそもProxy Protocolとは何か

Proxy Protocolは、

TCP接続の最初に「送信元IP情報」を追加で流す仕組み

です。

通信イメージ

[Proxy Protocol Header][通常のTCPデータ]

このヘッダには、

クライアントIP
クライアントPort
サーバIP

が含まれます。

重要なのは、

これはTCPの標準仕様ではない

という点です。

罠①：サーバ側がProxy Protocolを理解していない

最も多く、最も致命的な罠です。

LBでProxy Protocolを有効にすると、

サーバは「見たことのないデータ」を最初に受け取ります。

起きる現象

HTTPサーバがリクエストを解釈できない
アプリが即切断

判断基準

LBだけでProxy ProtocolをONにした
サーバ設定は何も変えていない

解決方法

サーバ（nginx / apache / アプリ）がProxy Protocol対応か確認
対応設定を必ず有効化

罠②：対応している「つもり」になっている

Proxy Protocolは、

「対応しているソフト」でも設定しないと無効

です。

典型例（nginx）

listen proxy_protocol を書いていない
real_ip_header を設定していない

この場合、

IPは受け取っているが使われていない

状態になります。

判断基準

通信はできるがIPがLBのまま

解決方法

listen xxx proxy_protocol;
real_ip_header proxy_protocol;

罠③：Proxy Protocol v1 / v2 の不一致

Proxy Protocolには、

v1（テキスト）
v2（バイナリ）

の2種類があります。

LBとサーバでバージョンがズレると、

即通信不能

になります。

判断基準

導入後すぐ通信不可
エラーログが意味不明

解決方法

LBとサーバでバージョンを明示的に合わせる

罠④：Proxy Protocolが不要な通信にも適用されている

LB全体でProxy Protocolを有効にすると、

本来不要なポートにも影響

します。

典型例

ヘルスチェック
管理ポート

これらが壊れると、

LBが「サーバ異常」と誤判定

します。

解決方法

Proxy Protocolを適用するポートを限定

tcpdumpでの即席確認方法

Proxy Protocolが流れているかは、

tcpdump -A port <port>

で確認できます。

v1なら「PROXY TCP4」という文字列が見えます。

Proxy Protocolを使うべき判断基準

HTTP以外のプロトコル
送信元IPが必須
SNATありLB構成

これに当てはまらないなら、

X-Forwarded-Forの方が安全

です。

まとめ（必ず守るべきポイント）

LBとサーバは「必ずセット」で設定
対応しているかではなく「設定されているか」を確認
v1 / v2 の不一致に注意
不要な通信には適用しない

Proxy Protocolは、

正しく使えば強力、雑に使うと破壊的

な仕組みです。

「なぜ壊れるか」を理解した上で導入すれば、

怖いものではありません。