nf_conntrack枯渇で接続断が起きる本番サーバの診断と恒久チューニング設計

nf_conntrack（ネットフィルター接続追跡）は、Linuxカーネルがステートフルなパケットフィルタリングを実現するための中核機構です。NATやファイアウォールを有効にした環境では常に動作しており、TCP/UDPのフロー情報をカーネル内テーブルに記録し続けます。このテーブルには上限（nf_conntrack_max）があるため、接続数が急増するとテーブルが埋まり「nf_conntrack: table full, dropping packet」というカーネルログが記録されて新規接続が一斉に拒否されます。これがnf_conntrack枯渇障害の正体です。

ウェブAPIサーバ、マイクロサービスのサイドカーが多数ある環境、あるいはロードバランサとして機能しているサーバなど、短命な接続を大量に処理するワークロードでは特に発生しやすい障害です。CPUやメモリのリソースには余裕があるにもかかわらず、突然すべての方向から接続が切断されたように見えるため、原因の特定に時間がかかることが多くあります。

nf_conntrack枯渇が起きるメカニズムと典型症状

nf_conntrackテーブルには1エントリあたり約288バイト（カーネルバージョンやオプションにより異なります）のカーネルメモリが消費されます。デフォルトのnf_conntrack_maxはRAMサイズから自動計算されますが、メモリが多いサーバほど上限が高く設定される傾向があるため、「メモリは十分にある」という安心感から見落とされがちです。

現場で観測される症状としては以下のパターンが典型的です。

• dmesgやjournalに「nf_conntrack: table full, dropping packet」が大量出力される
• iptables/nftablesのDROP統計が突如として増加する
• 外形監視ツールが接続タイムアウトを断続的に報告する
• アプリケーションログにTCP接続エラーが散発し、サービス再起動後に一時回復する

特に「再起動後に一時回復する」という挙動が誤解を招きやすく、アプリケーションの不具合として処理されてしまうことがあります。再起動によって既存のconntrackエントリが消去されるため一時的に空きが生まれますが、負荷が戻ると再発します。根本原因を診断せずに再起動を繰り返すと、障害の兆候を見逃したままインシデントが深刻化するリスクがあります。

枯渇を確認する診断手順

まず現在のエントリ数と上限値を確認します。

cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

nf_conntrack_countがnf_conntrack_maxの90%を超えていれば黄信号、100%に達しているかdmesgに「dropping packet」の形跡があれば枯渇が確定します。conntrackコマンドが利用可能であれば、現在のエントリを状態別に把握できます。

conntrack -L 2>/dev/null | awk '{print $4}' | sort | uniq -c | sort -rn | head -20

TIME_WAITやCLOSE_WAITの状態が大量に残っている場合、タイムアウト値が長すぎてエントリが消化されずテーブルを占有している可能性があります。次にnf_conntrack_hashsizeを確認します。

cat /sys/module/nf_conntrack/parameters/hashsize

このハッシュテーブルのサイズがnf_conntrack_maxに対して極端に小さいと、ハッシュ衝突によるパフォーマンス低下が重なって問題が複合化します。推奨の目安はnf_conntrack_maxの1/8程度です。診断段階でこの三値（count・max・hashsize）を揃えておくことが、チューニング設計の出発点になります。

恒久チューニングの設計方針

対処は「上限値の引き上げ」「タイムアウト短縮」「ハッシュサイズの最適化」の三本柱で設計します。

上限値（nf_conntrack_max）の引き上げ
単純に上限を上げるだけでは枯渇が先延ばしになるだけです。ただし現行値が実態より小さく設定されているケースは多く、適切な目標値を算出することが先決です。conntrack -L | wc -l の最大観測値に1.5〜2倍の余裕係数を掛けた値を出発点にします。1エントリあたり約288バイトのカーネルメモリを消費するため、524288エントリは約150MBに相当します。サーバ搭載RAMの2〜5%以内に収まることを確認してから設定してください。

タイムアウト値の短縮
TIME_WAITエントリが大量に滞留している環境では、タイムアウトを短縮するとエントリの回転率が上がります。TCPのestablished状態のデフォルトは432000秒（5日間）と非常に長い設定です。NAT配下でセッションが長期間維持されるユースケースでなければ、1800〜3600秒に短縮しても実害は起きにくいです。UDPについても、DNSクエリが大量発生する環境ではunrepliedのタイムアウトを短縮する余地があります。

