【実務・中級編】 netstatによるTCP接続状態(ESTABLISHED, TIME_WAIT, CLOSE_WAIT等)の確認 – トラブルシューティング＆ネットワーク運用監視実践ガイド

夜中の3時。データセンターの冷気が肌を刺すNOCルームで、突然鳴り響くアラート音。モニタリング画面には、APIサーバーのレスポンスタイム急上昇と、接続拒否（Connection Refused）のログが滝のように流れている――。

Web APIの設計やインフラ運用に携わるエンジニアなら、一度はこの生きた心地がしない瞬間を経験したことがあるはずです。「コードは正常に動いているはずなのに、なぜ？」。その答えの多くは、見えないパケットの往来の果て、OSのカーネル内にあるTCPソケットの「状態（ステート）」に隠されています。

今回は、数々の修羅場をくぐってきたシニアエンジニアの視点から、netstat（あるいはその後継であるss）を駆使してTCPのステートマシンを読み解き、接続リークやポート枯渇の根本原因を秒速で特定する実践的なノウハウを伝授します。

—

1. なぜTCPの「状態」を理解しなければならないのか？

Webアプリケーションの開発現場では、HTTPやgRPCといったレイヤーの「リクエストとレスポンス」に意識が向きがちです。しかし、その下層で黙々とコネクションを維持・切断しているのはTCPです。

TCPは信頼性を担保するため、3wayハンドシェイクによる接続確立から、4wayハンドシェイク（またはそれに準ずるシーケンス）による切断まで、厳密なステートマシン（状態遷移）を持っています。

[クライアント]                         [サーバー]
      | ----- SYN ---------------> |  (SYN_RECV)
      | <---- SYN-ACK ------------ |  (ESTABLISHED)
      | ----- ACK ---------------> |  (ESTABLISHED)
      |                            |
      | (データ送受信)             |
      |                            |
      | ----- FIN ---------------> |  (CLOSE_WAIT)
      | <---- ACK ---------------- |  (LAST_ACK)
      | <---- FIN ---------------- |  (TIME_WAIT)
      | ----- ACK ---------------> |  (CLOSED)

このステートの遷移が正常に行われず、特定の状態でソケットがフリーズしたり、解放が追いつかなくなったりする現象こそが、いわゆる「接続リーク」や「ポート枯渇（Port Exhaustion）」の正体です。

—

2. 現場で押さえるべき主要なTCPステートと危険信号

Linux等のネットワークスタックを覗き見るとき、netstat -antやss -antコマンドが叩き出すアルファベットの羅列は、トラブルシューティングの羅針盤となります。実務で特に注意すべき主要なステートを整理しておきましょう。

ESTABLISHED（確立状態）

文字通り、パケットの送受信が可能なアクティブな状態です。ここにあるコネクション数が多いこと自体は正常ですが、「想定以上のリクエストが来ていないか」「アイドル状態のまま放置されているコネクションがないか」を監視する必要があります。

CLOSE_WAIT（切断待ち）

ここからがトラブルシューティングの真骨頂です。
CLOSE_WAITは、「リモート側（相手）から切断要求（FIN）を受け取ったが、こちらのアプリケーション層がまだ切断処理（ソケットのクローズ）を完了していない状態」を示します。
この状態が大量に発生している場合、アプリケーションのコードに致命的なバグがあります。例えば、HTTPクライアント側でレスポンスボディを最後まで読み切らなかったり、DBや外部APIとのコネクションを明示的にclose/releaseしていなかったりするケースが典型的です。

TIME_WAIT（時間待ち）

接続を能動的に切断した側（Active Closer）が、ネットワーク上に迷子になった遅延パケットが将来の新しいコネクションに影響を与えないよう、一定時間（通常は2倍のMSL、Linuxではデフォルトで60秒間）待機する状態です。
アクセスが殺到するAPIサーバーやリバースプロキシでは、このTIME_WAITが数万単位で蓄積し、一時的なエフェメラルポート（クライアント側の一時ポート）の枯渇を引き起こすことがあります。

—

3. 実践：netstat / ss コマンドによるソケット診断の極意

百聞は一見に如かず。実際に障害時のサーバーにログインしたと仮定して、現場で使えるコマンドのレシピを見ていきましょう。

現代のスタンダード：ss コマンドの活用

現代のLinuxディストリビューションでは、高速かつ詳細な情報を取得できる ss コマンドが netstat の後継として推奨されています。

# 全てのTCPソケットのステートを数値形式（名前解決を省略して高速化）で一覧表示
ss -ant

