ネットワークがつながらない、通信が遅いといったトラブルは、仕事や日常の作業を大きく妨げてしまいます。原因が回線なのか、機器なのか、設定なのかを特定するには、やみくもに再起動するのではなく、基本的なコマンドを使って順序立てて確認していくことが重要です。
本記事では、ネットワークトラブルシュートに欠かせない ping・traceroute・nslookup・netstat・ipコマンド などを中心に、接続不良の原因を切り分ける方法を整理します。初心者でも実務者でもすぐに活用できる内容になっていますので、ネットワーク障害に直面したときの参考にしてください。
詳細な流れを横断的に確認したい場合は Linuxトラブルシューティング総合ハブ から全体像をご覧いただけます。
ネットワークトラブルシュートの基本的な流れ
ネットワークトラブルシュートを行う際に大切なのは、「どこで問題が発生しているのか」を段階的に絞り込んでいくことです。原因がPCやサーバー側にあるのか、ルーターやスイッチといったネットワーク機器にあるのか、あるいはインターネット回線やDNSといった外部にあるのかを切り分けることで、効率的に対処できます。
物理的な接続確認（ケーブル・Wi-Fi・機器の状態）
最初に確認すべきは物理的な接続です。有線であればLANケーブルがしっかり挿さっているか、リンクランプが点灯しているかを確認します。ケーブルの断線や差し込み不足は意外と多い原因です。無線LANの場合はWi-Fiが有効になっているか、SSIDに正しく接続されているかを確認しましょう。また、ルーターやモデムが正常に動作しているか（電源・ランプ状態）も重要です。これらを確認するだけで、単純なトラブルの多くは解決します。
OSレベルでの状態確認（IPアドレスやインターフェース）
物理的に問題がなければ、OS側でネットワークインターフェースが有効になっているかを調べます。
Linuxであれば ip addr show や ifconfig を利用してIPアドレスが割り当てられているか確認します。Windowsの場合は ipconfig コマンドで同様の情報が取得可能です。
もしIPアドレスが「169.254.x.x」のような自動割り当てアドレス（APIPA）になっている場合、DHCPサーバーとの通信が失敗している可能性が高いです。固定IP設定に誤りがないかも合わせて見直すとよいでしょう。
このように、物理 → OS設定 → 通信確認 の順で切り分けを行うことで、原因の範囲を効率よく絞り込むことができます。
pingコマンドで疎通確認
ネットワークトラブルシュートで最も基本となるのが pingコマンド です。指定したホストに対してICMPエコー要求を送り、応答があるかどうかで通信の可否を確認できます。単純ながらも強力な切り分けツールです。
ローカル環境（127.0.0.1 / 自分のIP）の確認
最初の一歩は、自分の端末内で通信が可能かどうかの確認です。
ping 127.0.0.1
このループバックアドレスに対して応答があれば、TCP/IPスタックが正常に動作していると判断できます。もし応答がない場合は、OSやネットワークスタック自体に問題がある可能性があります。
次に、自分の端末のIPアドレスを指定してpingを実行します。これにより、インターフェースが有効であるか確認できます。
ping 192.168.1.10
ここで応答がなければ、ドライバや設定の問題が疑われます。
ゲートウェイや外部サーバーへの到達確認
ローカル環境で問題がなければ、デフォルトゲートウェイ（通常はルーター）へpingを実行します。
ping 192.168.1.1
応答が返ってくればLAN内は正常に通信できています。逆に応答がなければ、ルーターやケーブルに問題があるか、またはファイアウォールでICMPが遮断されている可能性があります。
さらに、外部の安定したサーバー（例: 8.8.8.8）へpingを試すと、インターネットとの接続性を確認できます。
ping 8.8.8.8
これで応答が返るならインターネット回線は正常であり、名前解決（DNS）が原因の可能性が高まります。
応答結果から切り分けるポイント
pingの結果は「成功か失敗か」だけでなく、応答時間やパケットロスの有無も重要です。
- 応答時間が極端に遅い → ネットワークの輻輳や回線品質の問題
- パケットロスが多い → 無線LANの干渉、回線障害、機器の不具合
- 宛先に到達できない → 経路上の障害やDNSの不具合
このように、pingは単なる接続確認にとどまらず、トラブルのヒントを多く与えてくれます。
traceroute（Windowsはtracert）で経路確認
pingで外部と疎通が確認できない場合や、応答が極端に遅い場合には、traceroute（Windowsでは tracert） を利用して通信経路を調べます。通信がどの地点で途切れているかを把握することで、問題の範囲を明確にできます。
どの地点で通信が途切れているかを確認
tracerouteは、宛先までのルーターを順番に辿りながら応答を記録するコマンドです。Linuxでは以下のように実行します。
traceroute www.google.com
Windowsの場合は次のようになります。
tracert www.google.com
実行すると、宛先までに通過するルーターのIPアドレスやホスト名が表示されます。途中で応答が途切れたり、特定の地点以降がすべてタイムアウトになる場合は、その区間で障害が発生している可能性が高いです。
タイムアウトや遅延の見方
tracerouteの結果では、各ホップごとの応答時間（ms）が表示されます。これが急激に大きくなっている場合、その区間で遅延が発生していることを示しています。
例：
1 192.168.1.1 1.23 ms 1.01 ms 1.05 ms
2 * * *
3 203.0.113.5 45.12 ms 44.88 ms 45.30 ms
- 「 * 」が表示される → そのルーターがICMP応答を返さない設定になっているか、通信が遮断されている可能性
- 特定のホップ以降で応答がない → その地点以降のネットワーク障害
- 応答時間が急激に増加 → 回線品質や経路の問題
tracerouteを活用することで、問題が自分のネットワーク内にあるのか、プロバイダやインターネットの中継地点にあるのかを判断できます。
ネットワーク管理者やサポートに問い合わせる際も、tracerouteの結果を提示すれば状況を的確に伝えることができ、解決までの時間を短縮できます。
nslookup・digで名前解決を確認
インターネットに接続できるのにWebサイトが表示されない場合、多くは DNS（名前解決） に原因があります。このとき役立つのが nslookup や dig コマンドです。ドメイン名が正しくIPアドレスに変換されているかを確認できます。
DNSサーバーの応答を確認する方法
まずは nslookup コマンドでシンプルに確認します。
nslookup www.google.com
正常に動作していれば、使用しているDNSサーバーと解決されたIPアドレスが表示されます。
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: www.google.com
Address: 142.250.196.132
もし「server can’t find」や「connection timed out」と表示される場合は、DNSサーバーが応答していない、またはネットワーク経路で障害がある可能性があります。
より詳細に確認したい場合は dig コマンドを使います。
dig www.google.com
結果にはAレコード（IPv4）やAAAAレコード（IPv6）、問い合わせにかかった時間などが含まれており、DNSの応答状況を細かく確認できます。
正常時と異常時の出力比較
- 正常時
IPアドレスが返り、ANSWER SECTIONにドメインとIPの対応が表示される。 - 異常時
SERVFAILやNXDOMAINが表示される。SERVFAIL→ DNSサーバー側の問題NXDOMAIN→ ドメイン自体が存在しない
また、特定のDNSサーバーを指定して調べることも可能です。
nslookup www.example.com 8.8.8.8
dig @1.1.1.1 www.example.com
これにより、プロバイダのDNSが不調なのか、特定のサーバーに依存する問題なのかを切り分けられます。
DNSはネットワーク障害の中でも見落とされがちなポイントですが、実際には「つながらない」トラブルの大きな割合を占めています。nslookupやdigを活用することで、問題が名前解決にあるのかをすばやく判断できるようになります。
netstat・ssで接続状況を調べる
ネットワークが正しく動作しているように見えても、実際には特定のポートが開いていない、あるいは不要な接続が残っていることがあります。そんなときに役立つのが netstat や ss コマンドです。これらは現在の通信セッションやポートの状態を確認するための基本ツールです。
LISTENポートや確立済みセッションを確認
サーバーがサービスを提供しているかどうかは、ポートの状態を確認すれば分かります。
# netstat の場合
netstat -tuln
# ss の場合（より高速で推奨）
ss -tuln
主なオプションの意味は以下の通りです。
-t… TCP接続-u… UDP接続-l… LISTEN状態（待ち受け）-n… 名前解決をせずに数値で表示
実行すると、現在LISTENしているポート番号とアドレスが表示されます。例えば、Webサーバー（HTTP）が正しく稼働していれば、0.0.0.0:80 や [::]:80 のようにLISTEN状態が見えるはずです。もしサービスが立ち上がっていない場合はここに表示されません。
また、現在確立しているセッションを確認する場合は以下のようにします。
ss -tan
ESTABLISHED 状態のセッションが表示され、どのIPアドレスと通信しているかを把握できます。
不審な接続・プロセスの調査
netstatやssの出力は、トラブルシュートだけでなくセキュリティ確認にも有効です。
ss -tunp
-p を付けることで、どのプロセスがどのポートを使用しているかを確認できます。もし意図しないプログラムが外部と接続していた場合、マルウェアや不正アクセスの可能性があります。
さらに、接続が過剰に増えている場合はDoS攻撃やアプリケーションの不具合も疑われます。ログと合わせて分析すると原因を特定しやすくなります。
netstatやssは「サービスが待ち受けているか」「接続が確立できているか」を可視化する強力なコマンドです。アプリケーション側の問題なのか、ネットワーク側の問題なのかを切り分ける際に大いに役立ちます。
ifconfig・ipコマンドでインターフェース確認
ネットワークの基本的な動作を確認するには、インターフェース（NIC: ネットワークインターフェースカード）の状態を調べることが欠かせません。ifconfig や ipコマンド を使うことで、IPアドレスの割り当てや通信状況を確認できます。
IPアドレスの割り当て確認
まずは現在のインターフェースにどのようなアドレスが設定されているかを確認しましょう。
# 旧来の ifconfig
ifconfig
# 推奨される ip コマンド
ip addr show
結果には、各インターフェースごとにIPアドレスやMACアドレス、サブネットマスクなどが表示されます。
- 正常な場合:
inet 192.168.1.10/24のようにアドレスが割り当てられている - DHCPが失敗している場合: アドレスが空欄、または
169.254.x.xのAPIPAアドレスが表示される - 固定IPの誤設定: 他のネットワークと一致しないサブネットが設定されている
この時点で「そもそもアドレスがない」状態なら、DHCPサーバーやネットワーク設定の問題が疑われます。
リンク状態や送受信パケットの確認
インターフェースが正しくリンクしているか、通信が行われているかも重要な手がかりになります。
# インターフェースの詳細を表示
ip -s link show
ここでは送信パケット数、受信パケット数、エラーの有無などが確認できます。
- RX/TXのエラーが多い → ケーブル不良やNICの問題
- パケットが全く増えない → 通信が行われていない
- インターフェースが DOWN → 無効化されている（
ip link set eth0 upで有効化可能）
特にサーバー環境では、NICが有効になっていないだけで「接続できない」という事態が起きやすいので注意が必要です。
ifconfigやipコマンドは、ネットワークの入り口であるインターフェースの状態を把握するための基本です。IPが正しく割り当てられているか、インターフェースが有効か、通信が行われているか を順に確認することで、物理層からネットワーク層までの切り分けが効率的に進められます。
その他便利な確認コマンド
基本の ping や traceroute、nslookup などに加えて、ネットワークトラブルシュートをさらに効率化できる便利なコマンドがあります。これらを使いこなすことで、問題の切り分け精度を高められます。
arpでMACアドレスの確認
LAN内で特定のホストと通信できない場合は、ARP（Address Resolution Protocol） の確認が役立ちます。
arp -a
実行すると、IPアドレスと対応するMACアドレスが一覧表示されます。ここに対象ホストが存在しない場合、同一ネットワーク内でARP要求が届いていない可能性があります。逆にMACアドレスが正しく解決されているのに通信できない場合は、上位層での障害が疑われます。
curl・wgetでアプリ層の応答確認
通信路が確立されていても、アプリケーションが応答しないケースがあります。その場合は curl や wget を利用してアプリ層の確認を行いましょう。
curl -I http://example.com
wget --spider http://example.com
HTTP/1.1 200 OK が返ればWebサーバーが正常に応答していることを示します。もし応答がなければ、アプリケーションやファイアウォールの設定が原因である可能性が高いです。
tcpdumpでパケットキャプチャ
問題の原因がどうしても特定できないときは、tcpdump を使ってパケットを直接確認します。
tcpdump -i eth0 host 192.168.1.1
指定したインターフェース上で、対象ホストとのやり取りをリアルタイムに監視できます。パケットが送信されているのに応答がない場合や、予期しない宛先へ通信が飛んでいる場合などを把握可能です。
これらのコマンドは一見すると上級者向けですが、基本的な使い方だけでも大きな効果があります。「通信できないのは物理か、ネットワーク層か、アプリ層か」 を切り分けるための手がかりを提供してくれるため、実務において非常に重宝されます。
トラブルシュートを効率化するコツ
ネットワークトラブルシュートは、単にコマンドを実行するだけではなく、切り分けの順序や情報の残し方 を意識することで、より効率的かつ再現性のある調査が可能になります。
切り分けの順序を意識する
トラブルが発生した際には、以下のような流れで確認するとスムーズです。
- 物理層の確認
ケーブル、Wi-Fi接続、リンクランプの状態を確認。 - IPアドレス・インターフェースの確認
ip addrやifconfigでアドレス割り当てを調べる。 - 疎通確認
pingでローカル・ゲートウェイ・外部の順に確認。 - 経路確認
traceroute/tracertでどの地点で途切れているかを調査。 - 名前解決確認
nslookup/digでDNSの応答を確認。 - ポート・セッション確認
ss/netstatでLISTEN状態や接続先を調べる。 - アプリ層の確認
curl/wgetでサービスの応答を検証。 - 詳細調査
tcpdumpなどでパケットレベルの分析を行う。
このように層ごとに下から上へ確認していくと、どの段階で問題が生じているのかを自然に絞り込むことができます。
ログとコマンド出力を残す習慣
トラブル対応では、その場での判断だけでなく 証跡を残すこと が非常に重要です。
- コマンド実行結果を保存 (
ping 8.8.8.8 > ping.log) - 日時を記録しておく
- 複数回試した場合は比較できるように残す
こうしておけば、後から状況を再確認したり、別の担当者に引き継ぐときにも役立ちます。特にネットワーク障害は一時的に復旧してしまうケースも多いため、記録があるかどうかで原因究明の精度が大きく変わります。
効率的なトラブルシュートのためには、順序立った切り分けと記録の徹底 がカギです。これを意識することで、原因を素早く特定できるだけでなく、再発防止やナレッジ共有にもつなげられます。
参考・参照リンク
ネットワークトラブルシュートやコマンドの使い方について、より詳しく学べる外部サイトを紹介します。基礎から実務に直結する情報まで網羅されていますので、調査や学習の際に参考にしてください。
- Linux コマンド集 – ping/traceroute/nslookup など（Linuxコマンド.com）
- traceroute コマンド解説（Qiita）
- nslookup コマンドの使い方（IT用語辞典 e-Words）
- ss/netstat の違いと使い方（Qiita）
- tcpdump チートシート（PacketLife.net）
- curl マニュアル（公式）
これらのリソースを活用することで、記事で紹介したコマンドをさらに深掘りし、日常的なトラブル対応や運用監視に役立てることができます。