ハッシュサイズの調整
nf_conntrack_hashsizeはモジュールロード時のパラメータです。カーネル5.x以降はruntime変更がサポートされており、/sys/module/nf_conntrack/parameters/hashsizeへの書き込みで動的変更できます。ただし再起動後も反映させるにはモジュールオプションとして指定する必要があります。

systemd-sysctlで設定を永続化する

チューニング値は/etc/sysctl.d/配下に専用ファイルとして配置し、systemd-sysctl.serviceで管理するのが現行標準です。/etc/sysctl.confへの直書きは避けてください。ディストリビューションのパッケージが同ファイルに書き込む場合があり、管理の衝突が起きます。以下の内容で/etc/sysctl.d/90-nf-conntrack.confを作成します（値は前節の算出値に置き換えてください）。

net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_tcp_timeout_established = 1800
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 120

ファイルを配置したあと、再起動を待たずに適用するには以下のコマンドを使います。

sysctl --system

nf_conntrack_hashsizeはsysctlで制御できないため、モジュールオプションで指定します。/etc/modprobe.d/nf_conntrack.confを作成してください。

options nf_conntrack hashsize=65536

この変更は次回モジュールロード時（再起動時）に有効になります。動的に変更したい場合は/sys/module/nf_conntrack/parameters/hashsizeへ直接書き込みます。両方の変更を組み合わせることで、再起動をまたいで一貫した設定を維持できます。

チューニング後の検証と切り戻し手順

設定適用後はnf_conntrack_countの推移を継続的に監視します。Prometheusを使用している環境ではnode_exporter経由でnode_nf_conntrack_entriesとnode_nf_conntrack_entries_limitメトリクスが取得できます。Grafanaダッシュボードに使用率（entries / entries_limit）を追加し、ピーク時の余裕率が継続して20%以上あることを確認してください。

手動で定点確認する場合は以下のようなコマンドが使いやすいです。

watch -n 5 'echo "$(cat /proc/sys/net/netfilter/nf_conntrack_count) / $(cat /proc/sys/net/netfilter/nf_conntrack_max)" | bc -l'

切り戻しが必要になった場合、sysctlの変更は即座にロールバックできます。

sysctl net.netfilter.nf_conntrack_max=<元の値>

ただしnf_conntrack_maxを現在のnf_conntrack_countより小さい値に設定しようとするとエラーになります。事前に既存エントリを減らすか、段階的に下げる必要があります。タイムアウト値の切り戻しは同様にsysctlで即時適用できます。/etc/sysctl.d/配下のファイルを削除しておかないと、次回のsysctl –systemやOS再起動時に変更後の値が再適用される点に注意してください。modprobe.dの変更を切り戻す場合はファイルの削除と再起動が必要です。

2026年現行環境での差分と注意点

2026年時点の主要サポート対象はRHEL 9.x/CentOS Stream 9やUbuntu 24.04 LTSであり、カーネル5.14〜6.8系が広く使われています。nf_conntrackのsysctlインターフェース自体は概ね安定していますが、いくつかの注意点があります。

古いドキュメントでは/proc/sys/net/ipv4/netfilter/配下のパスが案内されていることがありますが、現在の標準は/proc/sys/net/netfilter/配下です。スクリプトやAnsibleプレイブックで古いパスを参照している場合は修正が必要です。conntrack-toolsパッケージのバージョンによってconntrackコマンドの出力フォーマットが変わる場合があるため、パイプで出力をパースしているスクリプトは事前に動作確認をしてください。

nftables環境（RHEL 9/Ubuntu 22.04以降のデフォルト）でもnf_conntrack機構自体は同じカーネルサブシステムを使います。ただしnftablesのflowtable（ファストパス機構）を有効にしている場合、conntrackエントリがオフロードされてnf_conntrack_countに反映されないケースがあります。モニタリングの際は、flowtableの有効/無効によって数値の意味が変わることを念頭に置いてください。

コンテナ・Kubernetes環境では特に注意が必要です。nf_conntrackはホスト側カーネルで動作するため、ノード上の全Pod・全コンテナの接続が同一テーブルを共有します。Podの数が増えるにつれてnf_conntrack使用量もスケールするため、ワーカーノード設計段階でPodあたりの想定接続数×最大Pod数を見込んだ値をnf_conntrack_maxに設定する必要があります。Kubernetes環境のノード設定はkubelet起動前にsysctlを適用する必要があり、cloud-initやnode provisioningスクリプトで管理するのが一般的なアプローチです。この設定漏れはクラスタ増設後にじわじわと顕在化するため、ノードテンプレートへの組み込みを標準化しておくことが運用上の重要な予防策になります。