「繋がらない」を「見える」に変える。netstatが語るソケットの真実
深夜のデータセンター、冷房の唸る音の中で、画面に流れるログを眺めながらふと思う。「システムは嘘をつかない」。だが、その「真実」を教えてくれるのは、往々にしてOSが吐き出す無機質なステータス情報だ。
Web APIのレスポンスが遅い、あるいは「Connection Refused」が頻発する。そんなとき、多くのエンジニアはとりあえず curl や ping を打つ。しかし、真のプロフェッショナルは、その先にある「ソケットの状態」を見るために、迷わず netstat（あるいはその後継である ss）を叩く。
今日は、教科書には載っていない「現場の視点」で、TCP/UDPソケットの深淵を覗く方法を解説しよう。
—
1. なぜ「netstat」を知らなければならないのか
APIが期待通りに応答しないとき、問題は往々にしてアプリケーションのコードの外側——つまりTCPスタックの「渋滞」にある。
- リスニングポートの確認: そもそもプロセスは起動しているのか？
- SYN_RECVの嵐: SYNフラッド攻撃を受けていないか？あるいは、接続要求が捌ききれなくなっていないか？
- TIME_WAITの蓄積: 短いコネクションを高速に繰り返す設計により、ポートが枯渇していないか？
これらを確認する術を持たないことは、暗闇で目隠しをしてトラブルシューティングをするに等しい。
2. 現場で叩くべき「鉄板コマンド」
最近のLinuxディストリビューションでは ss コマンドが推奨されているが、往年の netstat もまだ現役だ。まずは、現場で最もよく使うコマンド構成を叩き込んでおこう。
# 現場の常識：全リスニング中のTCP/UDPポートをプロセス名と共に表示する
# -t: TCP, -u: UDP, -l: Listening, -n: 数字表示(DNS逆引き禁止), -p: プロセス名表示
sudo netstat -tulpn
# ssを使うならこちら（最近の主流）
# -t: TCP, -l: Listen, -n: 数字表示, -p: プロセス
sudo ss -tlnpなぜ -n が重要なのか？
初心者は -n を付けたがらないが、現場では厳禁だ。DNS解決がタイムアウトしてコマンドの応答が数秒間フリーズするのを防ぐためだ。障害発生時の数秒は、命取りになる。
—
3. TCPの状態遷移を読み解く：TIME_WAITの正体
APIエンジニアが最も警戒すべきは、TIME_WAIT 状態のソケットだ。クライアントが頻繁に接続と切断を繰り返すと、サーバー側には終了したはずの接続の「残骸」が残り続ける。
# TIME_WAIT状態のコネクション数を数える
netstat -an | grep TIME_WAIT | wc -lもしこの数字が数千を超えているなら、ロードバランサーとバックエンド間の通信設定を見直す必要がある。Keep-Alive が有効になっていない、あるいはコネクションの再利用（Connection Pooling）ができていない証拠だ。
Pythonによるリクエストの最適化例
requests ライブラリを使っているなら、セッションを使い回すことが「TIME_WAITによるポート枯渇」を防ぐ唯一の解となる。
import requests
# セッションを維持することで、TCPコネクションを使い回す
session = requests.Session()
# 接続を確立し、ヘッダーでKeep-Aliveを明示する
headers = {'Connection': 'keep-alive'}
response = session.get('https://api.example.com/data', headers=headers)
print(response.status_code)—
4. 異常検知のためのチェックリスト
障害対応の現場では、以下の3ステップでソケット情報を整理する。
1. Listenを確認: Local Address は 0.0.0.0 になっているか？（特定IPにバインドして外部から繋がらないミスは意外と多い）
2. Send-Q / Recv-Qを確認:
Recv-Qが積み上がっていれば、アプリが処理しきれていない（ボトルネック）。Send-Qが積み上がっていれば、ネットワーク帯域が飽和しているか、対向側の処理が遅延している。
3. Stateの偏り: ESTABLISHED が異常に多い場合、コネクションのクローズ処理が適切に行われていない可能性がある。
—
最後に：ネットワークは「生き物」である
コマンドの出力結果は、その瞬間のシステムの「心電図」だ。最初はただの羅列に見えるかもしれない。しかし、何度も見ているうちに、ESTABLISHED が並ぶリズムや、SYN_SENT が消えない時の違和感に気づくようになる。
トラブルシューティングにおいて、最も信頼できるツールは、あなたの目の前にあるCLIコンソールと、その背後にあるネットワークの挙動への理解だ。
さあ、恐れずに netstat を叩いてほしい。あなたのシステムが何を叫んでいるのか、その声を聞き取る準備はできているはずだ。
コメント