リバースプロキシ完全攻略：Nginx/Envoyの役割とパフォーマンスを最大化するバッファ・タイムアウト設定

Webアプリケーションの安定稼働とパフォーマンス向上に不可欠なリバースプロキシ。その中でもNginxとEnvoyは、多くのシステムで採用されている強力なツールです。本記事では、2026年現在のモダンなWebサービス開発において、NginxとEnvoyが果たす役割を解説し、さらにパフォーマンスと安定性を最大化するための適切なバッファ・タイムアウト設定について、簡潔かつ実践的にご紹介します。

リバースプロキシの役割（Nginx/Envoyの基本）

リバースプロキシは、クライアントからのリクエストを直接バックエンドサーバーに転送するのではなく、間に立って「代理」するサーバーです。これにより、バックエンドサーバーの負荷軽減、セキュリティ強化、可用性向上など、多岐にわたるメリットが生まれます。

NginxとEnvoyは、どちらも高性能なリバースプロキシとして機能しますが、それぞれ異なる特徴を持ちます。

• Nginx: 軽量かつ高速なWebサーバーとしての機能も持ち合わせ、静的コンテンツの配信やSSLターミネーション、キャッシュ機能に優れています。設定ファイルはシンプルで直感的であり、幅広いユースケースで利用されています。
• Envoy: マイクロサービスアーキテクチャに特化したエッジ/サービスプロキシです。動的な設定変更、高度なトラフィック管理（A/Bテスト、カナリアリリースなど）、分散トレーシングとの統合など、サービスメッシュのデータプレーンとしての役割も果たします。特に複雑な分散システムで真価を発揮します。

リバースプロキシの主な役割は以下の通りです。

1. 負荷分散（ロードバランシング）: 複数のバックエンドサーバーへリクエストを分散し、特定のサーバーへの負荷集中を防ぎます。
2. セキュリティ強化: クライアントとバックエンドサーバーの間に立つことで、直接的な攻撃からバックエンドを保護します。SSL/TLS終端を行うことで、バックエンドサーバーの負荷を軽減し、暗号化通信を提供します。
3. キャッシュ: 頻繁にアクセスされるコンテンツをプロキシサーバーでキャッシュし、バックエンドへのリクエスト数を減らし、応答速度を向上させます。
4. 静的コンテンツ配信: 画像やCSS、JavaScriptなどの静的ファイルを高速に配信し、バックエンドサーバーの処理負担を軽減します。
5. APIゲートウェイ: マイクロサービスへのルーティング、認証、レート制限などを一元的に管理します。

パフォーマンスを最大化するバッファ設定

リバースプロキシにおけるバッファリングは、クライアントとバックエンドサーバー間のデータ転送速度の差を吸収し、効率的な通信を可能にする重要な機能です。 適切に設定することで、バックエンドサーバーの過負荷を防ぎ、ユーザー体験を向上させることができます。

Nginxのバッファ設定

Nginxでは、主にproxy_buffer_sizeとproxy_buffersディレクティブでバッファリングを制御します。

• proxy_buffering on | off;: バッファリングを有効または無効にします。デフォルトはonです。 ストリーミング処理などリアルタイム性が重要な場合はoffに設定することもありますが、その際はバックエンドがクライアントの速度に律速される可能性があるため注意が必要です。
• proxy_buffer_size size;: バックエンドサーバーからのレスポンスヘッダを格納するバッファのサイズを設定します。デフォルトはプラットフォームに依存し、4KBまたは8KBです。 HTTPヘッダがこのサイズを超える場合、upstream sent too big headerといったエラーが発生することがあります。 通常はデフォルトで十分ですが、大量のCookieやカスタムヘッダを使用する場合は調整が必要です。
• proxy_buffers number size;: バックエンドサーバーからのレスポンスボディを格納するためのバッファの「数」と「サイズ」を設定します。例えばproxy_buffers 8 16k;は、16KBのバッファを8個（合計128KB）使用することを意味します。 レスポンスがバッファサイズに収まらない場合、Nginxは一時ファイルに書き出すことがあります。 これが頻繁に発生するとI/O負荷が高まるため、エラーログでan upstream response is buffered to a temporary fileという警告が多発する場合は、この値を調整してメモリでのバッファリングを増やすことを検討しましょう。

設定のポイント:

• バックエンドからの平均的なレスポンスサイズを把握し、proxy_buffersの合計サイズがそれに対応できるよう調整します。
• メモリ使用量とのトレードオフを考慮し、無駄に大きな値を設定しないようにします。
• proxy_buffer_sizeは主にヘッダ用、proxy_buffersはボディ用と理解し、それぞれ適切に設定します。

Envoyのバッファ設定

Envoyも同様にバッファリングの概念を持ちますが、その設定はNginxとは異なります。Envoyはデフォルトで接続ごとのバッファ制限が1MiB (1,048,576バイト) です。 大規模なファイルアップロードや大きなJSONペイロードを扱う場合、このデフォルト値を調整する必要があるかもしれません。

