このページはネットワーク配下の入口です。具体的な設定や仕組みは、下の「読む順番」またはメニューの子ページから選んでください。出口の代理、サービスの入口、負荷分散、分散配信を混同しないために比較します。

この記事の要点

プロキシ・ロードバランサ・CDN は、クライアントとサーバーの間に入って通信を中継・分散・高速化する仕組み フォワードプロキシはクライアント側の代理、リバースプロキシはサーバー側の代理で、向きが逆 ロードバランサは送り先を選んで負荷を分散する。障害時の継続には検知・残存容量・入口やデータの冗長化も必要 実装の定番は nginx と HAProxy。クラウドではマネージドの LB（ALB など）を使うことが多い CDN は分散したエッジで配信する。キャッシュするか、オリジンへ転送するかは内容・設定・鮮度による 初学者は「フォワード → リバース → ロードバランサ → CDN」の順に読むと理解しやすい

負荷分散・プロキシ・CDN とは

Webサービスでは、アプリケーションの前段にプロキシ・ロードバランサ・CDNを配置し、中継・振分け・分散配信を分担させる構成があります。すべてのサービスに全部が必要なわけではなく、TLS終端・キャッシュ・WAFも製品と設定によって利用可否が異なります。このカテゴリでは、役割の違いから個別設定へ進めます。

次は組合せの一例です。自宅からの通信に社内プロキシが必ず入るわけではなく、CDNや独立したLBを使わない構成もあります。CDNのキャッシュから返せる要求は、毎回アプリまで進むわけではありません。

ブラウザ → (社内ならフォワードプロキシ) → インターネット
        → CDN エッジ → ロードバランサ / リバースプロキシ → アプリサーバー群

それぞれの違い

種類	誰の代理か	主な用途	代表的な実装
フォワードプロキシ	クライアント	社内から外部へのアクセス制御・ログ・キャッシュ	Squid
リバースプロキシ	サーバー	TLS終端・転送。キャッシュやWAFは追加機能/設定次第	nginx、Apache
ロードバランサ	サーバー群	複数サーバーへの振り分け、ヘルスチェック	HAProxy、nginx、クラウド LB
CDN	サーバー（地理的に分散）	分散配信・キャッシュ。DDoS緩和等はサービスの提供条件次第	Cloudflare、CloudFront

リバースプロキシは公開サービスの代理として要求を受ける役割、負荷分散は送り先を選ぶ機能です。リバースプロキシが複数のupstreamへ振り分けることもあり、台数だけでは分類できません。L4のTCP/UDP分散と、HTTPのHostやpathを扱うL7の分散も区別します。nginxやHAProxyの機能範囲は対象版・module・設定によって確認します。

読む順番

1. フォワードプロキシ — 「代理で通信する」というプロキシの基本概念をつかむ
2. リバースプロキシ — 向きが逆になると何がうれしいのか（SSL 終端・隠蔽）を理解する
3. ロードバランサ — L4 と L7 の違い、ラウンドロビンなどの分散アルゴリズム、ヘルスチェック
4. nginx リバースプロキシ設定 — proxy_pass と upstream で実際に設定する
5. HAProxy — frontend / backend の考え方と設定例
6. CDN — エッジキャッシュ、TTL、キャッシュ削除（パージ）の考え方

手を動かして試したい場合は、1・2 を読んだあと 4 の nginx 設定に進むのが近道です。

目的別の選び方

• 社員のインターネット利用を制御・記録したい → フォワードプロキシ
• アプリの前で HTTPS を受けたい、アプリを直接公開したくない → リバースプロキシ（TLSとバックエンドの到達制限も設計する）
• サーバーを複数台にして負荷と障害に備えたい → ロードバランサ（自前なら HAProxy / nginx、クラウドならマネージド LB）
• 画像や JS・CSS の配信を速くしたい、海外利用者がいる → CDN
• サーバー更新後に変更が反映されない → ブラウザ/CDN/リバースプロキシ/アプリのどこが古い応答を返すか切り分ける

導入前に確認する境界

