現場実践|障害調査・トラブルシューティング

ネットワーク障害調査の実践入門|ping・traceroute・netstat・tcpdumpの使い方

「ネットワークがつながらない」「疎通確認が取れない」——現場でネットワーク障害が発生したとき、まず何を確認するべきか。ping・traceroute・netstat・tcpdumpを使った体系的な障害調査手順を解説します。

読了目安:約18分更新日:2026年3月

💡 ネットワーク障害調査の基本は「どこまで届いているか」を順番に確認すること。OSI参照モデルの下層から順番に確認していくことが最も効率的な調査アプローチです。

この記事を書いた人
現役ITエンジニア・IT講師(経験14年)
CCNA・CCNP 取得LPIC-1 保有SES現場を複数経験

ネットワーク障害調査を現場で多数経験してきた立場から、体系的な調査手順を解説します。

1. 障害調査の基本的な考え方

まず、ネットワーク障害調査では「OSI参照モデルの第1層(物理層)から順番に確認する」アプローチが最も効率的です。「ケーブルは接続されているか」→「IPは設定されているか」→「ルーティングは正しいか」→「ファイアウォールでブロックされていないか」の順番で切り分けていきます。

2. ping:疎通確認の基本

# 基本的な疎通確認
ping 8.8.8.8

# 回数を指定(5回)
ping -c 5 192.168.1.1

# パケットサイズを指定(MTU確認用)
ping -s 1472 192.168.1.1

# ローカルループバックの確認(NIC自体の確認)
ping 127.0.0.1

3. traceroute:経路確認

# 経路のホップを確認
traceroute 8.8.8.8

# Windows環境
tracert 8.8.8.8

# UDPではなくICMPを使う(-I)
traceroute -I 8.8.8.8

各ホップの応答時間が急激に上がる箇所や「* * *」(タイムアウト)が続く箇所が障害ポイントの手がかりになります。

4. netstatとss:ポート・接続確認

# リスニングポートを確認(ss推奨)
ss -tlnp

# 確立済みの接続を確認
ss -tnp

# 特定ポートの接続を確認
ss -tnp | grep :443

# 旧来のnetstatでの確認
netstat -tlnp

5. tcpdump:パケットキャプチャ

# 特定ホストとの通信をキャプチャ
sudo tcpdump -i eth0 host 192.168.1.100

# 特定ポートをキャプチャ
sudo tcpdump -i eth0 port 443

# ファイルに保存(Wiresharkで分析)
sudo tcpdump -i eth0 -w /tmp/capture.pcap
📌 この記事のポイント
  • 障害調査はOSI参照モデルの第1層から順番に「どこまで届いているか」を確認する
  • ping(疎通)→traceroute(経路)→ss(ポート)→tcpdump(パケット)の順番が基本
  • tcpdumpでキャプチャしたファイルをWiresharkで視覚的に分析するとより詳しく調査できる

キャリアの疑問、一緒に解決しませんか?

Route Bloomでは、インフラ系ITエンジニアを目指す方への個別サポートを行っています。2026年7月からフリーランス講師として本格始動予定です。

※コマンドはLinuxディストリビューション・バージョンにより異なります。

ABOUT ME
たから
サラリーマンをしながら開業して経営やってます。 今年、本業で独立・別事業を起業予定です。 ◆経験:IT講師/インフラエンジニア/PM/マネジメント/採用/運用・保守・構築・設計 ◆取得資格:CCNA/CCNP/LPIC-1/AZ-900/FE/サーティファイC言語 ◆サイドビジネス:経営/個人事業/アパレル