ロードバランサ配下で戻り通信が消える典型パターンと切り分け方法

ロードバランサ（LB）配下のシステムで、次のような現象に遭遇したことはないでしょうか。

• クライアントからの通信はLBに届いている
• バックエンドサーバにも到達している
• しかし、レスポンスが返ってこない

このとき多くの現場で言われるのが、

「ルーティングは問題ない」「LBも正常」

──それでも通信は成立しません。

本記事では、ロードバランサ配下で戻り通信が消える“構造的な原因”を整理し、

• どの状態ならNGなのか
• どこを見れば判断できるのか
• どうすれば正しく解決なのか

を実務視点で解説します。

まず結論：LB配下の通信は「対称性」が崩れやすい

ロードバランサ配下では、

通信の行きと戻りが「同じ経路・同じ状態」であること

が前提です。

これが崩れると、

• FW
• LB
• OS

のいずれかで、戻り通信は破棄されます。

典型パターン①：バックエンドから直接戻している

最も多いパターンです。

構成例

Client → LB → Server
Client ← Server（LBを経由しない）

この場合、クライアントは

「通信していない相手」からの応答

を受け取ることになります。

判断基準

• ServerのデフォルトGWがLBではない
• tcpdumpでServer→Clientが直接出ている

解決方法

• バックエンドの戻り経路を必ずLB経由にする
• デフォルトGWをLB向きに修正

典型パターン②：SNAT/DNATの認識ズレ

LBがNATを行う構成では、

サーバが「誰と通信していると思っているか」

が非常に重要です。

よくある誤解

• クライアントIPが見えている前提でACLを書く
• 実際はLBのIPで到達している

判断基準

• Server側で見える送信元IPは何か
• LBでSNATが有効か

解決方法

• LBのNAT設計を整理する
• 必要ならProxy ProtocolやX-Forwarded-Forを利用

典型パターン③：セッション維持（スティッキー）が崩れている

LB配下では、

同一通信が同一サーバに届く

ことが前提になるケースがあります。

症状

• 初回は通る
• 途中から応答が返らない

判断基準

• LBでセッション保持が無効
• バックエンドが複数台

解決方法

• スティッキーセッションの有効化
• アプリをステートレス化

典型パターン④：FWが「想定外の戻り通信」と判断している

LB配下ではFW視点で、

非対称通信に見える

ことがあります。

判断基準

• FWセッションテーブルに存在しない
• 片方向のみログが出る

解決方法

• 経路を対称にする
• FWをバイパスしない設計にする

tcpdumpでの実践的な確認方法

以下の2点を必ず確認します。

① Serverでの確認

tcpdump -n host <client_ip>

戻り通信が出ているか。

② LBでの確認

tcpdump -n host <server_ip>

戻り通信がLBを通過しているか。

切り分け思考まとめ

• LB配下では「戻り経路」が最重要
• NATとセッションを必ず疑う
• tcpdumpは「どこで消えたか」を見る

ロードバランサ配下での通信トラブルは、

個々の機器ではなく「構造」を見る

ことで一気に解決に近づきます。