コンテンツにスキップ 
NGINXのバッファリング プロキシがアップストリームからの応答をどのくらいの速さで、かつメモリを節約しながら受け取り、バッファに格納し、クライアントに送信するかを決定します。ここでは、レイテンシを低減し、バックエンド接続を早期に解放し、 メモリ その間、状況を把握しておく。.
中心点
以下の重要なポイントを押さえることで、パフォーマンスとメモリ使用量のバランスを適切に取ることができます。.
- デカップリング クライアントとバックエンド間の通信時間を短縮し、スループットを向上させます。.
- バッファサイズ RAMを節約し、ディスクI/Oを回避するために、正確に選択してください。.
- バッファの混雑 送信中のアクティブなメモリを制限する。.
- ストリーミングの例外 バッファリングなしでスムーズに操作できる。.
- モニタリング また、負荷テストによって、あらゆる変更が確実に検証されます。.
NGINXにおけるプロキシバッファリングの仕組み
私はアクティブ型を利用しています バッファリング, 、これによりNGINXはアップストリームから迅速に応答を取得し、その後、独自にクライアントへ配信します。この分離により、 レイテンシー バックエンドでは、アプリケーションの処理がより早く完了し、接続も早期に閉じられるためです。クライアントがさまざまな速度で読み込みを行う間、プロキシ層はメモリからの送信をタイミングよく制御します。 データがRAMに完全に収まらない場合、NGINXは一時的にファイルに依存することで、それでも確実にレスポンスを転送することができます。まさにこの動作によって、多数の同時接続がある高負荷なシステムの安定性が確保されるのです。 コネクション.
アクティブバッファリングが最適な選択肢となる場合
従来のWebアプリ、レスポンスサイズが中程度のAPI、あるいはWordPressスタックの場合、 バッファリング 常に最高の結果をもたらします。私はバックエンドの負荷を早めに軽減し、残りの転送はNGINXが、多くの場合混在するクライアントネットワークに対して引き受けます。これにより、実効的な スループット, 、特に多くのリクエストが同時に処理されている場合はなおさらです。リバースプロキシの背後に複数のサービスを統合すれば、制御された負荷分散という追加のメリットも得られます。プロキシに関するアーキテクチャ上の質問については、明確な リバース・プロキシ・アーキテクチャ, 、役割と制限を明確に区別する。.
ストレージ対I/O：適切な予算
RAMとハードディスクへのアクセスとのバランスを調整しているのは、バッファが小さすぎると不必要な ディスクI/O トリガーとなり、バッファが大きすぎると接続ごとのメモリ使用量が膨れ上がってしまう。重要なのは、典型的な応答サイズ、並列リクエスト、そして実際の クライアントの速度. 小さなレスポンスは、理想的には完全にRAM内に収まるため、NGINXは遅延なく、処理速度の遅い受信側へストリーミングできます。非常に大きなボディはディスクに書き出されても構いませんが、その場合は高速なドライブを使用し、過度なI/Oが発生しないよう制限を設けています。このバランスを保つことで、 応答時間 低く設定されており、システムを貯蔵圧力から保護します。.
指針と目安の概要
メモリや送信動作を制御するために、コアパラメータを意図的に設定しています。応答ヘッダー用の最初のバッファは、 proxy_buffer_size; これにより、ヘッダーのサイズが過剰になるのを防ぎ、不要なスワップを回避できます。実際のレスポンスデータは、 proxy_buffers 「数×サイズ」のペアとして、現実的に可能な限り、ボディが完全にRAM内に収まるようにする。 proxy_busy_buffers_size アクティブなメモリ使用量を抑えるため、すでに送信用に割り当てられているバッファの量を制限しています。一般的なサイズについては、メモリページ（4～32 KB）と、アプリケーションの既知の応答プロファイルを基準に設定しています。.
| 指令 | 効果 | 代表値 | 備考 |
|---|---|---|---|
| proxy_buffering | オン／オフ バッファリングの | on（既定値） | 標準のWebアプリでは有効にしておく；ライブストリーミングの場合は確認する |
| proxy_buffer_size | ヘッダーバッファ | 8k～16k | サイズが小さすぎると、「upstream sent too big header」というエラーが発生します„ |
| proxy_buffers | ボディバッファー | 8 16k、16 16k | 応答サイズと並列処理を連動させる |
| proxy_busy_buffers_size | 送信バッファの制限 | 32k～128k | RAMを占有することなく、十分なスループットを確保 |
| proxy_max_temp_file_size | ディスク容量制限 | 0～1g | 0 一時ファイルを無効にする |
| proxy_temp_path | パス 一時ファイル用 | SSDのパス | 高速な記憶媒体に保存する |
実務に即したプロファイルと計算例
アクティブな接続1件あたりのメモリ使用量は、おおまかに次の合計として計算しています。 proxy_buffer_size plus (N × バッファサイズ) を proxy_buffers から取得します。8 個の 16k バッファと 16k のヘッダーの場合、すべてが RAM 内に収まる限り、1 リクエストあたり約 144 KB となります。 したがって、5,000件の同時リクエストの場合、バッファの純粋な使用量は約720 MBとなり、これに プロセス. トラフィックが増加すれば、ニーズも増加します。そのため、典型的なレスポンスに対応できるようバッファを設定しつつ、ボディが異常に大きいような特殊なケースを通常のケースとして扱わないようにしています。必要に応じて、例外を次のように制限しています。 ディスクの制限, 、メモリ使用量のピークを緩和するために。.
私が意識的にバッファリングをオフにするのはいつか
リアルタイムAPI、サーバー送信イベント、ライブ動画には直接的な スループット 追加のバッファリングなし。そのような場合は、proxy_buffering を無効にし、効率的な ストリーミング. プロキシはデータを即座に転送するため、ライブデータにおける遅延の急増を防ぐことができますが、その一方でバックエンドへの接続が長く開いたままになります。このようなパターンについては、以下を参照するとよいでしょう。 レスポンス・ストリーミング, 、適切なキープアライブおよびタイムアウトの調整を含みます。重要なのは、接続ごとのリソース消費量が増加していることを常に把握し、それに応じて制限を設定することです。.
Busy Buffers を適切に設定する
と一緒に proxy_busy_buffers_size これにより、「送信準備完了」状態のメモリのうち、同時にブロックされたままになる量を制御します。制限を低くしすぎると配信が滞り、高く設定しすぎるとRAMの使用量が急増します。 そこで、NGINXがパケットを迅速に転送しつつ、過度な負荷をかけないよう、バッファサイズの1～2倍に相当する値を選択しています。 メモリ を割り当てる。処理速度の遅いクライアントに対しては、頻繁なコンテキスト切り替えのリスクを低減するため、多少多めのビジースペースを許容する。高速なネットワークでは、より厳しい値を設定することで、 メモリ要件 計画通りに進められるようにする。.
一時ファイル：パス、サイズ、制限
一時的なものを有効にします ファイル 大きなボディがリアルに動作する場合や、RAMが不足している場合に限ります。一時ファイルがSSDに保存されていれば、応答時間は許容範囲内に収まりますが、低速なディスクでは、I/Oによってシステム全体の動作がすぐに遅くなってしまいます。 返信スレッド. `proxy_max_temp_file_size` を使って、メモリ使用量が過剰になるのを防いでいます。不安がある場合は、厳格な上限を設定します。 大規模なレスポンスが並行して多数発生する場合は、十分な容量を確保し、実際の使用状況を監視します。RAMに余裕がある場合は、より大きなバッファを優先し、重要な部分は メモリ.
反復的なチューニング、メトリクス、およびテスト
私は保守的なものから始める 価値観, 、測定し、調整し、このサイクルを繰り返します。重要な指標としては、レイテンシ、エラー率、RAM使用量のピーク、I/O待ち時間、および 労働者. 負荷テストでは、クッキーによるヘッダーの急増や、まれに発生する大規模なレスポンスなど、日常の運用では見過ごされがちな影響を明らかにします。さらに、接続パラメータとワーカーパラメータの相互作用を調整し、例えば Worker‑Connections およびキープアライブ。変更があるたびに、その影響を バッファ 明確に割り当てることができる。.
リクエストバッファリングとアップロード
応答バッファは真実の半分に過ぎない。入力側では、 proxy_request_buffering, NGINXがクライアントのボディ（アップロードなど）を完全にバッファリングしてから送信するか、それともアップストリームに即座にストリーミングするか。 大容量のファイルを受信するAPIの場合、私はよくリクエストバッファリングを無効にします。これにより、アップストリームがデータをより早く受け取れるようになり、タイムアウトが短縮され、NGINXが大きなボディをディスクに一時保存する必要がなくなります。デメリットは、アップストリーム接続がより長く開いたままになり、クライアントの速度に大きく依存してしまうことです。 従来のフォームや小規模なJSONリクエストの場合は、スパイクを適切に平滑化し、サーバーリソースをより適切に管理するために、リクエストバッファリングを有効にしています。これと組み合わせて クライアント・ボディ・サイズ そして、それに合う client_body_buffer_size, 、外れ値を早期に排除するか、適切にバッファリングできるようにするためです。.
Pro-Response の制御：X-Accel-Buffering、Chunked、および長さ
細かい設定として、レスポンスごとのバッファリングを無効にしています。 X-Accel-Buffering Upstreamからの情報：「X-Accel-Buffering: no」というヘッダーは、proxy_bufferingがグローバルに有効になっている場合でも、NGINXに対してレスポンスを直接ストリーミングするよう指示します。私はこれを利用して、SSE、ロングポーリング、または診断ストリームを、一般的なチューニングを犠牲にすることなく実現しています。 さらに、正しい コンテンツの長さ, 、可能な場合は：NGINXが長さを把握している場合、バッファや一時ファイルの計画は、単に チャンクド 転送されます。長さが不明な場合（例：ライブストリーム）、必要量を控えめに見積もり、制限を設けてI/Oを確実に処理します。エラーページや小さなJSONレスポンスについては、バッファリングを厳格に有効にし、アップストリームクラスターが早期に解放されるようにしています。.
圧縮とプロトコル：HTTP/2/3の概要
圧縮とバッファリングは、セットで考える必要があります。もし ジージップ またはBrotliが有効になっている場合、RAM内の連続したデータブロックの圧縮が効率化されます。バッファが小さすぎると、コンプレッサーが頻繁にコンテキストを切り替えなければならないため、スループットが制限される可能性があります。 そのため、接続ごとにRAMが溢れかえることなく、典型的な応答セグメントを適切にまとめることができるバッファサイズを選択しています。以下で HTTP/2 そして HTTP/3 マルチプレクシングとフロー制御により、ストリームごとに送信速度が変化します。バッファリングがバックエンド側の動作を安定させ、NGINXがストリームを正確にタイミング調整します。 重要：レイテンシに非常に敏感な経路では、Busy-Spaceをわずかに減らすことで、ヘッド・オブ・ライン効果を緩和できます。一方、ウィンドウサイズが大きい「太い」回線では、最大送信性能を維持するために、Busy-Spaceを少し多めに確保しています。.
プロキシキャッシュとレンジリクエスト：バッファとの相互作用
誰が proxy_cache を使用する場合、バッファと一時ファイルの予算を互いに調整する必要があります。NGINXは、レスポンスをキャッシュしつつクライアントに配信することも可能です。十分なRAMバッファを確保することで、バックエンド接続の維持時間を短縮できる一方、キャッシュヒットにより、その後のリクエストは完全に独立して処理されます。 キャッシュがウォーム状態のときは一時ファイルの制限を厳しくし、ヒット率の向上が進行している間はそれらを開放します。 レンジに関するお問い合わせ （部分ダウンロードの場合）キャッシュから直接提供するのか、それともまず完全にバッファに読み込むのか、私が判断します。大容量ファイルの頻繁な範囲アクセスでは、ディスクI/OやRAMの使用量が暴走しないよう、綿密に調整されたバッファサイズと、オプションでセグメント化された応答を活用することで、パフォーマンスを最適化できます。.
動作の遅いクライアント：RAMを消費せずにスループットを最適化
バッファ効果の大部分は、非常に低速なクライアントでのみ現れます。私は send_timeout およびオプション limit_rate/limit_rate_after, 、躊躇する受信者を保護しつつ、ワーカーを過度に拘束しないようにするためです。大幅にスロットリングされる場合は、ビジー・バッファを増やす必要があります。そうしないとストールが発生する恐れがあります。同時に、IP ごとの並列接続数を制御して、異常なパターンを緩和しています。 モバイル、Wi-Fi、光ファイバーなど、さまざまな接続環境が混在するダウンロードの場合、適度なBusy値とやや余裕のあるBodyバッファを設定することで、アップストリームがすでに次のリクエストを処理している間も、NGINXが線形にリクエストを順次送信できるようになります。.
コンテナ環境での運用とオーケストレーション
コンテナ内で、それを計画しています proxy_temp_path 留意点：高速なホストボリューム（SSD）か、十分なRAMがある場合はtmpfsのいずれかを使用する。 コンテナの制限（メモリ／CPU／一時ストレージ）は、バッファや一時ファイルに直接影響します。私はピーク時の負荷に備えて十分な余裕を確保し、それに応じて並列ワーカー数や接続数を調整しています。重要な点は以下の通りです。 ulimit -n （ファイルディスクリプタ）とオーケストレーターのクォータ：一時メモリが不足していると、一時ファイルがエラーとなり、RAMが不足していると、ワーカーはOOM（メモリ不足）の圧力によりダウンしてしまいます。 私は、コンテナの範囲内で典型的な負荷のピークが安定するようにバッファのサイズを設定し、一時ディレクトリの実際の容量使用状況を継続的に監視しています。.
一般的なWebアプリ用の初期設定値とブループリント
信頼性の高い出発点として、簡単なプロファイルを用い、その後、測定値を用いてそれを精緻化しています。例：
location / {
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_buffering on;
# ヘッダーおよびボディバッファ
proxy_buffer_size 16k;
proxy_buffers 16 16k;
proxy_busy_buffers_size 64k;
# 一時ファイルはフォールバックとしてのみ使用
proxy_max_temp_file_size 256m;
proxy_temp_path /var/cache/nginx/proxy_temp 1 2;
# タイムアウトと送信
proxy_read_timeout 60s;
send_timeout 30s;
# オプション：API に応じたアップロード・ストリーミング
# proxy_request_buffering off;
}
これにより、中規模の応答は完全にRAM内に収まり、アップストリームは早期に解放され、一時ファイルは異常値が発生した場合にのみ使用される。 第2段階では、バッファ数を実際の並列処理状況に合わせて調整し、短くて頻繁なレスポンスがある場合は必要に応じて「Busy」のサイズをわずかに増やし、キャッシュヒット率が向上し次第、一時ファイルの使用制限を厳しくします。.
モニタリングとロギング：効果を可視化する
私は一貫して測定しています： 1TP4リクエスト時間 そして $upstream_response_time アクセスログから、アップストリームが早期に切り離されているかどうかを確認します。. $バイト_送信 そして $body_bytes_sent バッファプロファイルを実際のトラフィックと照合するのに役立ちます。アップストリーム時間と総所要時間の差が小さくなれば、バッファは適切に機能していることになります。私はこれを、RAMの使用率のピーク、I/O待機時間、および proxy_temp_path. ストレステストでは、クライアントの速度、応答高さ、ヘッダー負荷（クッキーなど）を変化させて、エッジケースを見つけ出します。 ログメトリクスとシステム値が目標範囲内で安定して維持されるようになって初めて、そのプロファイルを確定し、制限値やエスカレーション手順（バッファの拡大、一時ファイルポリシーの変更、レプリカの追加など）を文書化します。.
よくある不具合とその対処法
「„アップストリームから送信されたヘッダーが大きすぎます“この問題は、proxy_buffer_size を大きくし、必要に応じて proxy_buffers も増やすことで解決します。端末の処理速度が遅い場合にタイムアウトが発生する場合は、送信タイムアウトを適度に延長し、ビジーバッファの余裕を少し増やします。 一時ディレクトリが満杯になった場合は、費用対効果を勘案して、最大サイズを下げるか、RAMバッファを増やすようにしています。配信がカクつく場合は、I/Oのボトルネック、CPUの飽和状態、および バッファ. 供給不足の状況については、私は常にまず測定値に基づいて対処し、一律に倍増させるようなことはしません。.
まとめ：NGINXのプロキシバッファリングに関する私のチェックポイント
まず、典型的なものを定義します 対応サイズ, ピーク負荷やクライアントプロファイルを確認してから、バッファの設定に取り掛かります。その後、不必要なエラーが発生しないよう、十分な大きさのヘッダーバッファを設定します。ボディバッファは、通常のレスポンスがRAM内に収まり、例外的なケースのみが ディスク となる。Busy Buffers は、メモリを無駄にすることなく転送がスムーズに実行されるように設定する。最後に、負荷テストとモニタリングを用いて、レイテンシ、スループット、メモリ使用量が信頼できる ウィンドウズ 嘘だ。
