リバースプロキシ & エッジサーバー 2026 完全ガイド - nginx · Caddy · Traefik · HAProxy · Envoy · OpenResty · Pingora · FrankenPHP 徹底解剖

プロローグ — なぜリバースプロキシはインフラの心臓か

2026年、新卒バックエンドエンジニアが最初に抱く疑問：「Node.js を 3000 ポートで立ち上げるだけじゃダメなの？なぜ前段に nginx を置く必要があるの？」

3か月後の現実：TLS 証明書が期限切れになったがコードを再デプロイしないと更新できない、トラフィックが 3 倍になって Node 一台では捌けない、誰かが 1 秒に 1 万リクエスト叩いてきても止める手段がない、静的ファイル配信で Node の CPU が 80%、新マイクロサービスを追加するたび DNS レコードを増やす必要がある。

これらすべての答えが リバースプロキシ(reverse proxy) である。クライアントとアプリケーションサーバーの間に挟まり、TLS 終端・ロードバランシング・キャッシュ・認証・レートリミット・可観測性をすべて担う インフラの心臓 だ。

本記事は 2026年5月時点でのリバースプロキシとエッジサーバーのフルスタックを解剖する。nginx 1.27（F5）と freenginx フォーク騒動、Caddy 2.8 の自動 HTTPS、Traefik 3 の動的ルーティング、HAProxy 3.x の L4/L7、Envoy 1.32 サービスメッシュデータプレーン、OpenResty Lua、Cloudflare Pingora の Rust リライト、FrankenPHP、K8s Ingress と Gateway API、Cloudflare Workers・Fastly Compute@Edge・Vercel Edge・Netlify Edge・Lambda@Edge・CloudFront Functions のエッジランタイムまで。

1章 · リバースプロキシとは何か — 5 つの中核責務

リバースプロキシは、クライアントが直接バックエンドに到達しないようにする中間層 である。クライアント側に立つ forward proxy と反対方向なので「リバース」と呼ばれる。

中核責務は 5 つ。

• ロードバランシング(load balancing). 同一アプリの N インスタンスにトラフィックを分散。ラウンドロビン・最小コネクション・IP ハッシュ・一貫性ハッシュ。
• TLS 終端(TLS termination). HTTPS をプロキシで復号し、内側は平文 HTTP で通信。証明書管理が一箇所に集約。
• キャッシュ(caching). 静的ファイルや HTTP レスポンスをメモリ・ディスクに保存。バックエンド負荷を 90% カットできる。
• 認証・認可(auth). OAuth、JWT 検証、mTLS、IP 許可リスト。アプリは毎リクエストで再検証しなくて済む。
• レートリミット・WAF(rate limit · WAF). 「1 秒に 100 回以上は拒否」、「SQL インジェクションパターンを検知」。第一防衛線。

これに 可観測性(observability) — 全リクエストのログ収集、Prometheus メトリクス公開 — が加わる。2026年のリバースプロキシは単なるルーターではなく L7 セキュリティゲートウェイ兼可観測性ハブ である。

2章 · 市場マップ — 8 つの陣営

2026年のリバースプロキシ・エッジ市場を俯瞰すると 8 陣営になる。

1. nginx 陣営. nginx 1.27（F5 Networks）、nginx Plus、freenginx（Maxim Dounin のフォーク）、OpenResty（nginx + Lua）。市場 1 位、最古参のベテラン。

2. Caddy 陣営. Caddy 2.8+（Matt Holt）。自動 HTTPS、Go で記述。FrankenPHP（Kévin Dunglas）が Caddy 上に PHP ランタイムを統合。

3. Traefik 陣営. Traefik 3.x（TraefikLabs）。Docker · K8s ネイティブ、動的 config、プラグイン。

4. HAProxy 陣営. HAProxy 3.x（Willy Tarreau）。L4/L7 ロードバランサー、最速の TCP 処理。

5. Envoy 陣営. Envoy Proxy 1.32（CNCF、Lyft 起源）。Istio · Linkerd2 · Consul Connect のデータプレーン。Envoy Gateway · Contour が K8s ゲートウェイ。

6. Rust 新興. Cloudflare Pingora（2024年オープンソース化）、Sozu、Hyper（ライブラリ）。メモリ安全性と性能。

7. エッジサーバーレス. Cloudflare Workers · Fastly Compute@Edge · Vercel Edge · Netlify Edge Functions · Lambda@Edge · CloudFront Functions · Akamai EdgeWorkers。

8. K8s Ingress. NGINX Ingress、Traefik Ingress、Contour、Istio Gateway、Kong Ingress、HAProxy Ingress、Cilium Gateway API、Gateway API 標準。

これに加えて CDN 統合 LB（Cloudflare Load Balancer、AWS CloudFront、Akamai、Fastly、Azure Front Door、Google Cloud CDN）が別レイヤーとして存在する。

