Envoy と Nginx の比較｜設計思想・設定方式・WordPress の前段にどちらを置くか

Envoy と Nginx はどちらもリバースプロキシとして使えますが、得意分野がはっきり分かれています。結論から言うと、WordPress を1〜数台のサーバーで動かすなら Nginx が素直な選択で、コンテナ基盤やサービスメッシュで多数のサービスを動的に束ねるなら Envoy が向いています。この記事では、両者の設計思想・設定方式・運用面の違いを整理し、同じ構成を両方で書いた例を見比べながら、自分の環境でどちらを選ぶべきか判断できるようにします。

Envoy と Nginx は何が違うのか

生まれた背景と設計思想

Nginx は高速な Web サーバーとして生まれ、静的ファイル配信、PHP-FPM への FastCGI 接続、リバースプロキシ、キャッシュまでを1つのプロセスでこなします。設定ファイル（nginx.conf）を書き、リロードで反映するという、サーバー単位で完結する運用が前提です。

Envoy は Lyft 社が社内のマイクロサービス通信のために開発し、現在は CNCF（Cloud Native Computing Foundation）のプロジェクトとして開発されているプロキシです。Web サーバーではなく「サービス間通信のためのプロキシ」として設計されており、設定を API（xDS と呼ばれる仕組み）経由で外部から動的に配信できる点が最大の特徴です。Istio などのサービスメッシュでデータプレーンとして使われているのもこのためです。

機能面の違い

主な違いを比較すると次のようになります。機能の有無はバージョンや提供形態で変わるため、（2026年10月現在）の一般的な傾向として捉えてください。

Nginx のオープンソース版でもバックエンドの切り離しはできますが、max_fails と fail_timeout による「失敗したら一定時間外す」受動的な方式です。Envoy はバックエンドへ定期的にリクエストを送る能動的ヘルスチェック、異常なホストを自動で外す外れ値検出（outlier detection）、同時接続数の上限を決めるサーキットブレーカーなどを標準で持っています。

同じ構成を両方で書いてみる

違いを実感するには、同じ「受けたリクエストを WordPress のバックエンドに渡すだけ」の構成を両方で書いてみるのが早道です。ここではバックエンドを wordpress-app:80 とします。

Nginx の場合

upstream wordpress_backend {
    server wordpress-app:80 max_fails=3 fail_timeout=30s;
}

