【入門編】 ssコマンドのフィルタリング機能（state, sport, dport, dst等）の高度な活用法 – トラブルシューティング＆ネットワーク運用監視実践ガイド

こんにちは！データセンターの片隅で、深夜の障害アラートと格闘しながらネットワークの深淵を覗き続けているNOCエンジニアです。

皆さんは、サーバーの調子が悪いとき、まず何をしますか？「何か重いな…」「通信が繋がらないな…」と思ったとき、真っ先に使ってほしいのが ss コマンドです。

昔は netstat というコマンドが主流でしたが、今や ss こそが現場のスタンダード。なぜなら、ss はとにかく速いからです。大量の通信が飛び交う現代のサーバーにおいて、ソケット（通信の窓口）の状態を瞬時に引き出してくれる頼もしい相棒なんですよ。

今回は、この ss コマンドの「フィルタリング機能」を使いこなし、まるで外科手術のようにピンポイントで障害原因を特定するテクニックを伝授します。

—

技術解説に入る前に、少しだけイメージの話をさせてください。

サーバー上で動いているプログラムたちは、外の世界と通信するために「窓口（ソケット）」を持っています。これは、「郵便局の窓口」を想像するとわかりやすいですよ。

ss コマンドは、この郵便局の「全窓口リスト」を閲覧し、さらに「〇〇番の窓口だけ教えて！」「今まさに荷物を受け取っている人だけ教えて！」と絞り込むための魔法のツールなんです。

—

まずは基本のフィルタリングから。サーバーには何千もの通信が混在しています。全部表示されると目が回ってしまいますよね。

例えば、「今、Webサーバー（ポート80番）に誰がアクセスしているか見たい！」というときはこう書きます。

# dport（宛先ポート）が 80 のものだけを抽出
ss -nt state established '( dport = :80 )'

これだけで、関係のないバックグラウンドの通信をバッサリ切り捨て、今まさにWebサーバーを使っているユーザーの接続だけがズラリと並びます。「あれ、このIPから異常にたくさんアクセスが来ているな…」といった発見が、ここから始まるんです。

—

サーバー運用で一番怖いのは、リクエストが多すぎて窓口がパンクし、「CLOSE_WAIT」や「TIME_WAIT」といった、終わったはずの通信がゴミのように溜まってしまう状況です。

そんなとき、特定のステータスだけを狙い撃ちしてみましょう。

# 終了処理中の怪しいソケットを全て洗い出す
ss -ant '( state time-wait or state close-wait )'

「あれ？さっきより数が減っているはずなのに、なぜかこの状態の通信が残っているぞ？」となれば、プログラム側の処理落ち（バグ）の可能性が高いと判断できます。

—

次は、特定の相手（例えばDBサーバーなど）との通信だけを追跡するケースです。

# 宛先IPが 192.168.1.10 の通信だけをフィルタリング
ss -nt dst 192.168.1.10

これは、DBサーバーが応答しなくなったとき、「自分からDBへの窓口はちゃんと開いているか？」を確認するのに非常に役立ちます。dst（宛先）を絞ることで、無関係なユーザーからのアクセスを無視して、自分のサーバーからDBへの「回線」だけに集中できるんです。

—

最後は、実務で私がよく使う「合わせ技」をご紹介します。「ポート80番で、特定のIPからのアクセスを、状態込みで確認したい」というケースです。

# 80番ポート宛の通信で、かつ 192.168.x.x からの接続のみを抽出
ss -nt '( dport = :80 ) and ( src 192.168.0.0/24 )'

ポイントは () で条件を囲むこと。こうすることで、「ポートは80」かつ「送信元は特定のネットワーク」という、論理的な絞り込みが可能になります。

—

トラブルシューティングのコツは、「情報のノイズをいかに減らすか」に尽きます。

最初はコマンドが長く感じて拒否反応が出るかもしれませんが、郵便局の窓口をイメージして、「どの窓口（ポート）」「どこの住所の人（IP）」「今どんな状況（state）」と整理していけば、必ず答えに辿り着けます。

皆さんも、まずはサーバーにログインして、 ss -nt を打つところから始めてみてください。そこから少しずつフィルタを加えていく。その繰り返しで、いつの間にかサーバーの「鼓動」が手に取るようにわかるようになりますよ。

それでは、次回の運用現場でお会いしましょう！ネットワークの平和を祈っています。