nethogs は「どのプロセスが今どれだけ通信しているか」をプロセス単位で表示するツールです。この記事では、画面に並ぶ各列の意味、単位の読み違えやすい点、unknown TCP などの行が出る理由を整理し、表示から「何が帯域を使っているのか」を判断できるようにします。インストール方法や基本操作ではなく、出てきた結果の解釈に絞って解説します。
nethogs の画面に出ている項目
sudo nethogs を実行すると、おおよそ次のような表示になります。以下は 0.8 系を想定した例で、主要ディストリビューションの配布版も大きな構成はこの形です（2026年10月現在）。バージョンによって列の並びや見出しの表記は少し異なります。
NetHogs version 0.8.7
PID USER PROGRAM DEV SENT RECEIVED
2481 www-data /usr/sbin/nginx eth0 412.351 18.204 KB/sec
1932 www-data php-fpm: pool www eth0 2.118 35.990 KB/sec
1105 root /usr/bin/rsync eth0 950.774 3.511 KB/sec
? root unknown TCP 0.412 0.208 KB/sec
TOTAL 1365.655 57.913 KB/sec各列の意味は次のとおりです。
- PID / USER / PROGRAM: 通信しているソケットを持っているプロセスと、その実行ユーザー、コマンド名です。
- DEV: 通信に使われたネットワークインターフェースです。複数の NIC や VPN インターフェースがあるサーバーでは、ここを見るとどの経路の通信かが分かります。
- SENT: そのサーバーから外へ送った量です。Web サーバーなら、訪問者へのレスポンスはここに出ます。
- RECEIVED: 外から受け取った量です。アップロードや、外部 API・パッケージのダウンロードはこちらに出ます。
- TOTAL: 表示中の全行の合計です。
SENT と RECEIVED は「そのサーバーから見た向き」です。nginx の SENT が大きいのは、訪問者に画像や HTML を返しているからで、異常ではありません。逆に、本来は受け身のはずのプロセスの SENT が急に増えている場合は、何をどこへ送っているのかを追う価値があります。
数値と単位の読み方
既定は「1秒あたりの量」で、ビットではなくバイト
既定の表示は KB/sec、つまり1秒あたりのキロバイトです。回線やプランの帯域は「Mbps（ビット毎秒）」で表されることが多いため、比べるときは 8 倍して考えます。たとえば SENT が 950 KB/sec なら、おおよそ 7〜8 Mbps 程度です。100 Mbps の回線上限に対しては余裕がある、といった見積もりができます。
表示モードを切り替えると「累計」になる
実行中に m キーを押すと表示モードが切り替わり、1秒あたりの値から、起動してからの累計量（KB・B・MB など）に変わります。起動時オプション -v でも指定できます（-v 0 が KB/sec、-v 1 が累計 KB、-v 2 が累計 B、-v 3 が累計 MB。新しいバージョンでは MB/sec などのモードが追加されている場合があります）。
瞬間値は変動が大きく、ある1秒だけ大きく見えることがあります。「この10分で何を一番使ったか」を知りたいときは累計モードで数分間眺めるほうが判断しやすくなります。
更新間隔と並べ替え
更新間隔は既定で1秒で、-d 5 のように指定すると5秒ごとになります。間隔を広げると値がならされ、短時間の山が目立たなくなります。並び順は s で SENT 順、r で RECEIVED 順に切り替えられます。調べたい向きに合わせて並べ替えると、上位の行だけ見れば済みます。
よく見かける行とその解釈
unknown TCP が出る
unknown TCP は、パケットは捕まえたものの、どのプロセスのソケットかを特定できなかった通信の合計です。主な理由は次のとおりです。
- 接続が短時間で閉じ、nethogs がプロセスとの対応を調べる前にソケットが消えた
- 別のネットワーク名前空間（コンテナなど）にあるプロセスの通信で、ホスト側からは対応が取れない
- 権限が足りず、他ユーザーのプロセス情報を読めていない
値が小さいうちは気にする必要はありません。unknown TCP の値が大きく、しかも続いている場合は、まず root 権限で実行しているかを確かめ、次にコンテナの有無を確認します。Docker などでは、コンテナ内のプロセスがホスト側の PID で表示されることもあれば、unknown に集約されることもあり、環境によって見え方が変わります。
同じプログラムが何行も並ぶ
php-fpm や Apache の prefork のように、ワーカープロセスを複数立てるソフトウェアは、PID ごとに別の行になります。合計で見たい場合は行を足し合わせて考えます。1つのワーカーだけが突出しているなら、そのワーカーが処理している特定のリクエスト（大きなファイルの配信や外部 API 呼び出し）を疑えます。
UDP の通信が出てこない
古いバージョンの nethogs は TCP のみを対象にしていました。新しいバージョンでは UDP も扱えるオプション（-C）がありますが、既定でどこまで表示されるかはバージョンによって異なります。DNS や QUIC（HTTP/3）、VPN などの UDP 通信が見当たらないときは、nethogs -h で使えるオプションを確認してください。
データベースの通信が出てこない
WordPress と MySQL が同じサーバーにあり、Unix ソケット（localhost 指定）で接続している場合、その通信はネットワークインターフェースを通らないため nethogs には表示されません。また既定ではループバックインターフェースを監視しない設定のため、127.0.0.1 経由の通信も通常は見えません。
表示から原因を絞り込む手順
1. 誰が使っているかを特定する
まずは SENT 順・RECEIVED 順のそれぞれで上位を確認します。よくある組み合わせと読み方は次のとおりです。
- nginx や Apache の SENT が大きい: 訪問者への配信です。アクセス増加、大きな画像や動画、ボットのクロールを疑い、アクセスログと照らし合わせます。
- php-fpm の RECEIVED が大きい: 外部 API の呼び出しや、プラグインによる外部サーバーとの同期、アップデートのダウンロードが考えられます。
- rsync・rclone・バックアッププラグインの SENT が大きい: バックアップの転送中です。実行時刻をアクセスの少ない時間帯にずらす判断材料になります。
- 見覚えのないプログラムやユーザーの SENT が続く: 不正なプログラムの可能性もあるため、PID から実体を確認します。
2. 通信の相手を確かめる
nethogs は相手先のアドレスを表示しません。気になるプロセスの PID が分かったら、ss で接続先を確認します。
sudo ss -tnp | grep "pid=1932"接続先の IP アドレスが分かれば、自社のバックアップ先なのか、外部 API なのか、それとも想定外の相手なのかを判断できます。プロセスの実体は ls -l /proc/1932/exe や ps -fp 1932 で確認できます。
3. 記録を残す
画面を眺めるだけでは、あとから比較できません。-t（トレースモード）を付けると、画面描画をせずに結果をテキストで出力し続けるため、ファイルに残せます。-c で更新回数を指定すると、その回数で終了します。
sudo nethogs -t -d 5 -c 60 eth0 > nethogs_$(date +%Y%m%d_%H%M).logこの例では5秒ごとに60回、約5分間の記録を取ります。出力の形式はバージョンによって多少異なるため、集計スクリプトを作る前に一度ファイルの中身を確認してください。
解釈で間違えやすい点
- root 権限なしで実行している: 権限が足りないと、パケットを捕まえられないか、プロセスとの対応が取れずに unknown ばかりになります。
sudoで実行するのが基本です。 - インターフェースの指定漏れ: 引数で特定のインターフェースだけを指定すると、それ以外を通る通信は見えません。VPN やコンテナ用のブリッジを経由する通信を見落としていないか確認します。
- 一瞬の値で判断する: 瞬間値の山だけで「このプロセスが原因」と決めつけず、累計モードや記録で傾向を見ます。
- nethogs 自身の負荷: パケットを解析するため、非常に通信量の多いサーバーでは CPU を使います。長時間動かしっぱなしにするより、調査したい時間帯に絞って実行するのが無難です。
まとめ
- SENT はサーバーから外へ、RECEIVED は外から受け取った量で、既定は1秒あたりの KB です。回線帯域と比べるときは 8 倍してビットに直します。
- 瞬間値は変動が大きいため、
mキーや-vで累計表示に切り替えたり、-tで記録を残したりして傾向を見ます。 - unknown TCP は「プロセスを特定できなかった通信」で、権限不足やコンテナ、短命な接続が主な理由です。
- Unix ソケットやループバック経由の通信は既定では表示されません。
- 相手先は nethogs では分からないため、PID を手がかりに
ss -tnpなどで接続先を確認します。