server {
    listen 8080;
    server_name example.com;

    location / {
        proxy_pass http://wordpress_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

短く読みやすいのが Nginx の強みです。Host ヘッダーを明示的に渡さないと、WordPress がバックエンドのホスト名でリダイレクトを返すといったつまずきが起きやすい点には注意が必要です。

Envoy の場合

admin:
  address:
    socket_address: { address: 127.0.0.1, port_value: 9901 }

static_resources:
  listeners:
  - name: listener_http
    address:
      socket_address: { address: 0.0.0.0, port_value: 8080 }
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: ingress_http
          use_remote_address: true
          route_config:
            name: local_route
            virtual_hosts:
            - name: wordpress
              domains: ["example.com"]
              routes:
              - match: { prefix: "/" }
                route: { cluster: wordpress_backend }
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

  clusters:
  - name: wordpress_backend
    connect_timeout: 5s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: wordpress_backend
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address: { address: wordpress-app, port_value: 80 }

同じことをするのに記述量が数倍になります。Envoy は「リスナー → フィルターチェーン → ルート → クラスター」という部品を組み合わせる設計で、@type で各部品の型を明示します。冗長に見えますが、この構造があるからこそ、同じ設定を API で動的に配信したり、フィルターを差し込んで機能を足したりできます。use_remote_address: true は、接続元の IP アドレスを X-Forwarded-For に追加させるための設定です。

管理用インターフェース（上の例では 9901 番ポート）は統計値の確認や設定のダンプができる強力な入口なので、外部に公開せず 127.0.0.1 などに限定してください。

設定の検証方法

どちらも、反映前に構文チェックをする習慣をつけるとトラブルを減らせます。

# Nginx
sudo nginx -t
sudo systemctl reload nginx

# Envoy（設定ファイルを検証するだけで起動はしない）
envoy --mode validate -c /etc/envoy/envoy.yaml

Envoy は管理インターフェースの /clusters でバックエンドの状態を、/stats でリクエスト数やエラー数を確認できます。Nginx で同等の情報を得るには、アクセスログの解析や stub_status モジュールなどを組み合わせることになります。

WordPress の前段に置くときの注意点

どちらを使う場合でも、プロキシの後ろにある WordPress は「自分が HTTPS で見られているか」を直接知ることができません。プロキシで TLS を終端し、バックエンドへは HTTP で渡す構成では、WordPress が HTTP だと判断してリダイレクトループや混在コンテンツを起こすことがあります。

この場合は wp-config.php の require_once ABSPATH . 'wp-settings.php'; より前に、次のような処理を入れます。

// 信頼できるプロキシ経由でのみアクセスされる構成に限って使う
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

X-Forwarded-Proto はクライアントが自由に偽装できるヘッダーです。バックエンドにプロキシ以外から直接到達できる状態でこの処理を入れると、判定を偽装される余地が生まれます。ファイアウォールでバックエンドへの接続元をプロキシに限定してから使ってください。

また、WordPress から見た接続元 IP はプロキシのアドレスになります。ログイン試行の制限やコメントのスパム判定で実際のクライアント IP が必要な場合は、Web サーバー側（Apache の mod_remoteip や Nginx の realip モジュール）で、信頼するプロキシを指定したうえで X-Forwarded-For から復元する方法が安全です。

作業前には設定ファイルと WordPress のバックアップを取り、ステージング環境で動作を確かめてから本番に反映してください。

どちらを選ぶべきか

Nginx が向いているケース

• WordPress を1台〜数台の VPS やクラウドサーバーで運用している
• 静的ファイル配信や PHP-FPM への接続も同じソフトウェアで済ませたい
• 設定変更の頻度が低く、ファイル編集とリロードで十分に回る
• チーム内に Nginx の運用経験があり、トラブル時の情報を探しやすいことを重視する

一般的な WordPress サイトであれば、Nginx 1つで Web サーバーとリバースプロキシの両方をまかなえるため、構成要素が少なく障害点も減ります。

Envoy が向いているケース

• Kubernetes などのコンテナ基盤で、多数のサービスを動的に追加・削除する
• サービスメッシュ（Istio など）や Gateway API の実装（Envoy Gateway など）を採用している
• リトライ、サーキットブレーカー、詳細なメトリクスをプロキシ層で一元管理したい
• gRPC を含む複数のプロトコルを同じプロキシで扱いたい

この場合でも、WordPress 自体の PHP 実行は Nginx や Apache が担い、その手前に Envoy を置く二段構成になるのが一般的です。Envoy だけで WordPress を動かすわけではない点を押さえておくと、構成図を描くときに迷いません。

迷ったときの判断基準

「設定を API で動的に変えたいか」「プロキシ層で高度な通信制御や計測が必要か」の2点が判断の分かれ目です。どちらも不要なら、Nginx を選ぶほうが運用負荷は小さくなります。Kubernetes 上の Ingress コントローラーについては、プロジェクトの保守状況が変わることもあるため（たとえば ingress-nginx は保守終了の方針が示されています）、採用前に各プロジェクトの公式情報で現状を確認してください。

まとめ

• Nginx は Web サーバー兼リバースプロキシで、少数サーバーの WordPress 運用に向く
• Envoy はサービス間通信向けのプロキシで、xDS による動的設定、能動的ヘルスチェック、詳細な統計値が強み
• 同じ構成でも Envoy の設定は冗長だが、その構造が動的配信や拡張を支えている
• どちらを前段に置いても、WordPress には X-Forwarded-Proto と実クライアント IP の扱いを正しく伝える必要がある
• 「動的な設定変更」と「プロキシ層での高度な制御」が要らなければ Nginx、要るなら Envoy を検討する

• HAProxy と Envoy の比較
• Nginx のリバースプロキシ設定方法