コンテンツにスキップ 
と一緒に nginx キープアライブ これにより、接続確立コストを削減し、ハンドシェイクの回数を減らし、応答時間を著しく短縮します。適切に調整されたタイムアウト、接続ごとのリクエスト制限、および再利用されたアップストリームソケットにより、新たなハードウェアを導入することなく、測定可能なパフォーマンスの向上を実現します。.
中心点
- タイムアウト 適切な選択：アイドル時間は、必要最小限に、かつ有用な限り長く保つ。.
- リクエスト 接続ごとの制限：ソケットの寿命が長く、フリーズしない。.
- アップストリーム・プール 有効化：ワーカーごとの永続的なバックエンド接続。.
- 労働者 および接続を調整する：アイドル状態およびアクティブなクライアント用に十分なスロットを確保する。.
- モニタリング 確立する：接続率、遅延、エラーを監視する。.
NGINXのキープアライブ：効果とコスト
私は意図的にTCP接続を開いたままにしています。その理由は、 握手 コストが高く、多数の小さなリクエストで大きな割合を占めてしまいます。パーシステントソケットはRTTを短縮するだけでなく、TLSの暗号処理が実行される頻度が減るため、CPU負荷を平準化します。ただし、開いている接続1つにつき リソース, 、例えばファイルディスクリプタやバッファなど、常に把握しておく必要がある要素です。重要なのはバランスです。パフォーマンスを確保するために十分な再利用を行い、負荷のピーク時には新しい接続を確立するための十分なリソースを確保することです。このバランスを適切に取ることができれば、TTFB値を常に低く抑え、ユーザーに高速な操作感を提供できます。.
HTTP/2 と HTTP/3：マルチプレクシングとキープアライブの融合
と一緒に HTTP/2 そして HTTP/3 1つの回線上で複数のストリームが流れるため、クライアント1台あたりに必要な接続数は減少します。それでも、キープアライブは依然として重要です。1つの接続は確実に維持されなければなりません。そうしないと、頻繁な再接続によって多重化のメリットが台無しになってしまいます。.
最新のプロトコルについては、専用のアイドルパラメータに注意を払い、その値がクライアントのタイムアウト設定と整合するようにしています。テストでは、まず適度な設定から始め、負荷が安定したら、再接続率が低下し、レイテンシが一定になるまで設定値を徐々に引き上げていきます。.
http {
# HTTP/2：使用されていないがオープンされているストリームのアイドル時間
http2_idle_timeout 60s;
# HTTP/3/QUIC：UDPベースの接続に対する同様のロジック
http3_idle_timeout 60s;
# TLS再開により、再接続時のハンドシェイク負荷を軽減
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets off;
}
多重化により、必要な並列TCP/QUIC接続数は減少しますが、その重要性は 適切なタイムアウト. HTTP/2/3 を利用している場合、多くの小さなリソースが同じチャネルを経由して送信されるため、クライアントのタイムアウトを多少長めに設定できることがよくあります。重要：測定可能であることを維持すること 最初のバイトまでの時間, 、接続ごとのエラー率およびアクティブなストリーム数。.
クライアントのキープアライブを正しく設定する
ブラウザクライアントについては、以下の方法で再利用を管理しています。 keepalive_timeout そして keepalive_requests, 、ソケットがいつまでもブロックされたままにならず、十分な時間存続するようにするためです。最初はタイムアウトを30～60秒、接続あたりのリクエスト数を100～300に設定し、その後、メトリクスに基づいて調整しています。詳細な分類については、こちらをご覧ください。 キープアライブ・タイムアウト・ガイド, 、ここではレイテンシやサーバーリソースへの影響について解説しています。タイムアウトを短く設定すると、非常に多くの短い呼び出しがある場合に適しており、時間枠を長くすると、定期的なAPIアクセスに役立ちます。まずは明確なデフォルト値を設定し、オープン接続数やエラーパターンへの影響を測定します。.
http {
# クライアントへのアイドル接続
keepalive_timeout 60s;
# TCP接続ごとのリクエスト数の上限
keepalive_requests 200;
# オプション：特定のクライアントに対してキープアライブを無効にする（レガシーバグ）
# keepalive_disable msie6;
}
リバースプロキシにおけるアップストリーム・キープアライブ
NGINXとバックエンドアプリの間では、PHP-FPM、Node.js、あるいはPythonサービスへの接続も同様に、永続的なアップストリームソケットを使用しています。 レイテンシー かかります。そのため、アップストリーム・プール内で、ワーカーごとに適切な数の再利用可能な接続を有効にします。重要なのは、HTTP/1.1をバックエンド側に指定し、Connectionヘッダーを空にすることです。そうしないと、クライアントからの「close」要求によってバックエンドの永続性が破綻してしまいます。 同時リクエスト数を基準とし、新しい接続がほとんど発生しないようにプールを設定しています。これにより、バックエンドの接続時間が短縮され、チェーン全体がより高速に動作するようになります。 回答.
upstream backend {
server 127.0.0.1:9000;
keepalive 64; # ワーカーごとの永続的なアップストリーム接続数
}
server {
location / {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
# OSレベルでのアップストリームソケットに対するTCPキープアライブ
proxy_socket_keepalive on;
}
}
プールの規模設定と接続予算
私はプールを現実的に計算しています。永続的なアップストリーム接続の数は、以下から算出されます。 worker_processes × keepalive アップストリームごとに。ワーカーを8つ、keepaliveを64に設定した場合、インスタンスごとにアップストリームあたり最大512個のソケットが開いたままになります。ロードバランサーの背後にある場合や、アップストリーム先が複数ある場合は、その数がすぐに膨れ上がる可能性があります。.
私の目標値：リクエストの大部分を処理できるだけの十分な空きソケット数 新しいConnectなし 処理は行われているが、ピーク時の余力はまだ残っている。私は「1秒あたりの新規アップストリーム接続数」というメトリクスを監視し、プールサイズをさらに拡大してもレイテンシの顕著な改善が見られなくなるまで、この数値を下げていく。.
私はまた、次のことも考慮に入れている。 公平性: プールが大きすぎると、アイドル状態の接続がワーカー・スロットを占有してしまうため、新しく接続してきたクライアントに不利益が生じる可能性があります。適切な上限値を設定し、積極的に監視を行う方が、根拠なく最大値を設定するよりも、たいていの場合、処理が速くなります。.
微調整：タイムアウトとリクエスト制限
タイムアウトとリクエスト制限を組み合わせて、接続が効果的に再利用されるようにしつつ、 クロスカントリースキーヤー になる。両軸の値が高いと、コネクト数は最小限に抑えられるが、ネットワークトラブル時にソケットがハングするリスクが高まる。 値を低く設定すると接続が新鮮に保たれますが、追加のハンドシェイクが発生します。私は少しずつ調整を進め、エラーを観察しながら、一定の間隔で微調整を行っています。以下の表は、さまざまな利用パターンに適した初期設定範囲を示しており、簡潔な オリエンテーション.
| シナリオ | keepalive_timeout | keepalive_requests | ヒント |
|---|---|---|---|
| 短いページ閲覧が多数ある | 10～30秒 | 100-300 | 高速な再利用、アイドル時のリソース消費が低い |
| 典型的なウェブサイト | 60～120秒 | 200–400 | AssetsとHTMLにおける適切なバランス |
| 定期的な呼び出しを行うAPI | 60～120秒 | 300–1000 | クライアントの再利用率の向上 |
| 内部サービス／ゲートウェイ | 30～90秒 | 500–1000+ | コンスタンスは、わずかなコネクト数よりも重要である |
ワーカーのチューニングと接続
私はこう言った。 ワーカープロセス 「auto」またはCPUコアの数に設定し、十分な ワーカーコネクション アイドルソケットがスロットを占有するためです。制限値が低すぎると、CPUの余力があるにもかかわらず、新しい接続を受け付けられなくなります。キープアライブプールを大きく設定する場合は、ワーカーごとに十分な記述子とイベントスロットが必要です。この点について、以下の資料が分かりやすい入門となっています。「„Worker-Connectionsのスケーリング“「」では、イベント、接続、負荷の間の関連性について解説しています。綿密に検討された設定値により、アイドル時の再利用と新たな接続が共存できるようになっています。.
worker_processes auto;
events {
worker_connections 4096;
# オプション：reuseport を設定すると、カーネルレベルでの負荷分散が改善される場合があります
# multi_accept on;
}
http {
keepalive_timeout 60s;
keepalive_requests 200;
upstream backend {
server 127.0.0.1:9000;
keepalive 64;
}
}
オペレーティングシステムおよびソケットのチューニング
Keepaliveがその性能を十分に発揮できるよう、システムの制限事項を確認しています。ディスクリプタの数が少なすぎたり、ソケットキューの容量が狭すぎたりすると、 人為的なボトルネック. ulimit や worker_rlimit_nofile に加え、カーネルの制限も重要な要素となります。.
# sysctl の設定例（注意を払い、テストを行いながら調整してください）
fs.file-max = 1000000
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 16384
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_syn_backlog = 262144
これらの値を環境に合わせて調整しています。多くの短命な接続では、ポート範囲を広くし、FIN／TIME_WAIT時間を短くすることでメリットが得られます。アップストリーム・キープアライブについては、 Neuconnects, これによりTIME_WAITの負荷が軽減されます。さらに、私は ナット- プロキシとバックエンドの間のデバイス：ネットワーク上のアイドルタイムアウトが厳しすぎると、予期せぬタイミングで接続が切断される。ソケットごとのリクエスト制限を適度に設定し、TCPキープアライブ（proxy_socket_keepalive on;) は、「古びた」接続を防ぐ。.
ヘッダーとHTTPバージョンを正しく設定する
私は次のことに注意を払っている。 HTTP/1.1 バックエンド側では、Upstream-Keepaliveが機能するのはバックエンド経由のみであるためです。また、NGINXが永続性を自律的に管理できるよう、ヘッダーによるアクティブな接続制御を無効にしています。 クライアント側では、Keep-Aliveを標準に準拠して動作させ、タイムアウトとリクエスト制限によって有効期間を制限しています。さらに、リセットエラーを防ぐため、バックエンドのアイドルタイムアウトを確認し、NGINXの設定よりもわずかに長く設定しています。適切なヘッダー設定により、 再利用 意図しない閉鎖がないこと。.
# の例：正しいヘッダーを持つプロキシ・ロケーション
location /api/ {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
区別：HTTP Keep-Alive 対 TCP Keep-Alive
とは厳密に区別している。 HTTP Keep-Alive （1つの接続につき複数のHTTPリクエスト）および TCP-キープアライブ （OSレベルでのプローブにより、応答のない相手先を検出）。HTTPのKeep-Aliveは以下のように制御しています。 keepalive_timeout そして keepalive_requests, 一方、TCPキープアライブはスタックによっては proxy_socket_keepalive on; およびシステムパラメータを実行します。不安定なネットワーク上のバックエンドについては、応答しなくなったソケットをより迅速に解放するために、TCPキープアライブを有効にしています。.
長期実行プロセスと特殊なケース：WebSockets、SSE、gRPC
ウェブソケットとサーバー送信イベントは クロスカントリースキーヤー, 、長期間にわたって接続を維持するもの――ここでは、従来のReuseは二次的な役割しか果たしません。私は適切な proxy_read_timeout そして、私を守ってください send_timeout にとって スローロリス-の影響。gRPC（HTTP/2ベース）については、マルチプレクシングに関する考慮事項が適用されます。アイドルタイムアウトは、ストリームが不必要に切断されないように設定しています。.
location /ws/ {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 300s;
send_timeout 30s;
}
モニタリングと測定基準
私は、新規アップストリーム接続の割合などの指標を用いて成果を測定しており、, アップストリームコネクトタイム およびワーカーごとの未閉じた接続の割合。リクエスト数が横ばいまたは増加しているにもかかわらず接続率が低下している場合は、再利用が成功していることを示唆しています。顕著なタイムアウトや接続リセットは、NGINXとバックエンド間のタイムアウト設定に不整合があることを示しています。 さらに、負荷がかかっている状態でのメモリ、ファイルディスクリプタ、イベントキューの状況を監視しています。定期的にチェックを行うことで、傾向を早期に発見し、コストのかかる問題を未然に防ぐことができます。 失敗例.
再利用の可視性を高めるためのロギング機能の改善
より詳細な情報を得るために、アクセスログに接続の詳細情報を追加しています。これにより、TCP接続がどれくらいの頻度で再利用されているか、また接続時間がどのように変化しているかを把握できます。.
log_format keepalive_fmt
'$remote_addr $host "$request" $status $body_bytes_sent '
'$request_time $upstream_connect_time '
'conn:$connection reqs:$connection_requests';
access_log /var/log/nginx/access_keepalive.log keepalive_fmt;
私は、以下の値の中央値およびP95/P99値を観察しています。 アップストリームコネクトタイム ならびに以下の配分 $接続要求. レイテンシが安定している状態でリユース数が増加しているということは、プールとタイムアウトが適切に設定されていることを意味します。.
典型的な障害と解決策
プールが大きすぎると、新しいクライアントが待機している間に接続スロットが埋まってしまうため、私はサイズを適度に抑え、状況を見ながら調整しています。プロキシとバックエンドでアイドルタイムアウトが異なるとリセットが発生するため、バックエンドのタイムアウトはプロキシよりもわずかに長く設定しています。 NGINX. プロキシヘッダーで「Connection: close」を書き忘れると永続性が失われるため、私はヘッダーを徹底的に空にしています。再接続が頻繁に行われると、TLSネゴシエーションがCPUに負荷をかける可能性があるため、リユース率を高めることでこの問題を緩和しています。 散発的なネットワーク障害が発生した場合は、ソケットごとのリクエスト制限を適度に設定することで、古い セッション 永遠に生きられるわけではない。.
実務に即した構成
アクセス数の多いウェブサイトでは、アセットが効率的に動作するよう、タイムアウトを短く設定し、リクエスト制限を中程度に設定しています。繰り返し呼び出しが行われるAPIについては、TCPおよびTLSのハンドシェイクをさらに削減するために、制限を引き上げます。 アップストリームプールの規模は、予想される並行処理数に基づいて決定し、現実的なトラフィックでテストを行います。環境ごとに挙動が異なるため、変更後はレイテンシとエラーパターンを確認しています。2つの例を挙げると、 開始値, その後、メトリクスを使ってさらに精度を高めます。.
# シナリオ 1：アクセス数の多いウェブサイト
http {
keepalive_timeout 30s;
keepalive_requests 300;
upstream app {
server 127.0.0.1:8080;
keepalive 32;
}
server {
listen 443 ssl http2;
# HTTP/2のアイドル時間を監視
http2_idle_timeout 45s;
}
}
# シナリオ 2：定期的な呼び出しを行う API
http {
keepalive_timeout 75s;
keepalive_requests 1000;
upstream api_backend {
server 127.0.0.1:9001;
keepalive 64;
}
server {
listen 443 ssl http2;
# 定期的な呼び出し向けに、やや長めのアイドルウィンドウを設定
http2_idle_timeout 75s;
}
}
反復的最適化のためのチェックリスト
まずは現状の分析から始めます。トラフィックパターン、応答時間、エラー率が作業のペースを決定します。その後、クライアントタイムアウトとリクエスト制限を適切な初期値に設定し、アップストリームプールを有効にします。予期せぬ事態を防ぐため、バックエンドのアイドルタイムアウトはNGINXよりも少し長めに設定します。 リセット 発生します。その後、ワーカーごとの接続レート、接続時間、およびオープンソケット数を監視します。再利用率についてさらに深く知りたい方は、以下のトピックに関するヒントをご覧ください。 コネクションの再利用 そして、妥当な上限。.
追加の診断：ミスマッチと時間的挙動
接続が「理由もなく」切断されたように見えるときは、私は次のことを確認します。 ミスマッチ 一連のプロセスにおいて：クライアントのアイドル状態 vs. NGINXのタイムアウト vs. バックエンドのアイドル状態、および中間にあるNAT／ゲートウェイ。バックエンドのタイムアウトをNGINXの設定値よりわずかに長くし、エラーログの リセットコードを確認し、以下の点が観察されるかどうかを確認します。 アップストリームコネクトタイム ピーク値を示す。バックエンドのタイムアウト時には、多くの場合、わずかなバッファ（例：+10–20%）を設けるだけで、リセットを解消できる。.
また、私は「„lingering close“「-フェーズ：接続を閉じる際、NGINXは着信データを短時間流すため、ワーカーのリソースを消費します。同時に多数の接続が閉じられると、イベントがロックされることがあります。そのような場合は、接続終了のタイムウィンドウを調整し、適切なキープアライブ値を設定することで、開いている接続の総数を適正な範囲に保っています。.
要約：パフォーマンス向上の鍵となるキープアライブ
私は、接続確立コストの削減、レイテンシの低減、およびCPU負荷の軽減につながるため、Keepaliveを意図的に活用しています。適切なタイムアウト、適切なリクエスト制限、そして適切なアップストリームプールを組み合わせることで、顕著な スピード. モニタリングを行わなければ潜在能力は活かせないため、私は指標を継続的に確認し、値を段階的に調整しています。さらなる余力が必要な場合は、ワーカー数、接続スロット、およびヘッダーの適切な処理に注意を払う必要があります。例えば、以下のようなプロフェッショナルなセットアップでは webhoster.de, 、これらの調整機能を徹底的に活用し、迅速かつ信頼性の高いサービスを提供しています。.