台数を増やしても無停止とは限らない

負荷分散と高可用性は同じではありません。バックエンドを増やしても、入口のLB・共通DB・共有ストレージや回線が単一障害点なら停止し得ます。故障検知までの要求、処理途中の接続、残存サーバーの容量不足も考慮します。セッションやアップロードを各アプリのローカルだけに置く構成では、送り先の変更だけで利用を継続できるとは限りません。

nginxのmax_fails / fail_timeoutは、どの失敗を何回検知して候補から外すかに関わります。通常要求で失敗を検知するpassive方式と、別の要求を定期送信するactive health checkを区別し、Open SourceとPlusの機能差も確認します。再送を広げれば解決するわけではなく、注文・決済などの二重実行を避ける設計が必要です。

HTTPSの終端と転送先の保護は別

入口でTLSを終端しても、入口からアプリまでが自動的に暗号化・認証されるわけではありません。区間ごとのTLS、証明書検証、到達可能なネットワークを設計し、バックエンドや管理画面を無制限に公開しません。プロキシを置いた事実だけでWAF・認証・アクセス制御が有効になるわけでもありません。

アプリが元の利用者IPやHTTPS判定を受け継ぐ場合も、外部から来たX-Forwarded-For等をそのまま信頼せず、信頼する中継元と付与/上書きする層を決めます。これはフォワードプロキシの利用だけで匿名性が保証される、という意味でもありません。

CDNが保存してよい内容を先に決める

画像などの共通ファイルと、ログイン後の個人情報を含む応答を分けます。URLが同じでもCookie・認証・queryで内容が変わるため、共有キャッシュの可否・キー・TTL・再検証・パージを個別に確認します。「動的だから必ず保存されない」「CDNだから全部保存される」のどちらも前提にしません。

例えばCloudflareは標準ではHTML/JSONをキャッシュしませんが、Cache Rules等で挙動が変わります。設定を変更する前に現在の応答とルールを調べます。接続が速くなるかはヒット率・オリジンまでの通信・利用者の経路等によるため、導入だけで性能向上を保証しません。

症状から調べる場所を選ぶ

• 特定の社内端末だけ接続できない：端末のプロキシ設定、名前解決、認証、出口の許可を順に確認。全通信が同じプロキシを使うとは限りません。
• 502/504になる：どの層が返したstatusか、発生時刻・接続先・接続/読取timeout・アプリ側ログを照合。番号だけでアプリ停止やLB故障と断定しません。
• 一部の要求だけログアウトする：送り先、セッション保存先、Cookieの条件、暗号鍵等の差を確認。sticky設定だけでデータや可用性が保証されるとは扱いません。
• 更新したファイルが古い：対象URLと応答ヘッダー、キャッシュ状態、オリジンの成果物を照合。全キャッシュ削除やTTL変更を初手にしません。

設定の変更・reload・遮断・パージは読取診断とは別の操作です。まず対象版と現在の構成を確認し、個別の子ページで前提を確かめてから、退避・検証・反映・切戻しの順序を決めます。

公式資料と確認範囲

補足：nginxの信頼する中継元とreal IP、passive / active health checkの違い。実装時は導入済みの版とmoduleで利用条件を確認してください。

2026年10月26日確認：MDNのプロキシと転送ヘッダー、nginxのリバースプロキシ、upstreamの障害判定、要求の再送条件、Cloudflareの標準キャッシュ挙動。本記事は役割と確認事項の案内です。個別構成の耐障害性・TLS・認証・実測性能を保証するものではなく、本番ネットワーク設定は変更していません。

関連

• Nginx 完全ガイド（リバースプロキシ・HTTP/2/3・Apache 比較・PHP-FPM 連携）
• クラウドロードバランサとは｜ALB(L7)/NLB(L4)/CLB・ターゲットグループ
• Cloudflareとは｜CDN・DNS・DDoS対策など主要機能と仕組み
• 本番サーバーでコード変更が反映されない（キャッシュ・OPcache・LB・CDN の切り分け）
• ルーター