Linuxサーバーでネットワーク遅延や接続エラーが増えた際、 ss や netstat を確認すると TIME_WAIT が大量に残っているケースがあります。
TIME_WAIT自体は異常ではありませんが、 数千〜数万単位で溜まると実害が出る状態になります。
本記事では、TIME_WAITの仕組みから、 大量発生する典型原因、 やってはいけない対処、 安全な対策・設計指針までを実務目線で解説します。
TIME_WAITとは何か
TIME_WAITとは、TCPコネクションを正常終了した後に一定時間保持される状態です。
主な目的は以下の2点です。
- 遅延パケットを誤って次の通信で使わないため
- 相手からの再送FINに正しく応答するため
つまりTIME_WAITはTCP仕様上、必要な状態です。
TIME_WAITが大量発生する典型的な症状
- 新規TCP接続が遅い／失敗する
- アプリケーションが断続的に通信エラー
- ファイルディスクリプタ枯渇が発生する
- エフェメラルポート不足
特にクライアント側サーバーで影響が顕著です。
TIME_WAITの確認方法
現在のTIME_WAIT数
ss -tan state time-wait | wc -lまたは
netstat -an | grep TIME_WAIT | wc -lポート使用状況
ss -tan state time-wait接続先IPやポートが偏っていないかを確認します。
TIME_WAITが大量発生する原因
① 短時間で大量のTCP接続を作っている
- HTTPリクエストごとに新規接続
- DB接続を毎回作って即切断
KeepAliveやコネクションプール未使用が典型原因です。
② クライアント側がコネクションを切っている
TIME_WAITは最後にFINを送った側に残ります。
- AP → DB 接続
- AP → 外部API
多くの場合、アプリケーションサーバー側にTIME_WAITが集中します。
③ ロードテスト・バッチ処理
- 負荷試験直後
- 大量並列バッチ実行後
短時間に大量の通信が発生すると一気にTIME_WAITが増えます。
TIME_WAITが「問題」になる条件
以下の状態になって初めて対策が必要です。
- エフェメラルポート枯渇
- FD枯渇と同時発生
- 通信エラーが実際に出ている
単に数が多いだけではチューニング不要な場合もあります。
やってはいけない対処
① tcp_tw_recycle を有効にする
net.ipv4.tcp_tw_recycle = 1これは現在のLinuxでは非推奨・削除済みです。
- NAT環境で通信が壊れる
- 一部クライアントと通信不能
② 無理にTIME_WAITを消そうとする
TIME_WAITを即座に消す設定はTCPの安全性を壊します。
「減らす」ではなく増えない設計が重要です。
安全な対策①：接続の再利用
HTTP KeepAlive
- nginx keepalive
- Apache KeepAlive On
接続回数そのものを減らすのが最も効果的です。
DBコネクションプール
- HikariCP
- DBCP
毎回connect/disconnectしない設計にします。
安全な対策②：エフェメラルポート拡張
現在の範囲確認
cat /proc/sys/net/ipv4/ip_local_port_range拡張設定例
net.ipv4.ip_local_port_range = 10240 65535使用可能なポート数を増やすことで枯渇を防ぎます。
安全な対策③：tcp_tw_reuse
net.ipv4.tcp_tw_reuse = 1TIME_WAITソケットを安全に再利用する設定です。
- クライアント側で有効
- サーバー用途では慎重に
FD枯渇との関係
TIME_WAIT自体もファイルディスクリプタを消費します。
以下が同時に起きている場合は要注意です。
- TIME_WAIT増加
- FD使用数増加
- 新規接続失敗
FD設定と併せて対策が必要です。
設計・運用のベストプラクティス
- 短命TCP接続を作らない
- KeepAlive / Poolingを前提設計
- TIME_WAIT数は「異常」ではなく「傾向」で見る
- ロードテスト後に必ず確認
まとめ
TIME_WAITは正常なTCP動作の結果です。
問題なのはTIME_WAITそのものではなく、 短時間で大量の接続を作る設計です。
設定で無理に抑え込むのではなく、 接続設計を見直すことが最も安全で効果的な対策です。