Envoyは、リクエストやレスポンスのボディをストリーミングで処理することが多いですが、特定のフィルター（例: バッファフィルター）を使用すると、リクエスト全体をメモリにバッファリングできます。 これにより、リクエストの検査やリトライなどが可能になりますが、メモリ使用量が増加します。

• filter_chains.filters.typed_config.http_connection_manager.common_http_protocol_options.max_connection_duration (HTTP接続マネージャーレベル): TCP接続の最大期間を設定します。
• cluster.max_buffered_data_size: クラスターレベルでの読み書きバッファのソフトリミットを設定します。

Envoyのバッファは「ハイウォーターマーク」と「ローウォーターマーク」という概念でフロー制御を行います。バッファサイズがハイウォーターマークを超えると、Envoyはデータソースからの読み込みを停止し、バックプレッシャーをかけます。

設定のポイント:

• Envoyのバッファ設定は通常、HTTP接続マネージャーやクラスターレベルで定義されます。
• Istioなどのサービスメッシュ環境では、EnvoyFilterリソースを使用してバッファサイズを調整することが可能です。
• メモリ枯渇を防ぐため、サービスが扱うデータ量に応じて適切なバッファサイズを設定することが重要です。

適切なタイムアウト設定で安定性を確保

タイムアウト設定は、リバースプロキシがバックエンドサーバーやクライアントとの通信でどれくらいの時間待機するかを定義し、リソースの無駄な消費を防ぎ、サービス全体の安定性を保つために不可欠です。

Nginxのタイムアウト設定

Nginxでは、主に以下のディレクティブでタイムアウトを制御します。

• proxy_connect_timeout time;: Nginxがバックエンドサーバーへの接続を確立するまでのタイムアウト時間です。デフォルトは60秒。 ネットワークの問題やバックエンドサーバーの起動が遅い場合に調整が必要になることがあります。通常、数秒で十分です。
• proxy_send_timeout time;: Nginxがバックエンドサーバーへリクエストを送信する際の、2つの連続した書き込み操作間のタイムアウト時間です。デフォルトは60秒。 リクエストボディの送信が非常に遅い場合に影響します。通常、デフォルトで問題ありません。
• proxy_read_timeout time;: Nginxがバックエンドサーバーから応答を受信する際の、2つの連続した読み込み操作間のタイムアウト時間です。デフォルトは60秒。 バックエンドでの処理に時間がかかる場合、このタイムアウトによって504 Gateway Timeoutエラーが発生する主要な原因となります。

設定のポイント:

• バックエンドサーバーの処理時間やネットワーク状況に合わせて、proxy_read_timeoutを適切に設定することが最も重要です。 長時間かかるAPIやレポート生成などの処理がある場合は、この値を長く設定します。
• proxy_connect_timeoutとproxy_send_timeoutは、通常デフォルト値で問題ないことが多いですが、ネットワークが不安定な環境では調整を検討します。
• サービス全体のSLA（Service Level Agreement）を考慮し、ユーザーが許容できる待機時間に合わせて設定します。

Envoyのタイムアウト設定

Envoyは非常に多様なタイムアウト設定を提供し、HTTP接続マネージャー、ルート、クラスターなど、様々なレベルで詳細な制御が可能です。

• connect_timeout (クラスターレベル): EnvoyがアップストリームTCP接続を確立するまでのタイムアウト時間。デフォルトは5秒です。
• http_connection_manager.stream_idle_timeout: 個々のストリーム（リクエスト/レスポンスペア）が、アップストリームまたはダウンストリームでアクティビティがない状態を許容する時間。デフォルトは5分です。 ストリーミング応答やアイドル期間の長いWebSocket接続などで重要になります。
• route.timeout: Envoyがアップストリームからの完全な応答を待機する時間。デフォルトは15秒です。 このタイムアウトはダウンストリームのリクエストストリーム全体が受信されてから開始されます。 ストリーミング応答や長時間かかる処理では、これを無効にするか、十分な長さに設定する必要があります。
• common_http_protocol_options.idle_timeout: HTTP接続全体がアクティブなリクエストやストリームがない状態で保持される時間。デフォルトは1時間です。

設定のポイント:

• Envoyのタイムアウトは階層的に適用されるため、グローバル設定とルート固有の設定を適切に組み合わせます。
• 長時間の処理が必要なエンドポイントでは、route.timeoutを長く設定するか、0sに設定して無効にすることを検討します。
• WebSocketやgRPCストリーミングなど、長期間アイドル状態になる可能性のある接続では、stream_idle_timeoutやidle_timeoutの調整が不可欠です。
• 2026年現在、タイムアウト設定はリソース枯渇を防ぎ、予測可能なリクエスト処理を保証するために不可欠であり、適切な監視と調整が必要です。

これらのバッファ・タイムアウト設定は、システムの種類、トラフィックパターン、バックエンドアプリケーションの特性によって最適な値が異なります。常に監視し、テストを通じて最適なバランスを見つけることが、リバースプロキシの真の力を引き出し、安定したサービス提供への鍵となります。

---

エンジニアのスキルシェアプラットフォーム「DokuPro」

教えたい人と学びたい人を繋ぐDokuProでは、新規登録（先生・生徒）を募集中です。
詳細はこちら: https://dokupro.dev/