【入門編】 TCP接続ステータス(LISTEN, SYN_RECV, ESTABLISHED, TIME_WAIT等)の診断 – トラブルシューティング＆ネットワーク運用監視実践ガイド

こんにちは！データセンターの隅っこで、日々モニターの明かりと格闘しているNOCエンジニアの私です。

ネットワークの世界に足を踏み入れると、次から次へと新しい用語や呪文のようなコマンドが出てきて、最初は面食らってしまいますよね。「なんだか難しそう…」と、そっとブラウザを閉じたくなる気持ち、痛いほどよく分かります。一歩ずつ、焦らずに理解していきましょう！

さて、今回はインフラ運用の現場で避けて通れない、かつトラブルシューティングの「花形」とも言えるテーマを取り上げます。それが、サーバーの裏側で今何が起きているのかを丸裸にする TCP接続ステータス（状態） です。

「なんだかサイトの読み込みが遅い」「APIの接続数がすぐに上限に達してしまう」——そんなトラブルに直面したとき、私たちが真っ先に頼るのが ss や netstat といったコマンドです。画面にズラリと並ぶ LISTEN や ESTABLISHED、そして TIME_WAIT といった英単語。これらが一体何を意味しているのか、そしてなぜそれが長期間残り続けてしまうのか。

今回は、難しいパケットの構造やビットの計算はいったん脇に置いて、私たちが普段暮らしている「現実世界の仕組み」に例えながら、じっくりと紐解いていきたいと思います。

—

1. TCPってなに？身近な「確実な連絡網」に例えてみよう

まず、TCP（Transmission Control Protocol）という言葉の基本からおさらいです。

インターネットの世界で、データを確実にあて先まで届けるための「お約束（プロトコル）」の一つがTCPです。よく引き合いに出されるUDPが「手紙をポストに放り込むスタイル（届いたかどうかは気にしない）」だとしたら、TCPは「必ず相手が受け取ったことを確認しながら、一歩一歩確実にやり取りする書留郵便」のようなものです。

この「確実なやり取り」をするために、TCPは通信を始める前、途中、そして終わるときに、必ずお互いの状態を確認し合います。これがまさに、今回主役となる 「TCP接続ステータス」 なんです。

サーバーの中で今、誰と誰が手紙のやり取りをしているのか。それをこっそり覗き見る窓口が、これから紹介するコマンドたちです。

—

2. 現場の必須ツール：ss コマンドで今の状態を覗き見してみよう

昔は netstat というコマンドが定番でしたが、現代のLinuxサーバーでは、より高速で詳細な情報を取得できる ss コマンドが主流になっています。「Socket Statistics」の略ですね。

まずは、自分のサーバーで今どんな接続が生きているのか、実際にコマンドを叩いて確認してみましょう。実務で本当によく使う基本の形はこちらです。

# 現在のすべてのTCP接続を、数値（名前解決をしない）で分かりやすく一覧表示する
ss -t -a -n

-t : TCPの接続だけに絞り込みます。
-a : 今まさに通信しているものだけでなく、待ち受け中のものも含めてすべて表示します。
-n : IPアドレスやポート番号を、DNSの名前解決をせずに数字のまますばやく表示します（現場では名前解決を待つと遅いので -n は必須テクニックです！）。

このコマンドを実行すると、画面の端っこに LISTEN や ESTABLISHED といったステータスが表示されます。では、それぞれのステータスが「現実世界で何をしている状態なのか」を順番に見ていきましょう。

—

3. 主要なステータスと、その裏側にあるリアルな挙動

① LISTEN （リスン・待ち受け中）

現実世界での例え： 「お店のシャッターを開けて、お客さんが来るのを待ち構えている店員さん」
技術的な意味： Webサーバー（NginxやApacheなど）が起動し、「いつでもリクエストを受け付けられるよ！」と特定のポート（例えばHTTPなら 80 や 443）を開いてスタンバイしている状態です。これがいないと、誰もホームページを見にこれません。

② SYN_RECV （シン・レシーブ・接続要求の受付中）

現実世界での例え： お客さんが店に入ってきて、「すいません、注文いいですか？」と声をかけられ、「はい、少々お待ちくださいね」と店員がメモ帳を構えた瞬間。
技術的な意味： 相手から「お話しませんか？（SYNパケット）」という最初の挨拶を受け取り、「こちらこそよろしくお願いします（SYN-ACKパケット）」と返事をして、相手からの最終返事を待っている非常に短い間の状態です。

③ ESTABLISHED （エスタブリッシュト・通信中）

