FIN_WAIT_2が残り続ける原因と対処【TCP接続異常の正体】

LinuxサーバーでTCP接続を監視していると、 FIN_WAIT_2 が大量に残り続けるという状態に遭遇することがあります。

この状態は、

• 接続数の異常増加
• ポート枯渇
• 通信遅延

の前兆であることが多く、放置すると重大障害につながります。

本記事では、 FIN_WAIT_2 が残り続ける仕組みと、 正しい原因切り分け・対処方法を解説します。

FIN_WAIT_2とは何か

TCPは正常切断時に以下の状態遷移を行います。

ESTABLISHED
 → FIN_WAIT_1
 → FIN_WAIT_2
 → TIME_WAIT
 → CLOSED

FIN_WAIT_2 は、 自分が FIN を送信し、相手の FIN 待ち状態です。

FIN_WAIT_2が残る＝何が起きているか

つまり、

「自分は切断意思を示したが、相手が切断しない」

という状態です。

まず確認すべきコマンド

ss -ant | grep FIN-WAIT-2

接続先確認

ss -ant state fin-wait-2

原因① 相手側アプリが正常にcloseしない

概要

サーバー側がFINを送ったが、 クライアントが接続を閉じない。

典型例

• バグ
• 異常系処理ミス
• タイムアウト未実装

対処

• 相手アプリ修正
• 通信仕様見直し

原因② ロードバランサ・FWがFINを破棄

概要

途中経路でFINが破棄される。

典型例

• NAT装置
• LB
• FWセッション管理

対処

• タイムアウト調整
• 装置設定確認

原因③ アプリ設計ミス（片方向切断設計）

概要

片側だけcloseする設計。

対処

• 双方向close設計
• 通信仕様修正

原因④ OSタイムアウト設定

概要

FIN_WAIT_2の待機時間が長い。

確認

cat /proc/sys/net/ipv4/tcp_fin_timeout

対処

sysctl -w net.ipv4.tcp_fin_timeout=30

※ 根本解決ではない

やってはいけない対処

• timeout短縮だけで誤魔化す
• 再起動でリセット
• 状態無視運用

切り分けフロー

1. FIN_WAIT_2接続先確認
2. 相手アプリ調査
3. 経路装置確認
4. OS設定確認

FIN_WAIT_2が示す設計上の問題

この状態は、 通信仕様が非対称設計になっている ことを意味します。

多くの場合、 OSではなくアプリ設計の問題です。

まとめ

FIN_WAIT_2 が残り続けるのは、 TCPの異常ではなく、 通信設計の異常です。

状態遷移を理解すれば、 原因は必ず論理的に切り分けられます。