FIN_WAIT_1が長時間残る原因と実践的な解決方法

FIN_WAIT_1 が増え続ける状態は、 TCP切断が正常に完了していないことを示します。

放置すると

• ファイルディスクリプタ枯渇
• コネクション枯渇
• 新規通信不能

につながるため、確実な対処が必要です。

本記事では、 FIN_WAIT_1 が長時間残る理由と、 実務での切り分け手順を解説します。

FIN_WAIT_1の状態を正確に把握する

件数と接続先を特定

ss -ant state fin-wait-1

✔ 同一IP・同一ポートに集中している場合は相手側起因の可能性が高い

対策① 相手プロセスが応答不能な場合

確認手順

# 相手ホストに疎通確認
ping 接続先IP

# アプリポート疎通
nc -vz 接続先IP port番号

解決策

• 相手プロセス再起動
• OOM / 高負荷があればリソース増強

ポイント： FIN_WAIT_1 は「こちらが悪い」とは限らない。相手の死活確認が最優先。

対策② ファイアウォール・LBでACKが破棄されている場合

確認すべきポイント

• stateful firewallのセッションタイムアウト
• LBの idle timeout

具体的対応

• LB idle timeout > アプリのKeepAlive
• FWで FIN / ACK を許可

✔ LB配下では FIN_WAIT_1大量発生＝timeout不整合 が多い

対策③ 非対称ルーティングの修正

確認

ip route get 接続先IP

送信経路と返信経路が異なる場合、ACKが届かない。

解決策

• ルーティングを固定
• SNAT/DNAT構成を見直す

対策④ パケットロス・再送が発生している場合

再送確認

ss -s
netstat -s | grep retrans

恒久対策

• NW帯域・MTU確認
• 輻輳ポイントの解消

最終手段：OSレベルでの切断促進（暫定対処）

再送回数短縮

sysctl -w net.ipv4.tcp_retries2=8

⚠ 根本原因を直さずにこれだけ行うのはNG

やってはいけない対処

• 原因特定せず sysctl だけ変更
• FIN_WAIT_1をFIN_WAIT_2と混同
• アプリ改修を検討しない

実務向けチェックリスト

• 接続先IPは特定できているか
• 相手プロセスは生きているか
• FW/LB timeoutと整合しているか
• 再送・パケットロスはないか

まとめ

FIN_WAIT_1 は 「通信設計の歪み」を可視化する重要なシグナルです。

数を減らすことではなく、 なぜACKが返らないかを突き止めることが、 唯一の正解です。