【保存版】ネットワーク障害で最初に使うコマンド10選｜Windows・Mac・Linux対応のトラブルシューティング実践ガイド
「インターネットにつながらない」
「社内ネットワークだけ通信できない」
「pingは通るのにWebサイトが開かない」
ネットワーク障害が発生したとき、原因を調べようとしても、何から確認すればよいか迷った経験はありませんか？
ネットワーク障害の調査では、やみくもに機器を再起動したり設定を変更したりするよりも、適切なコマンドを使って、問題が発生している場所を絞り込むことが重要です。
この記事では、ネットワークエンジニアや社内SEが障害調査で活用できる基本コマンド10選を紹介します。
Windows・macOS・Linuxそれぞれの実行方法に加え、実行結果から何を判断できるのかも解説します。
この記事で分かること
ネットワーク障害の切り分けに役立つ10種類のコマンド
Windows・macOS・Linuxでの実行方法
コマンドの結果から確認できること
DNS障害・通信遅延・経路障害の調査方法
現場で使えるトラブルシューティングの基本手順
※ OSのバージョンや環境によって、コマンドのオプションや出力は異なります。Linuxでは追加パッケージが必要な場合があります。
1. ipconfig / ip / ifconfig｜IPアドレスを確認する
ネットワーク障害が発生したら、最初に確認したいのがIPアドレスです。
端末に正しいIPアドレスが設定されていなければ、正常な通信は期待できません。
Windows
ipconfig /all
macOS
ifconfig
Linux
ip addr show
確認するポイント
IPアドレスが想定したネットワークに属しているか
サブネットマスクやプレフィックス長は正しいか
デフォルトゲートウェイが設定されているか
DNSサーバーが適切か
DHCPによるアドレス取得が正常か
例えばWindowsで次のように表示された場合です。
IPv4 Address : 169.254.10.25
Subnet Mask : 255.255.0.0
169.254.0.0/16はIPv4リンクローカルアドレスの範囲です。
通常のDHCP構成で想定外にこのアドレスが設定されている場合、DHCPによるアドレス取得に失敗している可能性があります。
ただし、これだけでDHCPサーバーの故障と断定することはできません。VLAN設定、無線認証、物理接続なども確認が必要です。
実務ポイント： まずIPアドレスを確認するだけで、調査範囲を大幅に絞り込めることがあります。
2. ping｜通信相手への到達性を確認する
ネットワーク障害の調査で、最も基本的なコマンドの一つです。
ICMP Echo Requestを送信し、応答が返ってくるか確認します。
Windows
ping 8.8.8.8
macOS / Linux
ping -c 4 8.8.8.8
実行結果の例
64 bytes from 8.8.8.8:
icmp_seq=1 ttl=117 time=12.5 ms
確認するポイントは次の3つです。
① 応答の有無
応答が返ってくれば、少なくともその時点でICMPの往復通信が成立しています。
② 応答時間（RTT）
time=12.5 ms は往復時間を表します。
値が大きい場合、ネットワーク経路の遅延や通信相手の処理などが影響している可能性があります。
③ パケットロス
送信したパケットの一部が応答しない場合、パケット損失やICMPの制限などが考えられます。
注意点
pingが通らないからといって、必ずしもネットワーク障害とは限りません。
ファイアウォールなどでICMPを拒否している機器もあります。
また、pingが成功してもHTTPやHTTPSの通信が正常とは限りません。
3. tracert / traceroute｜通信経路を調査する
通信先までの経路を確認するコマンドです。
Windows
tracert 8.8.8.8
macOS / Linux
traceroute 8.8.8.8
出力例
1 192.168.1.1 1 ms
2 10.10.0.1 4 ms
3 203.0.113.1 10 ms
4 * * *
※ IPアドレスは説明用の例です。
この結果から、経路上のルーターや各ホップの応答時間を確認できます。
重要な注意点
途中に * * * が表示されても、その場所で通信が途絶えているとは限りません。
ルーターがTTL超過メッセージに応答しない場合や、ICMPを制限している場合にも発生します。
後続のホップが正常に応答しているなら、途中の * だけを障害と判断しないことが重要です。
4. nslookup｜DNSの名前解決を確認する
IPアドレスへの通信は成功するのに、Webサイトの名前でアクセスできない場合、DNSが原因の可能性があります。
Windows / macOS / Linux
nslookup example.com
DNSサーバーを指定する場合
nslookup example.com 8.8.8.8
確認するポイント
DNSサーバーから応答が返ってくるか
想定したIPアドレスが返るか
タイムアウトが発生していないか
社内DNSと外部DNSで結果が異なるか
例えば、社内DNSでは名前解決に失敗するのに外部DNSでは成功する場合、社内DNSの設定やフォワーダーなどを調査する手掛かりになります。
ただし、社内専用ドメインは外部DNSでは解決できないことが正常です。
5. arp｜同一ネットワーク内のMACアドレスを確認する
ARPは、IPv4アドレスとMACアドレスの対応関係を調べるための仕組みです。
Windows / macOS / Linux
arp -a
出力例
192.168.1.1 aa:bb:cc:dd:ee:ff
どんなときに使う？
デフォルトゲートウェイと通信できない
同一セグメントの端末にアクセスできない
IPアドレス重複が疑われる
ARPテーブルに想定外の情報がある
Linuxでは次のコマンドも利用できます。
ip neigh show
なお、ARPテーブルにエントリがないだけで障害とは断定できません。通信履歴、キャッシュの有効期限、端末の状態などによって結果が変わります。
6. route｜ルーティングテーブルを確認する
IPアドレスが正しく設定されていても、通信先への経路が間違っていれば通信できません。
Windows
route print
macOS
netstat -rn
Linux
ip route show
確認するポイント
デフォルトルートが存在するか
ネクストホップが正しいか
意図しない静的ルートが存在しないか
VPN接続によって経路が変わっていないか
例えばLinuxで次のように表示された場合です。
default via 192.168.1.1 dev eth0
これは、より具体的な経路が存在しない宛先への通信に、192.168.1.1をゲートウェイとして使用する設定を表します。
特にVPN接続後に通信できなくなる場合は、ルーティングテーブルの確認が有効です。
7. netstat / ss｜通信状態と待ち受けポートを確認する
「サーバーは起動しているのに接続できない」
そんなときに確認したいコマンドです。
Windows
netstat -ano
macOS
netstat -an
Linux
ss -tuna
確認するポイント
TCP接続が確立されているか
対象ポートが待ち受け状態か
接続先IPアドレスとポート番号
接続状態がどこで止まっているか
代表的なTCP状態には次のものがあります。
状態
意味
LISTEN
接続待ち
SYN_SENT
接続要求送信後、応答待ち
ESTABLISHED
接続確立
TIME_WAIT
接続終了後の待機状態
※ 表示される状態名はOSによって異なります。
SYN_SENTが継続する場合、通信先からの応答が届いていない可能性があります。ただし、その原因はファイアウォール、経路、相手側の状態など複数考えられます。
8. curl｜HTTP・HTTPS通信を確認する
pingが成功してもWebサイトが表示できない場合、HTTPやHTTPSのレベルで確認する必要があります。
Windows / macOS / Linux
curl -I https://example.com
※ Windows PowerShellでは、環境による別名との混同を避けるため curl.exe を使用すると確実です。
確認できること
DNSによる名前解決
TCP接続
TLSハンドシェイク
HTTPレスポンス
サーバーからの応答コード
例えば次のようなレスポンスです。
HTTP/2 200
HTTP 200はリクエストが成功したことを示します。
一方、HTTP 403ならアクセス拒否、HTTP 503ならサービス利用不可を表します。
なお、-I はHEADリクエストを送信するため、サーバーによってはGETと異なる応答になる場合があります。
詳細な通信時間を確認する
curl -o /dev/null -sS \
-w 'DNS:%{time_namelookup}\nConnect:%{time_connect}\nTLS:%{time_appconnect}\nTotal:%{time_total}\n' \
https://example.com
Windowsで使用する場合は、出力先を NUL に変更するなど、シェルに合わせて調整してください。
表示される時間は、リクエスト開始からの経過時間です。DNS、TCP接続、TLSなどの各処理を比較する際には、その差分も確認します。
9. dig｜DNSをより詳しく調査する
nslookupよりもDNSレコードを細かく確認したい場合に便利です。
macOS / Linux
dig example.com
Aレコードを確認
dig example.com A
MXレコードを確認
dig example.com MX
DNSサーバーを指定
dig @8.8.8.8 example.com
Windowsでは標準で利用できない環境があるため、BIND関連ツールなどの導入が必要です。
実務で確認するポイント
ANSWER SECTIONに期待したレコードがあるか
DNS応答コードが正常か
TTLが想定どおりか
DNSサーバーによって回答が異なるか
DNSの問題では、単純に名前解決が成功するかだけでなく、どのDNSサーバーからどのレコードが返ってきたかが重要になります。
10. Test-NetConnection / nc｜TCPポートへの接続を確認する
最後に紹介するのは、特定のTCPポートに接続できるか確認するコマンドです。
Windows PowerShell
Test-NetConnection example.com -Port 443
macOS / Linux
nc -vz example.com 443
どんなときに使う？
HTTPSの443番ポートに接続できるか
SSHの22番ポートが到達可能か
アプリケーション用ポートが開いているか
ファイアウォールで遮断されていないか
Windowsでは次のような結果が表示されます。
TcpTestSucceeded : True
これは指定した宛先・ポートへのTCP接続に成功したことを示します。
ただし、TCP接続が成功しても、その先のTLS認証やアプリケーション処理が正常とは限りません。
実践編：ネットワーク障害はこの順番で調べる
ここまで10種類のコマンドを紹介しましたが、重要なのは使う順番です。
例えば、Webサイトが表示できない場合は次のように調査します。
STEP 1：IPアドレスを確認
Windowsなら次のコマンドです。
ipconfig /all
IPアドレス、ゲートウェイ、DNSサーバーが適切か確認します。
STEP 2：ゲートウェイへの通信を確認
ping 192.168.1.1
※ 192.168.1.1は例です。実際のゲートウェイIPアドレスに置き換えてください。
応答がない場合、LAN接続、Wi-Fi接続、VLAN、ゲートウェイのICMP設定などを確認します。
STEP 3：外部IPアドレスへの通信を確認
ping 8.8.8.8
ここで失敗した場合、経路やファイアウォールなどを調査します。ただしICMPが制限されている可能性も考慮します。
STEP 4：DNSを確認
nslookup example.com
名前解決が成功するか確認します。
STEP 5：HTTPS接続を確認
Test-NetConnection example.com -Port 443
TCP接続が成立するかを確認します。
STEP 6：HTTPレスポンスを確認
curl.exe -I https://example.com
Webサーバーからの応答やTLS関連のエラーを確認します。
STEP 7：必要に応じて経路を確認
tracert 8.8.8.8
ここまで調べることで、問題がIP設定、DNS、通信経路、TCP接続、HTTPなど、どの領域にあるかを絞り込めます。
ただし、これらのコマンドだけですべての原因を特定できるわけではありません。
コマンドだけでは分からない障害もある
例えば、次のようなケースです。
pingは正常なのに、アプリケーションが頻繁に切断される
TCP接続は成立するのに、通信速度が極端に遅い
特定の端末だけ通信が不安定になる
ファイル転送中に通信が止まる
DNSの応答は正常なのに、Webアクセスに時間がかかる
こうした問題では、パケットの再送、TCPウィンドウ、接続確立処理などを詳しく確認する必要があります。
そこで役立つのが Wireshark です。
Wiresharkを使用すると、実際に送受信されているパケットを取得し、通信の状態を詳細に分析できます。
ただし、取得位置によって観測できる通信は異なります。暗号化された通信の内容も、通常はそのまま確認できません。
さらに詳しく学びたい方へ
この記事では、ネットワーク障害の初動調査に役立つ10種類のコマンドを紹介しました。
実際の障害対応では、コマンドの実行結果から仮説を立て、必要に応じてパケットキャプチャを取得し、原因を検証することが重要です。
より高度な調査方法を学びたい方向けに、別の記事で 「Wiresharkによる異常通信解析」 を解説しています。
TCP再送、重複ACK、通信遅延、接続異常など、コマンドだけでは判断しにくい問題の解析に興味がある方は、ぜひ参考にしてください。
▶ 関連記事：【実務向け】Wiresharkによる異常通信解析
※ ここに公開済みの有料note記事へのリンクを挿入してください。
まとめ
ネットワーク障害の調査では、最初から難しい解析を行う必要はありません。
まずは基本的なコマンドを使用して、障害の発生箇所を絞り込むことが大切です。
今回紹介した10種類をもう一度整理します。
コマンド
主な用途
ipconfig / ip / ifconfig
IPアドレスの確認
ping
ICMP到達性・RTTの確認
tracert / traceroute
通信経路の確認
nslookup
DNS名前解決の確認
arp
IPv4とMACアドレスの対応確認
route
ルーティングの確認
netstat / ss
TCP接続・ポート状態の確認
curl
HTTP・HTTPS通信の確認
dig
DNSレコードの詳細調査
Test-NetConnection / nc
TCPポートへの接続確認
ネットワーク障害対応で重要なのは、コマンドを暗記することではなく、実行結果から何が分かり、何がまだ分からないのかを理解することです。
この記事が日々のトラブルシューティングに役立てば幸いです。
後から見返せるように、ぜひ保存して活用してください。