現実世界での例え： カウンター席に座ったお客さんと店員さんが、実際にメニューを決め、料理を注文し、楽しく会話をしている真っ最中の状態。
技術的な意味： 無事にハンドシェイク（事前の挨拶）が終わり、お互いにデータ（画像やテキストなど）をガンガン送り合っている、もっとも健全でアクティブな状態です。サーバーの負荷が高いときは、ここにある接続数が何千、何万へと膨れ上がります。

④ TIME_WAIT （タイム・ウェイト・後片付け中）

現実世界での例え： お客さんがお会計を済ませて店を出た後、店員さんがテーブルを綺麗に拭いて、レシートの控えを整理している時間。
技術的な意味： 通信が終わった後、インターネットのどこかの回線に「最後の挨拶のパケット」が迷い込んでいないか、念のために一定時間（通常Linuxでは60秒程度）だけ名残りを残して待っている状態です。

—

4. トラブル発生！「ステータスが長期間残留する」原因と究明プロセス

ここからが、シニアエンジニアの腕の見せ所です。
正常であれば、一時的に通り過ぎるはずのステータスが、なぜかサーバー上で何千件も溜まり続け、やがてサーバーがフリーズしたり、新規の接続を受け付けなくなったりするトラブルが現場ではよく起きます。

よくある2大「残留トラブル」の正体と、その追いかけ方を紐解いていきましょう。

ケースA：SYN_RECV が大量に残留する（SYNフラッド攻撃や高負荷）

ある日突然、サーバーが重くなり、ss コマンドで確認すると SYN_RECV が画面を埋め尽くしていることがあります。

原因： 相手（クライアント）が「お話しましょう」と挨拶だけして、わざと最後の返事をしない、あるいは存在しない偽のIPアドレスから大量の挨拶が送りつけられている状態です（いわゆるDDoS攻撃の一種であるSYNフラッド攻撃、または悪質なクローラーの暴走）。サーバーは「返事が来るはずだ」とメモ帳を開いたまま待ち続けるため、やがて新しいお客さんを迎えられなくなります。
究明と対策：

まずはどのIPアドレスから大量の SYN_RECV が来ているのかを、以下のコマンドで特定します。

# SYN_RECVの状態になっている接続のIPアドレスを集計して、多い順に上から10件表示する
ss -n state syn-recv | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -n 10

特定の怪しいIPアドレスからであれば、ファイアウォール（iptables や nftables）でそのIPをブロックします。また、OSの設定（カーネルパラメータ）で、半端な接続を早めに切り捨てる設定（tcp_syncookies など）を有効にしているかも確認ポイントです。

ケースB：TIME_WAIT が大量に残留する（ソケット枯渇問題）

APIサーバーやマイクロサービス間の通信が多い環境でよくあるのが、TIME_WAIT が数万件単位で残り続ける現象です。

原因： サーバー側から頻繁に短い通信を「プツッ、プツッ」と切断していると、先ほど説明した「後片付けの時間（TIME_WAIT）」のステータスが次々と溜まっていきます。Linuxが同時に扱えるポートの数には限界があるため、このお片付けが追いつかなくなると、新しい通信ができなくなります（これを「ポート枯渇」と呼びます）。
究明と対策：

現在、どれくらいの TIME_WAIT がいるのかを数えてみましょう。

# 現在のTIME_WAITの総数をカウントする
ss -t -n state time-wait | wc -l

もしこれが数万件に達している場合、根本的な解決策として、アプリケーション側でコネクションを毎回切断するのではなく、「コネクションプーリング（接続を使い回す仕組み）」 を実装するのが定石です。
また、どうしてもOSレベルで急場をしのぎたい場合は、/etc/sysctl.conf などのカーネルパラメータで、TIME_WAIT の状態にあるソケットを再利用できるように設定します（実務の現場ではお馴染みの処方箋です）。

# /etc/sysctl.conf に追記する設定例（TIME_WAITの再利用を許可）
net.ipv4.tcp_tw_reuse = 1

※設定を反映した後は、sudo sysctl -p を実行するのを忘れないでくださいね！

—

5. おわりに：パケットの流れを想像できるようになれば、もう怖くない！

いかがでしたでしょうか？
一見すると難解な ss コマンドやTCPのステータスも、「サーバーというお店の中で、お客さんと店員さんがどうやり取りしているか」という視点に置き換えてみると、ぐっと親しみやすくなったのではないでしょうか。

トラブルシューティングの基本は、「今、何がどこで渋滞しているのか」を正確に観測すること です。画面の向こう側で、目に見えないパケットたちがどんなドラマを繰り広げているのか。そのストーリーを頭の中でスラスラと描けるようになれば、どんな障害が起きてびくともしない、頼もしいインフラエンジニアに一歩近づいています。

日々の運用監視の中で、ぜひ今回のコマンドを試してみてくださいね。それでは、また次回のNOC技術コラムでお会いしましょう！