【入門編】 ssコマンドの基本構造とnetstatからの移行理由 – トラブルシューティング＆ネットワーク運用監視実践ガイド

ネットワークエンジニアの皆さん、こんにちは。深夜のデータセンターで、冷たいサーバーの排気音を聞きながら障害調査をしたことはありますか？あのピリピリした緊張感の中で、何よりも頼りになるのは「今、このサーバーで何が起きているのか」を瞬時に教えてくれるコマンドたちです。

これまで、ネットワークの状態確認といえば netstat コマンドが定番でした。しかし、現代のサーバー運用では、その後継である ss（Socket Statistics）コマンドを使うのが「大人の嗜み」になりつつあります。

今日は、なぜ今 ss なのか？そして、この強力なツールをどう使いこなせばいいのか、現場の視点から紐解いていきましょう。

—

まず、なぜ netstat から移行する必要があるのか。例えるなら、「手紙の配達状況を確認する方法」の違いです。

netstat（昔のやり方）: 郵便局の巨大な書類棚（カーネルの /proc ディレクトリ）を、一つひとつ開けて中身を確認するようなものです。サーバーの通信量が増え、接続数が数万にもなると、書類棚を全部チェックするだけで時間がかかり、サーバーに余計な負荷をかけてしまいます。
ss（現代のやり方）: 郵便局の仕分けシステムに直接問い合わせるようなものです。カーネルと直接会話する「Netlink」という高速道路を使うため、たとえ何万件の接続があっても、瞬時に情報を引き出せます。

特に、クラウド環境で大量のトラフィックを扱う現代において、netstat は「動作が遅い」だけでなく、正確な状態を掴み損ねるリスクさえあるのです。

—

ss コマンドの使い方はシンプルです。まずは、今サーバーで何が動いているか、全体像を見てみましょう。

# TCP接続の一覧を表示する
# -t: TCPを表示
# -l: リッスン（待ち受け）状態のポートを表示
# -n: IPアドレスやポート番号を数字で表示（名前解決をしないので高速！）
ss -tln

このコマンドを打つと、画面いっぱいに現在待ち受け中のサービスが表示されますよね。Local Address:Port がサーバーの住所、Peer Address:Port が通信相手の住所です。

コマンドを覚えるのが苦手な方も、まずはこの3つの組み合わせだけ覚えてください。

—

障害調査の現場で、「とにかく特定のポートだけを見たい！」という場面は山ほどあります。例えば、ウェブサーバーの「80番ポート」が生きているか確認したいときは、こう打ちます。

# 80番ポートを使っているプロセスを特定する
sudo ss -tlnp sport = :80

ここで使った sport = :80 は「ソースポート（自分の出口）が80番のものだけ教えて」というフィルターです。dport に変えれば「宛先ポート」になります。これさえあれば、膨大なログの中から犯人を探す必要はもうありません。

—

通信がうまくいかないとき、私たちは「接続が確立しているのか（ESTAB）」それとも「相手からの返事を待っているのか（SYN-RECV）」を気にします。これも ss なら一発です。

# 現在確立されている接続だけを抽出する
ss -tn state established

例えば、特定のIPアドレスからの接続が多すぎてサーバーが重い……なんていう時は、こう書き換えます。

# 特定のIPアドレスからの接続状況を確認する
ss -tn dst 192.168.1.10

—

いかがでしたか？ ss コマンドは、単なる情報の羅列ではなく、サーバーという生き物の「血流」を可視化するツールです。

最初は呪文のように感じるかもしれませんが、一度「あ、今パケットはここで止まっているな」という感覚が掴めれば、ネットワークトラブルは怖くありません。

まずは、自分のパソコンや開発環境で ss -tln を叩くところから始めてみてください。画面に流れる情報の意味が少しずつ理解できるようになれば、あなたはもう立派なインフラエンジニアの入り口に立っていますよ。

何か分からないことがあれば、いつでも現場の知見を共有します。一緒に、安定したネットワークを構築していきましょう！