陣営を頭に入れておくと意思決定が速くなる。伝統的静的サイトは nginx、自動 TLS の小規模チームは Caddy、K8s ネイティブは Traefik · Envoy、超高速 L4 は HAProxy、グローバルエッジは Cloudflare Workers が基本マッピング。

3章 · nginx 1.27 — 市場のベテラン、F5 買収後

nginx は 2004年に Igor Sysoev が作った第 1 世代リバースプロキシ。

歴史まとめ.

• 2004: Igor Sysoev が Rambler 向けに nginx 0.1 リリース。
• 2011: Nginx, Inc. 設立。Plus（有料）リリース。
• 2019: F5 Networks が 6.7 億ドルで買収。
• 2024: Maxim Dounin（古参コア開発者）が F5 のセキュリティパッチ方針に反発して freenginx フォーク。コミュニティ分裂。
• 2025〜2026: nginx 1.27 メインラインと freenginx 1.27 が並行開発。

強み.

• 圧倒的な市場シェア — 2026年現在、全世界のウェブサイトの約 30% が nginx を使用（Apache を抜いて久しい）。
• モジュラーアーキテクチャ — 非同期イベントループ、ワーカープロセス N 個。
• 豊富なモジュール — HTTP、mail、stream（TCP/UDP）、gRPC、HTTP/3 QUIC（1.25+）。
• 巨大な文書・チュートリアル資産 — 検索して出てこないことがほぼ無い。

設定例.

upstream backend {
    least_conn;
    server app1.internal:3000 weight=3;
    server app2.internal:3000 weight=2;
    server app3.internal:3000 backup;
}

server {
    listen 443 ssl http2;
    listen 443 quic reuseport;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_http_version 1.1;
    }

    location /static/ {
        alias /var/www/static/;
        expires 1y;
    }
}

弱点. 動的設定が弱い — config ファイルを編集して nginx -s reload を叩く必要がある。本格的な動的 API は Plus（有料）のみ。モジュールはビルド時に決まる — 動的モジュール(.so) は存在するが制限的。

4章 · freenginx — Maxim Dounin のコミュニティフォーク

2024年2月、nginx 古参コア開発者の Maxim Dounin が F5 のセキュリティ脆弱性パッチ方針に反発して freenginx というフォークを立ち上げた。

主張. 「F5 は CVE 発番なしで静かにパッチを当てる方針に転換した。これはセキュリティ透明性に反する。真のオープンソースに戻るべきだ。」

現状（2026年5月）.

• freenginx 1.27 メインラインが稼働中。
• コミュニティパッチが数十件マージ済み。
• 一部ユーザー（特にセキュリティ重視の現場）が freenginx へ移行。
• ただし市場シェアは nginx メインラインが圧倒的 — freenginx は 1〜2% 程度。

選択ガイド.

• 既存 nginx ユーザー → 大きな違いはない、nginx メインライン継続。
• セキュリティ透明性重視・F5 ガバナンスに不満 → freenginx。
• エンタープライズサポートが必要 → nginx Plus（F5）。

このフォークは「オープンソースガバナンスがどう壊れうるか」のケーススタディだ。Redis-Valkey、Terraform-OpenTofu、Elasticsearch-OpenSearch と同じパターン。

5章 · Caddy 2.8 — 自動 HTTPS の革命

Caddy は 2015年に Matt Holt が始めた Go ベースのウェブサーバー。2026年5月時点で 2.8.x。

1.x 時代（2015〜2018）. 「config 1 行で自動 HTTPS」が売り。シングルバイナリ配布。

2.x（2019〜2026）. 完全書き直し。モジュラーアーキテクチャ、JSON ベースの config、プラグインシステム、REST API。

強み.

• 自動 HTTPS — Let's Encrypt と ZeroSSL を自動統合。ドメインを書くだけで証明書が自動発行・更新。
• シングルバイナリ — Go 製、依存なしの静的バイナリ。
• モジュラー — DNS プロバイダー、ストレージバックエンド、ミドルウェアをプラグインで。
• REST API — 実行時に設定を動的変更。
• HTTP/3 デフォルト — QUIC が設定不要で有効化。

Caddyfile 例.

