FWセッションタイムアウトが引き起こす断続的通信断の正体【なぜ“時間が経つと切れる”のか】

通信は最初は正常。

しかし、

• 数分後に突然切れる
• 一定時間操作しないと接続が落ちる
• 再接続すれば直る
• サーバにもエラーは出ていない

このような断続的通信断は、

FWセッションタイムアウト

が原因であることが非常に多いです。

本記事では、

• セッションタイムアウトの仕組み
• なぜ断続的に見えるのか
• 確定診断の方法
• 正しい対処法
• 設計で防ぐ方法

を、現場レベルで解説します。

まず理解すべきこと：FWは通信を“覚えている”

ステートフルFWは、通過する通信を

セッションテーブル

で管理しています。

このテーブルには、

• 送信元IP
• 宛先IP
• ポート番号
• TCP状態
• 最終通信時刻

が記録されます。

そして一定時間通信がないと、

セッションは削除されます。

なぜ「断続的」に見えるのか

典型的な流れ：

1. TCP接続確立
2. しばらく通信なし（アイドル状態）
3. FWがセッションを削除
4. アプリが再び通信しようとする
5. FWにセッションが存在せず破棄

この時、

• クライアント側ではタイムアウト
• サーバ側にはログが出ない

という状況になります。

再接続すると新しいセッションが作られるため、

「一時的な不具合」に見える

のです。

よくある発生パターン

① Webアプリで一定時間後にエラー

• 管理画面を放置
• 操作再開で500エラー

② DB接続プールで突然エラー

• アイドル時間が長い
• クエリ実行時に接続失敗

③ VPNやRDPが突然切断

• 操作していない時間がある

診断方法：本当にタイムアウトか確認する

① 発生までの時間を測る

例：

• 常に5分後に切れる
• 30分後に必ず切断

→ FWタイムアウト値と一致すれば可能性大

② tcpdumpで確認

tcpdump -nn host 対向IP and port ポート番号

切断時に確認するポイント：

• RSTが返っているか
• 無応答で再送していないか

多くの場合、

再送のみで応答がない

という挙動になります。

③ FWのセッション確認

該当通信のセッションが存在するか確認。

通信失敗直後にセッションが存在しなければ、

タイムアウトで削除された可能性が高い

TCPタイムアウトの基礎知識

FWには複数のタイムアウトがあります。

• TCP Established
• TCP SYN
• UDP
• ICMP

特に重要なのは

TCP Establishedタイムアウト

です。

一般的な値：

• 300秒（5分）
• 900秒（15分）
• 3600秒（1時間）

解決方法

① FWタイムアウト値を延長する

最も単純な方法。

ただしセッションテーブル容量とのバランスが必要。

② アプリ側でKeepAliveを有効化

一定間隔でパケットを送ることで、

セッションが維持されます。

例：

• TCP keepalive
• HTTP keep-alive
• DBのheartbeat設定

③ LBやProxy経由の場合の確認

FWだけでなく、

• ロードバランサ
• リバースプロキシ

にもタイムアウト設定があります。

FWより短い場合、そこで切断されます。

解決したと言える状態

• 一定時間放置後も通信が継続する
• 再送が発生しない
• セッションが安定維持される
• アプリログに接続エラーが出ない

再発防止の設計ポイント

• アプリのアイドル時間を把握する
• FWタイムアウト値を明文化する
• KeepAlive設計を標準化する
• セッション数上限とバランスを取る

まとめ

FWセッションタイムアウトによる断続的通信断は、

「通信が止まった」のではなく、「FWが忘れた」

という現象です。

原因は偶発的ではありません。

時間と一致するなら、必ずタイムアウトを疑う。

構造を理解すれば、確実に解決できます。