プロキシとロードバランサ

プロキシ＝通信の代理人

クライアントとサーバの間に立ち、通信をいったん受け取って、代わりに転送するのがプロキシ（代理サーバ）です。直接つながずに1段挟むことで、次のようなことができます。

隠す：本当の送信元（または送信先）のIPを相手から見えなくする
まとめる：複数の通信を1か所に集約して、ログ・認証・フィルタを一括で適用する
キャッシュする：同じ内容を何度も取りに行かず、手前で使い回す

ポイントは「どちら側の代理をしているか」。これでフォワードとリバースに分かれます。

フォワードプロキシとリバースプロキシ

観点	フォワードプロキシ	リバースプロキシ
代理する相手	クライアント（送信する側）	サーバ（受ける側）
立ち位置	クライアントの“出口”に置く	サーバの“入口”に置く
隠すもの	クライアントのIP・素性	サーバの構成・台数・素性
誰が意識する？	クライアント側が設定して使う	クライアントは存在に気づかない
主な用途	社内からの外向き通信の制御・フィルタ	負荷分散・TLS終端・キャッシュ
代表例	社内プロキシ, SOCKSプロキシ	Nginx, ALB, CDNのエッジ

同じ「中継」でも向きが逆だと覚えると整理しやすいです。フォワードは「内→外を見張る」、リバースは「外→内を受け止める」。

“匿名プロキシ＝安全”ではない

フォワードプロキシを通すと相手から自分のIPは隠れますが、プロキシ運営者には全通信が見えます。HTTPS でも、プロキシでTLSを終端する構成（社内の検査プロキシ等）なら中身が読まれます。匿名化と暗号化は別物です。

リバースプロキシで何ができる？

サーバの「入口」に1枚かませると、アプリ本体を触らずに共通機能を足せます。

TLS終端：HTTPSの暗号化/復号をここで処理し、内側はHTTPで軽くする
ルーティング：パスやホスト名で振り先を変える（/api はAPIサーバへ、等）
キャッシュ / 圧縮：静的ファイルを手前で返す、gzip/brotli をかける
集約：認証・レート制限・アクセスログを1か所に寄せる
負荷分散：複数のサーバへ振り分ける ← これに特化したのがロードバランサ

つまりロードバランサはリバースプロキシの一種（振り分け機能を主役にしたもの）であり、両者はきれいに分かれる別物ではなく役割の重なりだと捉えると正確です。

ロードバランサ：L4 と L7

ロードバランサは「OSI参照モデルのどの層を見て振り分けるか」で性格が大きく変わります（/network/osi/ も参照）。

観点	L4（トランスポート層）	L7（アプリケーション層）
見る情報	IPアドレスとポート番号	HTTPのパス・ヘッダ・Cookie・ホスト名
中身の理解	中身は見ない（素通し）	リクエストの中身を解釈する
できる振り分け	接続単位でサーバへ転送	URLパスやホストで振り先を変える
TLS	基本そのまま通す（終端しない）	終端してヘッダを読める
速さ / 負荷	高速・低オーバーヘッド	やや重いが高機能
代表例	AWS NLB, LVS	AWS ALB, Nginx, Envoy

ざっくり言えば、L4は「速いが何も分からない」、L7は「賢いが少し重い」。/images だけ別サーバに送る、といったHTTPの中身に基づく振り分けは L7 でないとできません。

L4とL7は排他じゃない

実運用では「外側にL4（NLB）でまず受けて、内側にL7（ALBやNginx）でルーティング」のように段重ねにすることがよくあります。どちらか一方を選ぶ、という話ではありません。

分散アルゴリズム

「どのサーバに振るか」の決め方にもいくつか定石があります。

方式	決め方	向いている場面
ラウンドロビン	順番に1台ずつ均等に回す	各サーバが同じ性能・同じ重さの処理
重み付きラウンドロビン	性能差に応じて配分比を変える	サーバのスペックがまちまち
最少コネクション	今いちばん接続が少ない台へ	処理時間にばらつきがある
IPハッシュ	送信元IPから振り先を固定	同じ人を毎回同じ台に寄せたい

セッション固定（スティッキー）は諸刃の剣

ログイン状態などをサーバのメモリに持つと、同じ人を毎回同じ台へ送る必要が出ます（セッションアフィニティ）。手軽ですが、その台が落ちるとセッションごと消え、負荷も偏ります。本来はセッションを外部（Redis等）に逃がしてどの台でも処理できる作りが望ましいです。

ヘルスチェックという生命線

ロードバランサは、振り分け先が生きているかを定期的に確認しています。これがヘルスチェックです。

L4のヘルスチェック：TCPで接続できるか（ポートが開いているか）程度
L7のヘルスチェック：/healthz などに HTTPリクエストを投げ、200が返るかまで確認

応答しない台は振り分け対象から自動的に外し、復活したら戻します。これがあるおかげで、1台落ちてもユーザーには（ほぼ）気づかれずに済みます。

“浅い”ヘルスチェックの落とし穴

「ポートが開いている＝正常」とは限りません。プロセスは生きているがDB接続が切れて全リクエストがエラー、というケースをTCPチェックは検知できません。アプリの実依存まで確認するL7の中身のあるヘルスチェックを用意しておくのが安全です。逆に、チェック先で重い処理を呼びすぎてヘルスチェック自体がサーバを圧迫する例もあるので、軽く保つこと。

つまずきポイント

「プロキシ」と聞いてどちらか曖昧になる：誰の代理かで判断。利用者が設定するなら大体フォワード、利用者が気づかないなら大体リバース
ロードバランサ＝ただの分散装置と思いがちだが、実体はリバースプロキシ。TLS終端やルーティングも担えることが多い
L4でやろうとして詰む：パスやCookieで振り分けたいのにL4を選ぶと不可能。中身を見たいなら L7
クライアントの本当のIPが消える：リバースプロキシを通すとサーバから見える送信元はLBのIPになる。元IPは X-Forwarded-For ヘッダで引き継ぐ（/network/http/ 参照）

ハンズオン

Nginx を最小構成のリバースプロキシ兼ロードバランサにする例です。

# 2台のアプリサーバへラウンドロビンで振り分ける
upstream app_backend {
    # least_conn;  # 最少コネクション方式にしたい場合はこの行を有効化
    server 10.0.0.11:8080;
    server 10.0.0.12:8080 weight=2;   # こちらは2倍の重み
}

server {
    listen 443 ssl;
    server_name example.com;

    # ここでTLSを終端（HTTPS → 内側はHTTP）
    ssl_certificate     /etc/nginx/certs/example.crt;
    ssl_certificate_key /etc/nginx/certs/example.key;

    location / {
        proxy_pass http://app_backend;
        # 本当のクライアントIPを引き継ぐ
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host            $host;
    }
}

# 設定の文法チェック → 反映（無停止リロード）
nginx -t && nginx -s reload

# 振り分けやTLS終端が効いているか確認
curl -I https://example.com/