example.com {
    reverse_proxy app1.internal:3000 app2.internal:3000 {
        lb_policy least_conn
        health_uri /health
        health_interval 10s
    }

    handle_path /static/* {
        root * /var/www/static
        file_server
    }

    encode gzip zstd
    log {
        output file /var/log/caddy/access.log
    }
}

このブロック 1 つで Let's Encrypt 証明書、HTTP/3、ロードバランシング、ヘルスチェック、圧縮、ログ取得がすべて有効化される。nginx なら 50 行以上必要。

弱点. 性能は nginx · HAProxy よりやや劣る（〜10〜20%）。Go の GC オーバーヘッドがあり、エッジケースの安定性で nginx に並ぶとまでは言われない。それでも 開発速度と運用の楽さが圧倒的 で、小規模チームが好む理由になっている。

6章 · Traefik 3 — Docker · K8s ネイティブ

Traefik は 2015年に Containous（現 TraefikLabs）が作った Go ベースのプロキシ。2026年5月時点で v3.x。

中核コンセプト「自動設定(automatic configuration)」. Docker コンテナにラベルを付ける、または K8s Ingress · CRD を作るだけで、Traefik が自動的にルーティングを追加する。config ファイルを直接書く機会がほぼない。

v3 の新機能（2024）.

• プラグインシステム安定化（Yaegi Go インタプリタ）。
• HTTP/3 GA。
• Gateway API 標準サポート（K8s Ingress 後継）。
• gRPC、TCP/UDP ルーティング強化。
• OpenTelemetry トレース統合。

Docker ラベル例.

services:
  app:
    image: myapp:latest
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`example.com`)"
      - "traefik.http.routers.app.tls=true"
      - "traefik.http.routers.app.tls.certresolver=letsencrypt"
      - "traefik.http.services.app.loadbalancer.server.port=3000"

このラベルだけで Traefik が自動でルーティングと証明書発行を処理する。K8s では IngressRoute CRD が同じ役割。

強み. Docker · K8s 環境での圧倒的な扱いやすさ、リアルタイムダッシュボード、自動 ACME、Let's Encrypt と DNS challenge 対応。

弱点. 純粋な性能は nginx · HAProxy より劣る。メモリ消費が大きめ。コンテナがない伝統的環境では魅力が薄い。

7章 · HAProxy 3.x — 最速の L4/L7 ロードバランサー

HAProxy は 2001年に Willy Tarreau が作った C ベースのロードバランサー。2026年5月時点で 3.x。

哲学. 「一つのことを本当に上手にやる」 — ロードバランシング。HTTP サーバーではなく純粋なプロキシ。静的ファイル配信なし、PHP 実行なし、TLS 終端のみ。

強み.

• L4（TCP）が圧倒的に速い — 単一ノードで秒間 100 万コネクション処理。
• L7（HTTP）も nginx 並み — ヘッダーベースルーティング、ACL、sticky session。
• 可観測性が一級市民 — Stats ページ、Prometheus exporter 内蔵。
• HTTP/2、HTTP/3、gRPC サポート（2.6+、3.x）。
• 豊富な LB アルゴリズム — roundrobin、leastconn、source、uri、url_param、hdr、random、first。

設定例.

frontend https
    bind *:443 ssl crt /etc/haproxy/certs/example.pem alpn h2,http/1.1
    bind quic4@:443 ssl crt /etc/haproxy/certs/example.pem alpn h3
    default_backend app_pool

backend app_pool
    balance leastconn
    option httpchk GET /health
    server app1 10.0.1.10:3000 check inter 2s
    server app2 10.0.1.11:3000 check inter 2s
    server app3 10.0.1.12:3000 check inter 2s backup

弱点. 静的ファイル配信、直接的な PHP/FastCGI といったフルスタック Web サーバー機能はない — 真の LB が必要な場面では HAProxy を前、nginx を後ろにするパターンが一般的。

使われている例. GitHub、Stack Overflow、Reddit、Twitter（X）、Tumblr — 高トラフィックサイト多数。

8章 · Envoy Proxy 1.32 — サービスメッシュのデータプレーン

Envoy は 2016年に Lyft が作り、2017年に CNCF に寄贈された C++ ベースのプロキシ。2026年5月時点で 1.32。

哲学. 「サービスメッシュ(service mesh)のデータプレーンになる」。単純な LB ではなく、マイクロサービス間通信のあらゆる側面を扱えるよう設計されている。

中核機能.

• xDS API — 動的設定（LDS · CDS · RDS · EDS）。control plane が push すれば Envoy が即座に反映。
• gRPC 一級市民 — gRPC ロードバランシング、トランスコーディング（REST↔gRPC）。
• 可観測性 — 詳細メトリクス、分散トレーシング（Jaeger、Zipkin、OpenTelemetry）。
• サーキットブレーカー、retry、outlier detection — マイクロサービス安定性パターンが組み込み。
• HTTP/3、mTLS、gRPC-Web、WebSocket すべて対応。

誰が Envoy を使っているか.

• Istio — K8s サービスメッシュ。全 Pod に Envoy sidecar。
• Linkerd 2 — 独自の Rust proxy（linkerd2-proxy）も使うが、一部コンポーネントは Envoy。
• Consul Connect — HashiCorp のサービスメッシュ。
• Envoy Gateway — K8s Gateway API 実装。
• Contour — VMware Tanzu（現 Broadcom）の K8s イングレス。
• AWS App Mesh — Envoy ベース。

弱点. 設定が複雑。YAML や JSON を直接書くと数百行が普通。だから通常は Istio · Envoy Gateway のような コントロールプレーン を介して扱う。

9章 · OpenResty — nginx 上の Lua フルスタック

OpenResty は Yichun Zhang（章亦春）が 2011年から作っている nginx ディストリビューション。

中核. nginx に LuaJIT を組み込んで 各リクエストで Lua コードを実行できるようにする。nginx の非同期イベントループ上で Lua の coroutine が非同期ロジックを自然に書けるようにする。

使用例.

location /api/auth {
    access_by_lua_block {
        local jwt = require "resty.jwt"
        local token = ngx.var.http_authorization
        local jwt_obj = jwt:verify("secret-key", token)
        if not jwt_obj.verified then
            ngx.status = 401
            ngx.say("Unauthorized")
            return ngx.exit(401)
        end
        ngx.req.set_header("X-User-Id", jwt_obj.payload.user_id)
    }
    proxy_pass http://backend;
}

OpenResty の上に作られた有名プロジェクト.

• Kong API Gateway — OpenResty ベース（一部 Go に書き換え中）。
• APISIX（Apache） — OpenResty ベースの API ゲートウェイ。
• 3scale（Red Hat）。
• Cloudflare の一部エッジロジック — 2024年に Pingora に移行する前まで。

強み. nginx の性能 + Lua の動的ロジック。認証、変換、ルーティング、A/B テストといったミドルウェアを高速に作れる。

弱点. Lua の学習曲線。デバッグが難しい。モノリシックな nginx ビルドなのでモジュール追加が手間。

10章 · Cloudflare Pingora — Rust リライトの野望

Pingora は Cloudflare が自社エッジ向けに作った Rust ベースのプロキシフレームワーク。2024年2月オープンソース化 されて大きな注目を集めた。

なぜ作ったか. Cloudflare は元々 nginx をエッジに使っていた。しかし：

• マルチプロセスモデル — コネクションがワーカー間で共有できない。
• メモリ安全性 — C 製ゆえセキュリティ脆弱性が継続的に発生。
• カスタムロジック追加が難しい — Lua と C モジュールで回避していた。

Cloudflare は Rust で一から書き直す方が良い と判断し、その結果が Pingora だ。

スペック（2026年5月）.

• 言語: Rust（安全性 + 性能）。
• モデル: マルチスレッド work-stealing（Tokio）。
• トラフィック: Cloudflare が 1 日 1 兆リクエスト以上 を Pingora で処理。
• CPU/メモリ: nginx 比 70% CPU、67% メモリ。
• HTTP/3、gRPC、WebSocket サポート。

オープンソース = フレームワーク. Pingora は crates として配布される。nginx のように「config を書いて実行」ではなく、Rust コードで 自分のプロキシを構築する 必要がある。

誰が使っているか（2026年）.

• Cloudflare 自身。
• Pingora ベースの OSS プロジェクト: River（開発中）、pingora-load-balancing サンプル。
• 一部の大企業が自社エッジへの導入を試行中。

弱点. 「そのまま落とせばいい」ソリューションではなく、Rust エンジニアが必要。学習曲線が急なので小規模チームには不向き。

11章 · FrankenPHP — Caddy の中に PHP ランタイム

FrankenPHP は Kévin Dunglas（Symfony コア貢献者、API Platform 創業者）が 2022年に始めたプロジェクト。2026年5月時点で 1.x 安定版。

核心アイデア. PHP-FPM をなくし、PHP インタプリタを Caddy（Go）の中に埋め込む。PHP が long-running プロセスの中で動く。

従来の PHP-FPM の問題.

• 各リクエストで PHP プロセスが新規起動（Opcache が助けても限界がある）。
• nginx → FastCGI → PHP-FPM → 再び nginx の hop が多い。
• ワーカープールチューニングが難しい。

FrankenPHP の解.

• PHP が Caddy プロセス内で long-running。
• HTTP/2、HTTP/3、WebSocket 自動。
• Worker mode — Laravel · Symfony · Drupal を octane のように long-running で実行。
• Early hints（HTTP 103）対応。
• 静的バイナリ — 1 ファイルに PHP と Web サーバー。

ベンチマーク. Symfony デモアプリで PHP-FPM 比 3.5 倍 RPS、レスポンスレイテンシ 75% 削減。

導入事例.

• API Platform 公式統合。
• Laravel Octane のワーカーオプションとして。
• Symfony 公式推奨オプションの一つ。

PHP が 2025〜2026年に再び注目を集めた理由の一つが FrankenPHP。「遅い言語」という PHP の印象を変えた。

12章 · Sozu とその他の Rust プロキシ

Rust がシステムプログラミングの次世代標準になるにつれ、リバースプロキシも複数登場した。

Sozu — CleverCloud が作った HTTP リバースプロキシ。ホットリロード(hot reload) が中核 — 設定変更でダウンタイム 0。AGPL ライセンスで一部論争。

Hyper — Rust で最も有名な HTTP ライブラリ。プロキシそのものではないが、多くの Rust プロキシの基盤。

Linkerd2-proxy — Linkerd 2 が自身のサイドカーに使う Rust プロキシ。小さくて速い。

River — Pingora 上に作られている OSS プロキシ（開発中）。

その他. Tonic（gRPC）、Tower（ミドルウェア抽象）、Hudsucker（MITM プロキシ）。

Bun の内蔵サーバー — Node 陣営だが言及する価値がある。Bun.serve() が fetch API ベースの HTTP サーバーを提供し、Express/Node http より 5〜10 倍速い。小さなマイクロサービスを nginx なしで直接公開できる水準。

13章 · K8s Ingress コントローラー — 7 つの選択肢

Kubernetes で外部トラフィックを受けるには Ingress コントローラー が必要だ。2026年は選択肢が多い。

1. NGINX Ingress Controller — K8s 公式コントローラーの一つ。nginx ベース。最も使われている。ConfigMap + annotation で設定。

2. NGINX Ingress（F5 商用） — 上とは別のコントローラー。nginx Plus ベース、動的設定。F5 が公式運営。

3. Traefik Ingress — Traefik をコントローラーに。IngressRoute CRD が魅力。

4. Contour — Envoy ベース、VMware（Broadcom）製。HTTPProxy CRD。

5. Istio Gateway — Envoy ベース、Istio コントロールプレーン。サービスメッシュまで揃うなら自然な選択。

6. Kong Ingress — Kong API ゲートウェイをコントローラーに。OpenResty ベース。

7. HAProxy Ingress — HAProxy をコントローラーに。L4 が強い。

8. Cilium Gateway API — eBPF ベースのデータプレーン。Cilium を CNI として使うなら魅力的。

選択基準：

• シンプルに始める → NGINX Ingress（CNCF 卒業、最も情報が多い）。
• サービスメッシュ統合 → Istio Gateway。
• 動的設定・プラグイン → Traefik。
• API ゲートウェイ機能 → Kong。

14章 · Gateway API — Ingress の後継

Ingress は 2015年の K8s 1.1 で導入された初の L7 ルーティング API だ。10 年が経つにつれ限界が明らかになった。

Ingress の問題.

• シンプルすぎる — ホストとパスのみ、ヘッダー・メソッドルーティング不可。
• コントローラーごとに annotation がバラバラ — nginx、traefik、contour、kong それぞれが独自方言。
• TCP/UDP ルーティング無し。
• 権限分離なし — インフラチームとアプリチームの役割分離不可。

Gateway API（SIG Network）はこれらすべての答え。2023年 GA、2026年5月時点で v1.2。

中核リソース.

• GatewayClass — どの実装を使うか（インフラチーム管轄）。
• Gateway — 実際の LB · 進入点（インフラチームが作成）。
• HTTPRoute、TCPRoute、UDPRoute、TLSRoute、GRPCRoute — ルーティング規則（アプリチームが作成）。
• ReferenceGrant — 名前空間横断参照の権限。

HTTPRoute 例.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
spec:
  parentRefs:
    - name: my-gateway
  hostnames:
    - "example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api/v1
          headers:
            - name: X-API-Version
              value: "1"
      backendRefs:
        - name: app-v1
          port: 80
          weight: 80
        - name: app-v1-canary
          port: 80
          weight: 20

実装（2026年）. Istio、Envoy Gateway、Contour、Kong、Traefik、NGINX Gateway Fabric、Cilium Gateway API。Ingress は deprecated ではないが、新規は Gateway API へ向かうのが正解.

15章 · TLS · mTLS · ACME — 証明書のエコシステム

HTTPS が標準 の時代（2018年 Chrome の「Not Secure」キャンペーン以降）になり、リバースプロキシの最大の責務は TLS 証明書管理になった。

ACME プロトコル. Let's Encrypt が作った自動証明書発行標準。HTTP-01 · DNS-01 · TLS-ALPN-01 challenge。

無料 CA（2026年）.

• Let's Encrypt — 最も使われる無料 CA。60 日の証明書。
• ZeroSSL — 90 日または 1 年（アカウント登録）。Caddy が Let's Encrypt と ZeroSSL の両方をデフォルトで試す。
• Google Trust Services — 2024年から ACME 無料発行。

証明書自動化ツール.

• Certbot — Let's Encrypt 公式クライアント。systemd timer で更新。
• acme.sh — bash で書かれた ACME クライアント。最も軽い。
• cert-manager — K8s で Issuer · Certificate CRD で自動化。事実上の標準。
• lego — Go 製、Traefik に内蔵。

プロキシ別 ACME 統合.

• Caddy — 組み込み、追加ツール不要。
• Traefik — 組み込み。
• nginx — 外部の Certbot · acme.sh。
• HAProxy — 外部の Certbot · acme.sh。
• Envoy — cert-manager または外部。

mTLS（相互 TLS）. クライアントも証明書で認証。サービスメッシュ（Istio、Linkerd）の zero-trust セキュリティモデルの中核。

プライベート CA.

• step-ca（smallstep） — 社内 CA。ACME サーバーとして動作。
• mkcert（Filippo Valsorda） — ローカル開発用の自己署名 CA。
• HashiCorp Vault PKI — エンタープライズ CA。

16章 · HTTP/3 · QUIC — UDP 上の新標準

HTTP/3 は 2022年に RFC 9114 で標準化され、2026年5月時点でグローバルトラフィックの約 30% が HTTP/3。

核心差分.

• トランスポート層 = QUIC（UDP の上） — TCP ではない。
• TLS 1.3 統合 — ハンドシェイクが 1 RTT（TCP+TLS の 3 RTT に対し）。
• Head-of-line blocking 解消 — HTTP/2 の限界を克服。
• 接続マイグレーション — モバイルが Wi-Fi から LTE に切り替わってもコネクション維持。

プロキシ別サポート（2026年5月）.

• nginx 1.25+ — QUIC 正式サポート。
• Caddy 2.6+ — 組み込み、設定不要。
• HAProxy 2.6+ — quic バインディング。
• Envoy 1.27+ — HTTP/3 listener。
• Traefik 3.x — experimental: http3: true。

クライアントサポート. Chrome 87+、Firefox 88+、Safari 14+、curl 7.66+（オプション）。事実上すべての主要ブラウザが HTTP/3 を使う。

いつ有効化するか. 2026年のグローバルサイトは無条件で有効化すべき。UDP がブロックされた環境（一部企業ファイアウォール）では自動的に HTTP/2 にフォールバックするので、デメリットはほぼない。

17章 · レートリミット — トークンバケット · スライディングウィンドウ · リーキーバケット

レートリミット(rate limiting) はリバースプロキシの中核セキュリティ機能。「1 秒に 100 回以上のリクエストは拒否」といったポリシーで DoS · スクレイピング · ブルートフォースを防ぐ。

3 つのアルゴリズム.

• トークンバケット(token bucket) — 一定速度でトークンを補充、リクエストごとにトークン消費。バーストを許容。nginx limit_req、HAProxy stick-table。
• スライディングウィンドウ(sliding window) — 直近 N 秒のリクエスト数をカウント。正確だがメモリ消費が大きい。Redis と組み合わせる。
• リーキーバケット(leaky bucket) — 一定速度で処理、超過は queue またはドロップ。nginx limit_req のデフォルト挙動。

nginx 例.

http {
    limit_req_zone $binary_remote_addr zone=api:10m rate=100r/s;

    server {
        location /api/ {
            limit_req zone=api burst=200 nodelay;
            proxy_pass http://backend;
        }
    }
}

分散レートリミット. 複数のプロキシノード間でカウントを共有するには外部ストレージが必要。Redis が標準。Cloudflare Workers · Vercel · Lambda のようなエッジでも同じ。

API ゲートウェイレベル. Kong · Traefik · APISIX がより豊富なプラグインで IP、ユーザー、API キー単位の差別化レートリミットを提供。

18章 · WAF — ModSecurity · Coraza · クラウド WAF

WAF（Web Application Firewall） は SQL injection · XSS · path traversal · RCE といった L7 攻撃をパターンマッチで防ぐ。

ModSecurity — 2002年に始まったオープンソース WAF。Apache モジュールで始まり、nginx と IIS に拡張。OWASP Core Rule Set（CRS） が標準ルールセット。ただし 2024年に Trustwave が ModSecurity の管理を OWASP に移管し、将来は若干不確実。

Coraza — Go で書かれた ModSecurity の代替。OWASP が直接サポートし、Caddy · Traefik · Envoy と統合。2026年の新規プロジェクトは Coraza 推奨。

クラウド WAF（SaaS）.

• Cloudflare WAF — 最大のグローバルシェア、OWASP CRS + ML ルール。
• AWS WAF — CloudFront · ALB · API Gateway と統合。
• Azure WAF — Front Door · App Gateway と統合。
• Google Cloud Armor — Cloud Load Balancer と統合。
• Akamai Kona — エンタープライズ専用。
• Imperva — クラシックなエンタープライズ WAF。

韓国 WAF. AhnLab TrusGuard · WAPPLES · Penta Security Cloudbric。金融セクターのコンプライアンス要件で国内ソリューションが強い。

19章 · Cloudflare Workers — エッジサーバーレスの覇者

Cloudflare Workers は 2017年にリリースされたエッジサーバーレスランタイム。

スペック.

• ランタイム: V8 isolate（各リクエストが別 isolate で実行、cold start がほぼ 0）。
• 言語: JavaScript、TypeScript、WebAssembly、（実験的）Python。
• グローバル: 330+ 都市の PoP。
• レイテンシ: ユーザーから 50ms 以内。

Cloudflare のフルスタック（2026年）.

• Workers — コンピュート。
• R2 — オブジェクトストレージ（S3 互換、egress 無料）。
• D1 — SQLite ベースの分散 DB。
• KV — グローバル key-value ストア。
• Durable Objects — 状態を持つ単一インスタンス。
• Queues — メッセージキュー。
• Hyperdrive — 外部 Postgres のキャッシュ。
• Cloudflare Tunnel（cloudflared） — 内部サーバーをエッジ経由で公開、IP は秘匿。

Workers 例.

export default {
  async fetch(request: Request, env: Env) {
    const url = new URL(request.url)
    if (url.pathname === '/api/hello') {
      return Response.json({ greeting: 'hello world', region: request.cf.colo })
    }
    return fetch(request)
  },
}

なぜ強いのか. エッジコンピュートの標準になった。Vercel · Netlify も似たモデルだが、Cloudflare の規模と価格競争力が圧倒的。

20章 · Vercel · Netlify · Fastly · AWS · Azure エッジ比較

Vercel Edge Functions / Middleware. Cloudflare Workers の上に構築（実際のインフラ）。Next.js · SvelteKit · Astro と深く統合。Edge Runtime は V8 isolate。

Netlify Edge Functions. Deno ランタイムベース。Deno Deploy インフラ上で動作。JSR · npm 両方対応。

Fastly Compute@Edge. WebAssembly ベース — Rust、AssemblyScript、Go（JS）でコード作成。cold start 0.1ms 未満。セキュリティ隔離が強力。

AWS Lambda@Edge. CloudFront と統合される Lambda。Node.js、Python。cold start 100〜500ms（他のエッジに比べ遅い）。

CloudFront Functions. Lambda@Edge より軽量版。ms 単位で実行、JS のみ。URL 書き換え、ヘッダー操作などの単純作業。

Akamai EdgeWorkers. JavaScript ランタイム、300+ PoP。エンタープライズ価格。

Azure Front Door + Azure CDN + Azure Static Web Apps。

Google Cloud CDN + Cloud Load Balancer + Cloud Run（厳密にはエッジではない）。

比較マトリクス：

選択ガイド. Next.js なら Vercel、フルスタックエッジデータまで必要なら Cloudflare、AWS ロックインなら CloudFront Functions、セキュリティ隔離・WASM 必要なら Fastly。

21章 · 開発用トンネル — Cloudflare Tunnel · ngrok · Tailscale Funnel · Pinggy

ローカルマシンで動かしているサーバーをインターネットに公開するには トンネル ツールが必須だ。

Cloudflare Tunnel（cloudflared）. Cloudflare が運用する無料トンネル。ローカルに cloudflared デーモンを立てドメインをマッピング。IP は非公開。本番でも使える安定性。

ngrok. 最古参のトンネル SaaS。無料プランはランダムドメイン、有料は固定ドメイン。月 1GB 無料。デモ · webhook テストの定番。

Tailscale Funnel. Tailscale の新機能。tailnet 内のノードをインターネット公開。Tailscale ユーザーなら無料。

Pinggy — インドのスタートアップ、ngrok の代替。SSH 1 行でトンネル。

localtunnel · serveo — 無料 OSS の代替、安定性は劣る。

用途.

• ローカル開発サーバーのデモ → ngrok · cloudflared。
• webhook テスト（Stripe、GitHub、Slack） → ngrok が定番。
• 社内システムを外部公開 → Cloudflare Tunnel（本番グレード）。
• 一時的な SSH → Tailscale Funnel。

22章 · API ゲートウェイ — 隣接カテゴリ

API ゲートウェイ はリバースプロキシの上位カテゴリ — L7 ルーティング + 認証 + レートリミット + 変換 + 分析。2026年の主要選択肢。

Kong Gateway. OpenResty ベース（一部 Go に移行中）。最大のプラグインエコシステム。OSS 無料、Enterprise 有料。

Tyk. Go ベース、オープンソース。Kong の競合。

KrakenD. Go ベース、宣言的 config、非常に高速。レスポンス aggregation が強み。

APISIX（Apache）. OpenResty ベース、Kong の OSS 代替。etcd がストレージ。

Express Gateway. Node.js ベース、小規模チーム向け。

Gravitee · WSO2. エンタープライズ、API 管理 + ゲートウェイ。

クラウドネイティブ. AWS API Gateway、Azure API Management、Google Cloud API Gateway、GCP Apigee。

リバースプロキシ vs API ゲートウェイ. 境界は曖昧。Traefik · Envoy は両方可能。Kong · Tyk は API ゲートウェイ寄り。本質的な差異は 開発者ポータル · ビリング · 分析 といった API 管理機能の有無。

23章 · 可観測性 — Prometheus · OpenTelemetry · アクセスログ

リバースプロキシは 全トラフィックが通る地点 なので可観測性のゴールデンポジションだ。

メトリクス（Prometheus）.

• nginx — 外部の nginx-prometheus-exporter、Plus は組み込み。
• Caddy — 組み込みの /metrics エンドポイント。
• Traefik — 組み込み。
• HAProxy — 組み込みまたは haproxy_exporter。
• Envoy — 組み込み、statsd · Prometheus 両方。

重要メトリクス.

• requests per second
• latency p50, p95, p99
• error rate（5xx, 4xx）
• upstream health（active connections, queued, failed）
• TLS handshake duration

トレース（OpenTelemetry）. Envoy · Traefik は OTel 組み込み。nginx は nginx-otel モジュール（1.24+）。分散トレースはマイクロサービスデバッグの標準。

アクセスログ. 全リクエストを JSON で記録。ELK · Loki · Grafana で分析。アクセスログはセキュリティインシデントのフォレンジックにも必須。

24章 · 韓日採用事例 — クラウド LB と WAF

韓国.

• NAVER Cloud Load Balancer — ALB · NLB · CLB ラインナップ。Envoy と nginx ベース。
• Kakao Cloud Load Balancer — 同様のラインナップ。
• NHN Cloud Load Balancer — Toss Payments などフィンテック多数。
• AhnLab TrusGuard WAF · WAPPLES · Penta Security Cloudbric — 金融セクター WAF の事実上の標準。
• NAVER · Kakao · Coupang 自社エッジ — 内部で nginx/OpenResty/Envoy の組み合わせを使用。

日本.

• NTT Communications Smart Data Platform — LB · CDN。
• SAKURA Internet — VPS · クラウド LB。
• IIJ GIO — エンタープライズクラウド LB。
• ConoHa — 個人 · 中小企業。
• AWS 東京 · 大阪リージョン — 日本企業の 80% が AWS を使用。CloudFront + ALB が標準。
• メルカリ · LINE · 楽天の自社エッジ — Envoy · Istio ベースのサービスメッシュ。

規制. 韓国は K-ISMS、日本は ISMS-AC と PCI-DSS。いずれも WAF · TLS 1.2 以上 · アクセスログ保持（1 年以上）を要求。

25章 · 意思決定マトリックス — どのプロキシを選ぶか

状況別推奨.

• シングルマシン、小規模チーム、PHP または静的サイト → nginx または Caddy。Caddy のほうが楽。
• Docker · K8s、自動化優先 → Traefik または NGINX Ingress。
• マイクロサービス + サービスメッシュ → Envoy（Istio または Envoy Gateway と一緒に）。
• L4 超高性能（DB プロキシ、TCP ルーティング） → HAProxy または Envoy。
• PHP フルスタック（Laravel、Symfony） → FrankenPHP。
• グローバルエッジコンピュート → Cloudflare Workers + R2。
• AWS ロックインエッジ → CloudFront + Lambda@Edge。
• Next.js · SvelteKit フルスタック → Vercel Edge。
• 社内システムの外部公開 → Cloudflare Tunnel。
• API ゲートウェイ（開発者ポータル、ビリング） → Kong または Apigee。
• レガシー nginx 安定運用 → freenginx または nginx メインライン。
• Rust エンジニア在籍、超高性能カスタム → Pingora。

アンチパターン.

• 「Caddy は自動 HTTPS なのですべての面で nginx より優れている」 — 性能とモジュールエコシステムは nginx が先行。
• 「Envoy が最強なのですべて Envoy で」 — 設定複雑度、小規模チームには負荷が大きすぎる。
• 「Cloudflare Workers だけ使えばインフラ完了」 — ロックイン、デバッグ難、価格スケール注意。

26章 · References — 公式ドキュメントと良質な記事

• nginx 公式ドキュメント
• freenginx
• Caddy 公式ドキュメント
• Traefik 公式ドキュメント
• HAProxy 公式ドキュメント
• Envoy Proxy 公式ドキュメント
• OpenResty 公式
• Cloudflare Pingora 発表（2024）
• FrankenPHP 公式
• Sozu 公式
• Kubernetes Gateway API
• NGINX Ingress Controller
• Istio 公式
• Linkerd 公式
• Let's Encrypt
• cert-manager
• step-ca（smallstep）
• OWASP ModSecurity Core Rule Set
• Coraza WAF
• HTTP/3 RFC 9114
• Cloudflare Workers 公式
• Fastly Compute@Edge
• Vercel Edge Functions
• Netlify Edge Functions
• AWS Lambda@Edge 公式
• Kong Gateway 公式
• Apache APISIX
• Tailscale Funnel
• ngrok