エフェメラルポート枯渇の見抜き方と対処法【TIME_WAITとの関係を理解する】

Linuxサーバーで「突然外部通信ができなくなった」「再起動すると一時的に直る」 といった障害の原因として、見落とされがちなのが エフェメラルポート枯渇です。 本記事では、発生原理・見抜き方・具体的な対処法までを実務視点で解説します。

エフェメラルポートとは何か

エフェメラルポート（Ephemeral Port）とは、クライアント通信時に OSが一時的に自動割り当てする送信元ポート番号のことです。

• HTTP / HTTPS / DB / API通信などで使用
• 通信ごとにランダムなポートが割り当てられる
• 通信終了後もしばらく解放されない

Linuxでは通常、以下の範囲が使用されます。

cat /proc/sys/net/ipv4/ip_local_port_range
# 例: 32768 60999

この範囲内のポートを使い切ると、新しい通信が張れなくなります。

エフェメラルポート枯渇が起きる仕組み

最大の原因は、TIME_WAIT状態の大量発生です。

TIME_WAITとは

TCP通信終了後、同じポート・コネクションの再利用を防ぐために 一定時間保持される状態です。

• 通常 60秒（2MSL）程度
• この間、ポートは使用不可

短命な通信を大量に繰り返すと、TIME_WAITが急増し、 結果としてエフェメラルポートが枯渇します。

よくある発生シナリオ

• HTTP/HTTPSで毎回コネクションを張り直す設計
• DB接続プール未使用
• 外部APIへの高頻度リクエスト
• ロードテスト・バッチ処理の同時実行
• NAT配下での大量通信

障害時の典型的な症状

• 外部通信のみ失敗する
• connect timeout が多発
• 再起動すると一時的に復旧
• FWやNWに異常が見つからない

エフェメラルポート枯渇の見抜き方

① TIME_WAIT数の確認

ss -tan | grep TIME-WAIT | wc -l

数千〜数万レベルで増加していれば要注意です。

② 使用中ポート数の確認

ss -tan | awk '{print $4}' | awk -F: '{print $NF}' | sort | uniq | wc -l

③ ポート範囲の確認

sysctl net.ipv4.ip_local_port_range

一時的な回避策（即効性あり）

① ポート範囲を拡張する

sysctl -w net.ipv4.ip_local_port_range="10000 65535"

② TIME_WAITの再利用を許可

sysctl -w net.ipv4.tcp_tw_reuse=1

※ 外向き通信が中心のサーバーのみ推奨

根本対策（必ず行うべき）

① コネクション再利用（KeepAlive）

• HTTP Keep-Alive 有効化
• HTTP/2の利用

② DB / API 接続プールの導入

Javaの場合、HikariCPなどの利用が必須です。

③ 短命TCP設計をやめる

• リクエストごとに接続しない
• バッチ処理の並列数制御

設計段階でのチェックポイント

• 1秒あたりの新規TCP接続数
• TIME_WAIT保持時間
• 同時実行数 × 接続数
• NAT配下かどうか

TIME_WAITとの違いまとめ

項目	TIME_WAIT	エフェメラルポート枯渇
状態	TCP状態	OSリソース枯渇
原因	正常なTCP終了	大量のTIME_WAIT
対策	削減・再利用	設計見直し必須

まとめ

エフェメラルポート枯渇は、NW・FW・アプリすべてが正常に見える中で 突然発生する非常に厄介な障害です。

「TIME_WAITが多い＝悪」ではなく、設計が原因という視点を持ち、 短命TCPを生まない構成に見直すことが最重要です。