状態別にソケット数を集計して傾向を掴む

障害発生時、どのステートが異常値を示しているかを一目で把握するためには、awk や sort を組み合わせたワンライナーが非常に有効です。

# 現在のTCP接続ステートごとのカウントを集計する
ss -ant | awk 'NR>1 {print $1}' | sort | uniq -c | sort -nr

【出力例の読み方】

4520 TIME_WAIT
    890 ESTABLISHED
    312 CLOSE_WAIT
     12 LISTEN

この出力結果を見た瞬間、ベテランエンジニアなら「CLOSE_WAITが300を超えている。アプリケーション層のコネクションリークだな」と即座にアタリをつけることができます。

—

4. コード側の原因と対策：なぜ CLOSE_WAIT は溜まるのか？

前述の通り、CLOSE_WAIT の多発はアプリケーションの怠慢（リソース解放漏れ）を意味します。具体的なPythonのコード例を挙げて、そのメカニズムと対策を解説します。

❌ 悪い例：レスポンスを読み捨ててコネクションを放置する

外部APIを叩く際、レスポンスのストリームを明示的に閉じないと、TCPのFINパケットを受け取った後もソケットが宙ぶらりんになります。

import urllib.request

# 悪い例：レスポンスのコンテキストマネージャやcloseを行わない、または途中で例外が発生する
for i in range(1000):
    try:
        response = urllib.request.urlopen("http://api.example.com/data")
        data = response.read()
        # response.close() が呼ばれる前に別の処理で落ちると、CLOSE_WAITの温床になる
    except Exception as e:
        print(f"Error: {e}")

⭕ 良い例：コンテキストマネージャで確実にリソースを解放する

近年の言語やライブラリ（Pythonの requests や Node.js の fetch など）では、コンテキストマネージャや適切なコネクションプーリングを使用することが鉄則です。

import requests

# 良い例：requestsのセッションとコンテキストマネージャを使用する
# これにより、HTTP通信終了後に確実にソケットが適切にクローズ/返却される
session = requests.Session()

for i in range(1000):
    try:
        # timeoutを設定し、コネクションがダラダラ残り続けるのを防ぐ
        with session.get("http://api.example.com/data", timeout=3.0) as response:
            response.raise_for_status()
            data = response.json()
    except requests.RequestException as e:
        print(f"Network Error: {e}")

—

5. インフラ・カーネルパラメータのチューニング（TIME_WAIT対策）

アプリケーション側を修正してもなお、アクセス数が秒間数千件を超えるような超高負荷環境では、どうしても TIME_WAIT によるポート枯渇が問題になります。その場合は、Linuxカーネルパラメータ（/etc/sysctl.conf）のチューニングで耐性を上げます。

以下の設定は、NOCやインフラエンジニアが必ずと言っていいほど投入する定番の処方箋です。

# /etc/sysctl.conf の設定例

# TIME_WAIT 状態のソケットを、安全な範囲で素早く再利用する（IPv4用）
net.ipv4.tcp_tw_reuse = 1

# エフェメラルポート（クライアント側のポート範囲）を拡張し、枯渇しにくくする
net.ipv4.ip_local_port_range = 1024 65535

# TCPのFIN-WAIT-2タイムアウト時間を短縮し、ゾンビコネクションを掃除する
net.ipv4.tcp_fin_timeout = 15

設定を反映させるためには、以下のコマンドを実行します。

# 設定を即時反映させる
sudo sysctl -p

*(※ tcp_tw_reuse は安全に設計されていますが、ネットワークトポロジーやNAT環境によっては副作用を考慮する必要があるため、ステージング環境等で十分に検証してから本番投入してください)*

—

6. まとめ：トラブルシューティングは「足元（ステート）」から見よ

障害対応の現場において、パケットキャプチャ（tcpdumpなど）をいきなり仕掛けるのは、広大な干草の山から針を探すようなものです。

まずは落ち着いてサーバーにログインし、ss コマンドでTCPのステートを俯瞰する。

  • CLOSE_WAIT が多いなら -> アプリのコード（リソース解放漏れ）を疑う
  • TIME_WAIT が多いなら -> アーキテクチャ（コネクションプールの欠如）やカーネルパラメータを疑う

この道筋を頭に叩き込んでおくだけで、深夜の障害対応で冷汗をかく時間は劇的に減り、スマートに原因を突き止められるはずです。ネットワークとコードの境界線にあるステートマシンの息吹を、ぜひ日々の運用でも感じ取ってみてください。

スポンサーリンク

コメント

タイトルとURLをコピーしました