皆さん、こんにちは！ネットワークの現場でパケットの息遣いを感じながら、今日もキーボードを叩いているNOCシニアエンジニアの○○（NOCシニアエンジニアとしての私の名前）です。
今回は、ネットワークのトラブルシューティングにおいて、まさに「探偵の目」となる強力なコマンド、netstat を深掘りしていきます。特に、TCPコネクションのさまざまな「状態」に焦点を当てて、それがネットワークの中でどんな意味を持つのか、どうやってトラブルの兆候を見つけるのかを、実世界の例えを交えながら、とことん優しく解説しますね。
「コネクション状態？TCP？なんだか難しそう…」と思ったあなた、大丈夫です！一歩ずつ、丁寧に紐解いていきましょう。パケットの旅を追体験するような、そんな気持ちで読んでみてください。
—
ネットワークの「会話」を覗き見！netstatで何がわかる？
皆さんは、普段インターネットを使うとき、意識せずともたくさんの「ネットワークの会話」をしています。Webサイトを見たり、チャットアプリを使ったり、動画をストリーミングしたり…これら全て、あなたのパソコンやスマホと、インターネットの向こう側にあるサーバーとの間で、たくさんの「メッセージ」がやり取りされているんです。
この「メッセージのやり取り」のことを、専門的には「コネクション（接続）」と呼びます。そして、このコネクションが今、どんな状況にあるのか？ちゃんと繋がっているのか？それとも途中で止まってしまっているのか？そんな「会話の状態」を教えてくれるのが、netstat コマンドなんです。
まるで、たくさんの電話回線が繋がっている電話交換所のオペレーターが、どの回線が通話中か、どの回線が呼び出し中か、一目でわかるようなイメージですね。
なぜコネクションの状態を知る必要があるの？
想像してみてください。
「Webサイトが表示されない！」
「アプリケーションがサーバーと通信できない！」
「なんだかネットワークが遅い気がする…」
こんな時、どこに原因があるのか見当もつかないと困りますよね。もしかしたら、アプリケーションがサーバーと繋がるための「窓口」が開いていないのかもしれないし、逆に相手から「窓口を閉めますよ」と言われているのに、いつまでも閉じずにリソースを消費しているのかもしれません。
netstat を使うことで、そんなネットワークの「声なき声」を聞き、トラブルの原因を特定する大きなヒントが得られるんです。
TCPコネクションって、そもそも何？〜郵便配達の旅〜
netstat で見るコネクションのほとんどは、「TCP」という種類のコネクションです。このTCPがどんなものか、まずは簡単に理解しておきましょう。
信頼性抜群！手紙が確実に届く「郵便配達」
ネットワークの世界には、大きく分けてTCPとUDPという二つの「通信プロトコル（通信ルール）」があります。
- UDP（User Datagram Protocol）:
これは例えるなら、「手紙をポストに投函するだけ」 のサービスです。手紙が相手に届いたかどうかの確認はしませんし、届かなければ再送もしてくれません。速いけど、信頼性はありません。
- TCP（Transmission Control Protocol）:
これこそ、私たちが普段使っている「郵便配達サービス」そのものです！
1. 手紙を送る前に、まず相手に「今から手紙を送ってもいいですか？」と挨拶をします。（これが「接続の確立」）
2. 相手が「OKです！」と返事をしたら、手紙のやり取りが始まります。
3. 送った手紙がちゃんと相手に届いたか、「届きましたよ！」という確認（ACK）をしてもらいます。
4. もし届かなければ、もう一度送ってくれます。
5. やり取りが終わったら、お互いに「もう手紙は終わりですね」と挨拶をして、接続を閉じます。（これが「接続の終了」）
どうでしょう？TCPは、まるで丁寧で責任感の強い郵便局員さんのようですよね。この「挨拶」や「確認」の仕組みがあるからこそ、私たちは安心してWebサイトを見たり、ファイルをダウンロードしたりできるわけです。
netstat は、このTCPという信頼性のある通信が、今どの段階にあるのかを教えてくれるんです。
netstatコマンド、いざ実践！
それでは、実際に netstat コマンドを使ってみましょう。
ターミナルやコマンドプロンプトを開いて、以下のコマンドを打ってみてください。
netstat -an-a: すべてのコネクションとリスニングポートを表示します。「active」の「a」と覚えてくださいね。-n: ホスト名やサービス名を数字で表示します。名前解決（DNS検索）をしないので、表示が速くなります。
たくさんの情報が出てきて、最初は「うわっ！」となるかもしれませんね。でも大丈夫、一つずつ見ていきましょう。
netstat出力結果の見方
netstat -an の出力は、だいたいこんな感じになっているはずです。
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN
tcp 0 0 192.168.1.100:54321 192.168.1.1:80 ESTABLISHED
tcp 0 0 192.168.1.100:54322 10.0.0.5:443 ESTABLISHED
tcp 0 0 192.168.1.100:54323 10.0.0.6:80 TIME_WAIT
tcp 0 0 192.168.1.100:80 192.168.1.101:45678 CLOSE_WAIT
udp 0 0 0.0.0.0:68 0.0.0.0:*各項目を簡単に見ていきましょう。
Proto: プロトコル（通信ルール）の種類です。ほとんどの場合tcpかudpが表示されます。Recv-Q: 受信キュー（Queue）に入っているデータ量です。相手から送られてきたけど、まだアプリケーションが処理しきれていないデータの量を示します。ここが大きいと、受信処理が追いついていない可能性があります。Send-Q: 送信キューに入っているデータ量です。アプリケーションが送りたいけど、まだネットワークに送れていないデータの量を示します。ここが大きいと、送信処理が遅れている可能性があります。Local Address: 自分自身のIPアドレスとポート番号です。Foreign Address: 相手の（通信している）IPアドレスとポート番号です。State: これが今回の主役！TCPコネクションの現在の状態を示します。- （
PID/Program name）: もしnetstat -anpのように-pオプションを付けると、そのコネクションを使っているプログラムのプロセスID（PID）やプログラム名も表示されます。これはトラブルシューティングで非常に役立ちます！
TCPコネクションの状態を深掘り！
さあ、いよいよ State の部分を詳しく見ていきましょう。郵便配達の例えを思い出しながら、一緒に旅を続けましょうね。
1. LISTEN (待機中)
- 状態の意味: サーバーが「いつでも接続を受け付けられますよ！」と、特定のポート（窓口）を開けて、クライアントからの接続要求を待っている状態です。
- 郵便配達の例え: 郵便局の窓口が「どうぞ、手紙をお出しください！」と開いている状態。お客さん（クライアント）が来るのを待っています。
- こんな時に見る: Webサーバー（80番ポートや443番ポート）、SSHサーバー（22番ポート）、データベースサーバーなど、外部からの接続を受け入れるサービスが起動している時に見られます。もしWebサーバーを起動しているのに
LISTEN状態になっていなければ、Webサーバーが正しく起動していない、または他の何かが同じポートを使っている可能性があります。
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN # 80番ポートでWebサーバーが待機中
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN # データベースがローカルからの接続を待機中0.0.0.0 は「どのIPアドレスからの接続も受け付けるよ」という意味です。
2. ESTABLISHED (接続確立)
- 状態の意味: クライアントとサーバーの間で、TCPコネクションが完全に確立され、データのやり取りが活発に行われている状態です。まさに「手紙のやり取り中」！
- 郵便配達の例え: 郵便局と相手先の家との間で、手紙のやり取りが滞りなく行われている状態。お互いに手紙を送ったり、受け取ったりしています。
- こんな時に見る: Webサイトを閲覧している時、SSHでサーバーにログインしている時、データベースに接続してクエリを実行している時など、通信が正常に行われている時に見られます。これがたくさんあるのは、システムが活発に使われている証拠です。
tcp 0 0 192.168.1.100:54321 192.168.1.1:80 ESTABLISHED # 自分のPCからWebサーバーに接続中
tcp 0 0 192.168.1.100:22 192.168.1.1:54322 ESTABLISHED # 自分のPCからSSHでサーバーにログイン中3. SYN_SENT, SYN_RECV (接続開始の挨拶中)
これは、TCPコネクションの開始（3-wayハンドシェイク）の途中の状態です。
SYN_SENT: クライアントがサーバーに「接続したいです！」という最初の挨拶（SYNパケット）を送って、サーバーからの返事を待っている状態です。- 例え: あなたが郵便局に「手紙を出したいです！」と声をかけたけど、まだ郵便局員さんが「どうぞ！」と返事をしていない状態。
SYN_RECV: サーバーがクライアントからの最初の挨拶を受け取り、「いいですよ！」という返事（SYN-ACKパケット）をクライアントに送って、クライアントからの最後の確認（ACKパケット）を待っている状態です。- 例え: 郵便局員さんがあなたに「どうぞ！」と返事をしたけど、あなたがまだ「ありがとう！」と言い終わっていない状態。
これらの状態が長時間続いたり、大量に発生したりする場合、接続先のサーバーが応答していない、ファイアウォールでブロックされている、ネットワーク経路に問題があるなどのトラブルの可能性があります。
4. FIN_WAIT1, FIN_WAIT2, CLOSING, LAST_ACK (接続終了の挨拶中)
これらは、TCPコネクションの終了（4-wayハンドシェイク）の途中の状態です。どちらか一方が「もう手紙のやり取りは終わりです」と挨拶（FINパケット）を送り、お互いに確認し合っている段階ですね。
FIN_WAIT1: 自分が「もう終わりです」と挨拶を送って、相手からの確認を待っている状態。FIN_WAIT2: 自分が「もう終わりです」と挨拶を送って、相手からも「OK、私も終わりです」という挨拶が来たけど、まだ相手からの最後の確認を待っている状態。CLOSING: お互いに同時に「もう終わりです」と挨拶を送り合った状態。LAST_ACK: 自分が「もう終わりです」と挨拶を送り、相手からも「OK」が来て、さらに自分が最後の確認を送って、その最後の確認が届くのを待っている状態。
これらの状態は、正常なコネクション終了の過程で一時的に見られるものです。短時間で消えるのが普通です。
5. TIME_WAIT (後片付けと再送に備える「猶予期間」)
- 状態の意味: TCPコネクションが完全に終了した後、しばらくの間、そのコネクションが使っていたポートを再利用せずに待機している状態です。
- 郵便配達の例え: 手紙のやり取りが全て終わり、郵便局の窓口を閉めました。でも、念のため「もし、相手から『最後の返事届いてないよ！』って来たらどうしよう…」と、しばらくの間、窓口の入り口で待機している状態です。この「念のため」の期間が
TIME_WAITです。 - なぜ必要？:
1. 古いパケットが迷い込むのを防ぐ: 通信中に遅延したパケットが、新しい同じポート番号のコネクションに誤って届いてしまうのを防ぎます。
2. 相手への最後の確認を確実にする: 自分が送った「接続終了の最終確認」が相手に届かなかった場合、相手は再送してきます。その再送に対応できるように、少しの間、情報を保持しています。
TIME_WAIT は、特にWebサーバーなどの大量の短いコネクションを捌くサーバーで頻繁に見られます。これは正常な動作です。ただし、あまりにも大量の TIME_WAIT が長時間残ると、ポート番号を使い果たしてしまい、新しいコネクションを張れなくなる可能性もゼロではありません（滅多にありませんが）。
大量の TIME_WAIT がシステムパフォーマンスに影響を与える場合は、OSのTCP設定（sysctl コマンドなど）で TIME_WAIT の時間を調整したり、再利用を許可したりすることも可能ですが、これはシステム全体に影響を与えるため、慎重な検討とテストが必要です。初学者のうちは「正常な状態」と理解しておけば大丈夫です。
6. CLOSE_WAIT (相手は終了したが、自分はまだ準備中)
- 状態の意味: 相手のサーバー（またはクライアント）から「もう終わりです」という接続終了の挨拶（FINパケット）を受け取ったにもかかわらず、自分自身のアプリケーションがまだそのコネクションを完全に閉じきれていない状態です。
- 郵便配達の例え: 相手の家から「もう手紙は終わりです」と連絡が来ました。でも、あなたは「ちょっと待って！まだ送りたかった手紙が残ってるんだ…」と、なかなか窓口を閉じられない状態です。相手はあなたが閉じるのを待っています。
- トラブルの兆候！:
CLOSE_WAIT が大量に、そして長時間にわたって表示され続ける場合、これはアプリケーションに問題がある可能性が高いです。
- アプリケーションがFINパケットを受け取ったにも関わらず、ソケットを閉じ忘れている（プログラムのバグ）。
- アプリケーションが処理に時間がかかりすぎて、コネクションを閉じられない。
- システムのリソース（メモリやCPU）が枯渇していて、アプリケーションが正常に動作できない。
ESTABLISHED の次に CLOSE_WAIT が大量にある場合、それは「相手はさっさと片付けてくれたのに、こっちがダラダラしてて、相手を待たせてしまっている」状態なんです。これはトラブルシューティングにおいて、特に注意すべきサインですよ！
実践的なnetstatコマンドの活用例
いくつか実用的な netstat の使い方を見ていきましょう。
1. どのポートでサービスが待機しているか確認する
WebサーバーやSSHサーバーがちゃんと起動しているか確認したい時によく使います。
netstat -anp | grep LISTEN-p: プログラム名とPIDを表示します。grep LISTEN:LISTEN状態の行だけを絞り込みます。
出力例:
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1234/sshd
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 5678/nginx
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 9012/mysqldこれで、SSH（22番）、Nginx（Webサーバー、80番）、MySQL（データベース、3306番）がそれぞれどのPIDで動いているか、すぐにわかりますね。
2. 特定のIPアドレスとのコネクションを確認する
特定のサーバーやクライアントとの通信状況を見たい時に便利です。
netstat -an | grep "192.168.1.100" # 例: 192.168.1.100との通信を探す3. CLOSE_WAIT が大量に発生していないか確認する
異常な CLOSE_WAIT が増えていないか、定期的にチェックする習慣をつけると良いでしょう。
netstat -an | grep CLOSE_WAIT | wc -lwc -l: 行数をカウントします。
この数値が常に増え続けていたり、異常に高い場合は、アプリケーションのバグやリソース不足を疑うべきです。
4. ss コマンドも知っておこう！
実は、Linuxの新しいバージョンでは netstat の代わりに ss (socket statistics) コマンドを使うことが推奨されています。ss は netstat よりも高速で高機能です。基本的な使い方は netstat と似ています。
ss -ant # -a:all, -n:numeric, -t:tcp (UDPは-u)
ss -ant | grep ESTABLISHED
ss -ant | grep CLOSE_WAITもしあなたの環境で netstat が遅いと感じたり、より詳細な情報が必要になったら、ぜひ ss コマンドも試してみてください。
トラブルシューティングの視点〜NOCエンジニアの独り言〜
私自身、夜中のアラートで叩き起こされて「サーバーに繋がらない！」と叫ばれるたびに、まず確認するのは netstat の出力です。
- 「Webサーバーに繋がらない！ポート80がLISTENしてない…」
→ Webサーバープロセスが落ちてないか、設定ファイルに誤りがないか確認。
- 「アプリケーションがタイムアウトする！ESTABLISHEDが全然増えない…」
→ 相手のサーバーがダウンしているか、途中のファイアウォールでブロックされている可能性を疑う。
- 「謎のCPU高騰！CLOSE_WAITが数万件…」
→ これはもう、アプリケーションのバグか、データベース接続プールなどのリソース管理の問題を疑う鉄板パターンですね。開発チームに連携して、コードレビューをお願いすることになります。
このように、netstat が教えてくれるTCPの状態は、まるでネットワークの健康診断書のようなものです。それぞれの状態が持つ意味を理解することで、「今、このネットワークで何が起きているのか？」という問いに、一歩近づくことができます。
まとめ
今回は netstat コマンドを使って、TCPコネクションのさまざまな状態を覗き見する方法について解説しました。
netstat -anでコネクションの状態がわかる。LISTENは「受付中」。ESTABLISHEDは「通信中」。TIME_WAITは「安全のための猶予期間」（正常）。CLOSE_WAITは「相手は終了したが、自分はまだ…」（トラブルの兆候！）。
最初は覚えることが多いと感じるかもしれませんが、実際に手を動かしてコマンドを打ち、自分のPCやサーバーのコネクション状態を観察してみてください。そうすれば、少しずつ「なるほど、こういうことか！」という感覚がつかめてくるはずです。
ネットワークのトラブルシューティングは、まるで謎解きのようです。今回の netstat コマンドは、その謎を解くための強力な「手がかり」の一つです。ぜひ、日々の運用やトラブル発生時に活用して、ネットワークの奥深さを体験してみてください。
それでは、また次の記事でお会いしましょう！
NOCシニアエンジニアの○○でした！
コメント