ネットワークトラブルは”ping”で解決、原因を特定する簡単な方法【Windows 10／11】：Tech TIPS

「ping」はTCP/IPにおける最も基本的で、かつ重要なコマンドである。pingが通るかどうかで相手先のPCが稼働しているかどうか、そこまでの通信経路が正しいかどうかを検査できる。pingに応答すれば、そのホストは正常に動作しており、そこまでのネットワークのルーティングが正しく設定されているということが分かる。この機能を使って、ネットワークトラブルの原因を特定する方法を紹介しよう。

» 2025年09月24日 05時00分公開

[デジタルアドバンテージ，著]

連載目次

対象OS：Windows 10／11、Windows Server 2016／2019／2022／2025

　「ping」コマンドは、TCP/IPネットワークにおける最も基本的なツールであるとともに、最も有用なツールの一つでもある（本来pingは「ピン」と読む。ただ、日本では「ピング」と読むのが一般的なようだ）。さまざまな使い方がある中で、一般的には、通信相手が「生きているかどうか」を調べたり、相手までのネットワークの経路が正しく設定され、通信が行える状態になっているかどうかを確かめたりするために使われる。本Tech TIPSでは、ネットワーク管理者の強い味方、pingの基本的な使い方についてまとめておく。

　以下を読み進める前に留意していただきたいのは、デフォルト設定のWindows OSはpingパケットに応答しない（pingの着信を拒否する）という点だ（古いWindows OSを除く）。Windows OSでpingに応答させるには、「セキュリティが強化されたWindows Defenderファイアウォール」アプリあるいはPowerShellの「Set-NetFirewallRule」コマンドレットなどで設定を変更する必要がある。具体的な手順についてはTech TIPS「Windowsでpingが通らない原因はコレ？　ファイアウォール設定で応答を許可する方法」を参照していただきたい。

　LinuxやmacOSなど他の環境では、ping応答がデフォルトで許可されている場合もある。そのため、実際の運用環境ごとにデフォルトで許可／禁止のどちらなのかを確認しておく必要もあるだろう。

pingの仕組み

　pingコマンド（実体はping.exeファイル）は、「ICMP（Internet Control Message Protocol）」の「echo request／echo reply」メッセージを使った、単純なパケットの通信テストプログラムの一つだ。

　TCP/IPネットワークでは、IPやTCP、UDPプロトコルのパケットにさまざまな情報を載せてホスト間で通信をしている。その通信中にエラーが起こった場合、ICMPという補助的なプロトコルを使って、エラーを伝えることになっている。

　echoはICMPでサポートされている機能の一つであり、echoの引数として受け取ったデータをそのまま送信元へ送り返すという動作をする（詳細は、基礎から学ぶWindowsネットワーク「TCP/IPプロトコルを支えるICMPメッセージ」を参照していただきたい）。

　echoはパケットを送り返すだけの単純な機能である。しかし、これが動作するということは、IPアドレスが正しく割り当てられ、かつ途中の経路（ルーティング情報）などが正しく設定され、動作しているということを意味している。途中で不通になっていると応答が返ってこないからだ。

　pingコマンドは、このecho機能を使って、パケットの平均応答時間を測定したり、ネットワーク経路のテストをしたりするためのコマンドである。どんなシステムでも、TCP/IPのプロトコルスタックが起動していて、IPアドレスが割り当てられ、それが正しく動作していて、組み込みのファイアウォールで通信が許可されていれば、このICMPのecho機能は必ずサポートされていることになっている。

　ただ、セキュリティを高めるために、ファイアウォールなどでICMP echo replyをわざとブロックしてpingに応答しない、という運用を組織的に実施している例もよく見かける。トラブルシューティング時には、この点も考慮する必要がある。

pingコマンドの基本的な使い方

　pingコマンドの最も基本的な使い方は、次のように、引数として通信相手のIPアドレスやホスト名を指定して起動する、というものである。

ping ＜宛先PC＞

　例えば「microsoft.com」というドメインにある、「www」というホストに対してpingを実行するには、次のようにする。

ping www.microsoft.com

　これを実行するとWindows OSのpingコマンドは、デフォルトで32bytesのデータ部（データ内容は単なるASCII文字列）を持つICMP echoパケットを4つ生成して、1秒置きに指定された宛先に対して送信する。そして、そのホストからのecho応答メッセージを受信すると、以下のように、応答を受け取るまでの所要時間や、その平均時間などの情報を表示する。

pingコマンドの実行例
pingは、指定されたホスト（IPアドレスか名前で指定する）に対して、ICMPのechoメッセージを送り、それが送り返されてくるのを待つコマンド。応答があれば、通信相手や、そこまでの経路が「生きている」ことが分かる。また、往復時間からネットワークの混雑度もある程度分かる。応答がなければ、通信相手がダウンしていたり、途中の経路設定が正しくなかったり、ファイアウォールでpingがブロックされていたりなど、さまざまな事象が発生していることになる。

　最後に表示されている統計値の意味は、4回パケットを送った結果、4回応答を受け取り（パケット喪失率は0％）、その応答時間は最小3ms、最大6ms、平均4msであった、という意味である。

　たとえローカルのLAN上であっても、最初の1回はARPコマンド要求のために若干遅くなることがある（ARPについてはTech TIPS「WindowsのARPコマンドで通信先を特定する ― MACレベルでの通信相手の特定方法 ―」参照）。そのため、遅延時間を（より正確に）測定したければ、同じpingコマンドをもう1回実行するとよい。コマンドプロンプトで［↑］キーを押して直前のコマンドラインを呼び出し、そのまま［Enter］キーを押せば簡単に再実行できる。

　ネットワーク（TCP/IPプロトコル）が正しく構成されているかどうかを調べるには、このように、相手からpingの応答が戻ってくるかどうかで判断する。

　通信相手がアクティブであるかどうか、そこまでのネットワーク経路が正しく「生きている」かどうかは、「～～からの応答:」の行があるかどうかで判断できる。

　pingの結果からは、次のようなことが分かる。

ネットワークの到達可能性――応答が1つでも返ってくるなら、相手先との通信経路が正しく設定されている
ネットワークの遅延時間――応答（ラウンドトリップ）時間から判断できる。遠くにあるホストほど遅くなる。Windows OSのpingコマンドでは、1ms以下だと「時間 <1ms」と表示される
ネットワークの混雑度――応答が遅い、喪失率が0％でない、応答時間のばらつきが大きい、などの傾向があるなら、ネットワークがかなり混雑している

　なお、応答結果に含まれる「TTL（Time To Live）」は、相手側からこちらへpingの応答が戻ってくるまでに何台のルーターを通過したかを表す数値（ホップ数）である。上の実行例で「TTL=56」となっているのは、初期値の64（推測）から始まって（初期値は255や128、64など、システムによって異なる）、8台ほど経由して戻ってきたと考えられる（ルーターを1台通過するごとに1つ減る）。正確には「tracert」コマンドなどで確認すること（Tech TIPS「tracertコマンドでネットワークの経路を調査する【Windows 10トラブル対策】」参照）。

　これ以外にも例えば、pingを繰り返し実行してシステムの死活管理を行ったり、より大きなサイズのデータを送信してネットワークのMTUサイズや帯域（の概算）を調査したりするなど、多くの使い道があるコマンドである。

Tech TIPS「pingコマンドを繰り返し実行させてネットワーク速度などを測定する【Windows 10／11】」
Tech TIPS「pingでMTUサイズを調査する」
Tech TIPS「pingでネットワークの速度を調査する」

pingに対する応答がない場合は？

　pingを実行しても、相手からの応答がなければ次のように表示される。

pingに応答しないホストの例
pingに対して（想定した時間以内に）応答がない場合は、このように「要求がタイムアウトしました。」と表示される。

　「要求がタイムアウトしました。」は、ICMPの応答を指定された時間内に受け取ることができなかったということを表している。ただしデフォルト待ち時間は1秒（1000ms）なので、インターネット上の宛先を調べる場合は、次のように「-w 5000」などというオプションを使って（待ち時間は1000分の1秒単位で指定する）、応答待ち時間をもう少し長くして調べる必要があるだろう。

ping -w 5000 www.example.co.jp ……各応答を5秒待つ指定

　「要求がタイムアウトしました。」ではなく、次のようなメッセージが表示されることもある。

同一LAN上の存在しないホストに対してpingを実行した場合の例
この例では、ネットワークアドレス「172.16.30.0/24」のLAN内で、「172.16.30.26」から、存在しない「172.16.30.37」というIPアドレスに対してpingを実行している。pingの送信に先立って行われるARPプロトコルに対する応答がないので、自分自身から「宛先ホストに到達できません。」というエラー応答が返ってきているように表示される。

　存在しないIPアドレスに対してpingを実行した場合に、このようなメッセージが表示されることが多い。ただし、システムやファイアウォールの設定などによってメッセージ内容は異なる。とはいえ、指定した相手からの応答がないという点では同じである。

　応答パケットが戻ってこない原因には、さまざまな理由が考えられる。

通信相手がダウンしている
通信相手がpingパケットの送受信を禁止している（許可していない）
経路途中にあるいずれかのルーターがパケットを正しく中継していない
経路途中のファイアウォールもしくはルーターでpingパケットの送受信や中継を禁止している

　正確な原因を突き止めるには、もう少し順序立ててpingを使う必要がある。それには、pingを実行するシステムに近い方から順に応答があるかどうかを調べていけばよい（具体的な手順は後述する）。遠くの方のノード（ホスト）から調べるよりも、素早くトラブルの場所を特定できる。

pingの引数におけるIPアドレスとホスト名の指定方法

　ところでpingの宛先にホスト名やFQDNなどを使う場合、その名前の指定が間違っていると次のようなエラーが表示される。

名前解決が失敗する場合の例
DNSによる名前解決ができない場合は、このようなメッセージが表示される。名前解決が失敗しているのと、pingに応答がないことは全く別の事象である。正しいトラブルシューティングのためには、この2つをきちんと区別して対処する必要がある。

　相手から応答が戻ってこない場合と表示が異なることに注意してほしい。

　この「ping 要求ではホスト＜指定した名前＞が見つかりませんでした。」というメッセージは、「名前解決（名前からIPアドレスを求めること）」が失敗したことを表している。

　この原因は次のように幾つか考えられる。

pingの引数で指定したホスト名やドメイン名が間違っている
（ネットワークインタフェースに付けた）IPアドレスなどの設定が間違っている
DNSサーバやWINSサーバの設定が間違っている
DNSやNBTの名前解決が何らかの原因でうまく動作していない（サーバのIPアドレス設定のミス、経路途中のルーターやファイアウォールなどでブロックされている、など）

　他にもさまざまな要因が考えられるため、簡単に特定することはできない。せっかくpingを使ってトラブルシューティングしようとしているのに、これではさらに話が面倒になるだけだ。このような問題を避けるため、名前解決に失敗した時は、nslookupコマンドなどを使ってIPアドレスが取得できるかどうかも確認しよう（nslookupについてはTech TIPS「DNSトラブル解決の定番、nslookupの基本的な使い方（社内ネットワーク編）」参照）。

IPv6またはIPv4を特定してpingを実行するには

　IPv4だけではなくIPv6も併用しているネットワーク環境は決して少なくない。そしてネットワークトラブルの際には、IPv4あるいはIPv6のどちらか一方に依存していることも考えられる。そのため、IPv4とIPv6のどちらかを明示的に選んでpingを実行したいこともある。

　そのような場合、IPv4でpingを実行するなら「-4」、IPv6なら「-6」というオプションをそれぞれ付けて実行すればよい。

IPv4またはIPv6を指定してpingを実行する

　IPv6で「fe80:～」のようなリンクローカルアドレス宛てにpingを実行する場合は、「-6」オプションを付けるだけではなく、「＜リンクローカルIPv6アドレス＞%＜送信元のインタフェースID＞」というように指定しないと、応答が返らないことがある。＜インタフェースID＞には、pingの送信元でipconfigコマンドを実行したときに表示されるインタフェース番号を指定すればよい（宛先ではない点に注意）。

インタフェースIDを指定しつつリンクローカルIPv6アドレス宛てにpingを実行する例
リンクローカルIPv6アドレス（fe80::/10）は、同一ネットワークセグメント内ノード同士でのみ通信できる。そのため、複数のネットワークアダプタを持つPCでは、宛先のリンクローカルIPv6アドレスのノードと同じセグメントに接続されているインターフェイスアダプタからpingを実行する必要がある。それには、宛先のアドレスの後に「%」を挟みつつ、対象のネットワークアダプタのインタフェースIDを指定すればよい。

　IPv6の詳細については、連載「Windows管理者のためのIPv6入門」が参考になるだろう。

pingを使ってネットワークをチェックする

　さてそれでは、pingを使ってTCP/IPのトラブルシューティングを行う方法について見ていこう。例えばインターネットへのアクセスが全くできなくなった（メールサーバやWebサーバへアクセスできなくなった）とすると、以下のような順番でトラブルの場所（通信が不通になっている場所）を特定していくとよいだろう。

pingでネットワークトラブルの原因を調査する
近くのノード（ホスト）から順にpingで応答があるかどうかを確認する。こうすると、ルーティングが通らないなどの問題のある場所を特定しやすい。図中のIPアドレスは一例である。
　 （1）ローカルループバックアドレスへpingを実行する。TCP/IPが正しくインストールされていれば、これは通るはず。
　 （2）ネットワークインタフェースに割り当てられたIPアドレスにpingを実行してみる。IPアドレスが正しく割り当てられているかどうかが分かる。
　 （3）同一のローカルネットワークセグメント上にあるホストに対してpingを実行してみる。ローカルのネットワーク上のクライアント同士で通信できるかどうかが分かる（この通信にはルーターは関与しない）。
　 （4）ルーター（デフォルトゲートウェイ）に対してpingを実行してみる。デフォルトゲートウェイと通信できるかどうかが分かる。
　 （5）ルーターの出口側のIPアドレスに対してpingを実行してみる。ルーターが正しくルーティングしているかどうか、デフォルトゲートウェイやルーティング設定が正しいかどうかなどが分かる。
　 （6）ルーターを越えた先にあるサーバなどに対してpingを実行してみる。IPアドレスだけでなくサーバ名やFQDNなどでもpingすること。サーバと通信できるか、社内向けDNSサーバの設定が正しいかどうかなどが分かる。
　 （7）インターネットにアクセスしてみる。インターネットアクセスが正しく行え、名前解決やファイアウォールなども正しく動作しているかどうかが分かる。

ネットワークインタフェースやドライバのチェック

　ネットワークがつながらないというトラブルを解決する場合、pingを使うよりも前に、少なくとも次のことを確認しておく（pingとはあまり関係ないので詳細な説明は割愛する）。

ケーブルが正しく接続されているか
ネットワークインタフェースやハブのリンクランプが正しく点灯しているか
無線LANが正しく接続されているか
デバイスドライバが正しく導入されているか
IPアドレスが正しく割り当てられているか

　これらに起因するケースも意外と多いので、まずはネットワークインタフェースが正しく動作しているかどうかを確認することから始めるのが望ましい。

●「タスクマネージャー」でネットワークインタフェースの状態を調べる

　Windows OSの「タスクマネージャー」を見れば、ネットワークインタフェースの状態を簡単に確認できる。

ネットワークインタフェースとIPアドレス
これはタスクマネージャーの「パフォーマンス」タブでネットワークインタフェースの一つを選んだところ。ネットワークインタフェースの状態を簡単に把握できる。

　ネットワークインタフェースにIPアドレスが割り当てられていない状態だと、pingで送信することはできないし、外部からのpingに応答することもない。

　コマンドプロンプト上でネットワークインタフェースの状態を確認するには、ipconfigコマンドを実行するとよい。

ループバックのテスト「ping 127.0.0.1」「ping ::1」

　ネットワークインタフェースが正しく動作しているようならば、次は「ping 127.0.0.1」というコマンドを実行して、正しく応答があることを確認する。

ping 127.0.0.1

　「127.0.0.1」というIPアドレスはIPv4の「ローカルループバックアドレス」といい、TCP/IPプロトコルスタックの内部には必ずこのIPアドレスが用意されている（Tech TIPS「ローカルループバックアドレス『127.0.0.1』『::1』『localhost』とは？」参照）。このアドレスは、常に自分自身を表すことになっているので、127.0.0.1へpingを行うということは、自分自身に対してpingを行うということになる。

　IPv6のループバックアドレスは「::1」である。そのため、IPv6でループバックアドレスにpingを実行する場合は、コマンドラインとして「ping ::1」を指定すればよい。

　もしこのコマンドの実行が失敗するようならば、TCP/IPプロトコルスタックが正しくインストールされていないことになる。現在のWindows OSでは必ずTCP/IPプロトコルがインストールされているので、このコマンドの実行が失敗するのは、ネットワークが使えないセーフモードの場合か、（OSの復元や再インストールが必要なほど）TCP/IPプロトコルスタックに何らかの深刻なダメージがある場合だろう。

ローカルIPテスト「ping ＜自分のIPアドレス＞」

　ローカルループバックアドレスの次にチェックすべきことは、自分に割り当てられているIPアドレスに対するpingの実行である。例えば、自分のPCに「172.16.30.26」という固定のIPv4アドレスを割り当てている（はず）なら、次のように実行してみる。

ping 172.16.30.26

　IPアドレスをDHCPで自動割り当てしている場合は、ipconfig.exeコマンドで確認してもよいだろう。DHCPでのIPアドレスの取得に失敗していると、「0.0.0.0」というアドレスか、APIPAで割り当てられる「169.254.～.～」になっているはずである。

　このpingコマンドにより、自分自身に正しくIPアドレスが割り当てられているかどうかを確認できる。もし失敗するようならば、IPアドレスの設定方法（手動割り当てやDHCPによる割り当て方法）に問題があることが分かる。

　またネットワークケーブルが外れているなど、正しく接続できていない場合にも（クロスケーブルとストレートケーブルを間違えたり、他のPCと固定IPが衝突したりした場合など）、IPアドレスの割り当ては失敗するので、これらも確認する。

pingが失敗する例
IPアドレスの割り当てが失敗している場合のエラーの例（Windows 11上で実行）。ローカルループバック以外のIPアドレスがない場合にpingを実行しようとすると、このようなメッセージが表示される。

ルーティングなしの通信テスト「ping ＜LAN上のPC＞」

　自分自身に正しくIPアドレスが割り当てられていることが分かったら、次はいよいよ他のPCとの通信をテストしてみる。

ping ＜LAN上のPC＞

　最初にpingすべき相手は、「同一のLAN（同一のイーサネット）上に存在している、同じネットワークアドレスを持つシステム」である。もちろん相手側ではpingに応答するように設定しておくこと（Windows OSでは冒頭で説明したようにpingの明示的な許可が必要）。できることなら、現在稼働していることが確実で、IPアドレスが固定的に割り当てられているシステム、例えば全員で共有しているファイルサーバやルーターなどが望ましい。

　これが成功するようなら、IPアドレスの割り当てが正しく行われ、ハードウェアやデバイスドライバ、TCP/IPプロトコルスタックなども正しく動作しているということになる。

　もし失敗するようならば（無応答ならば）、デバイスドライバなどが正しく動作していない／インストールされていないなど、ハードウェア的なトラブルである可能性が高い。

ルーティングありの通信テスト「ping ＜ローカルネットワーク以外のIPアドレス＞」

　LAN上の相手に対してpingが成功するようならば、次は（インターネットや社内の他のネットワークに接続するための）ルーターや、そのルーターの先にあるシステムに対してpingを実行してみる。

ping ＜ローカルネットワーク以外のIPアドレス＞

　これが失敗するようなら、デフォルトゲートウェイのIPアドレスや（サブ）ネットマスクの設定などがおかしい、もしくは設定するのを忘れている、などの理由が考えられる（Tech TIPS「Windows OSのデフォルトゲートウェイは1つのみ有効」が参考になるだろう）。

　また逆に、ping先の機器から逆向きのルート設定がどこかで間違っていても、やはり応答が戻ってこなくなる。ルーティングの設定については、Tech TIPS「ネットワークのルーティングは双方向で設定する」も参照していただきたい。

名前解決のテスト「ping ＜名前＞」

　ここまで成功するようなら、次はIPアドレスではなく、ホスト名を指定してpingを実行してみる。

ping ＜名前＞

　＜名前＞としては、ローカルのLAN上にあるシステム名（ドメイン名を含まないホスト名）や、FQDN形式のホスト名（社内にあるファイルサーバやDNSサーバ、Webサーバ、メールサーバなど）など、いろいろ試してみる。これに失敗するようなら、名前解決のための設定が正しく行われていないことが分かる。

　ただしセキュリティ上の理由によって、外部からのpingコマンドを受け付けないようにファイアウォールやシステムなどが設定されている場合もある。そのため、pingコマンドに対する応答がないからといって、必ず相手先との通信ができなくなっていると結論付けることはできない。

　もし単純なホスト名（FQDN形式でないホスト名）に対するpingが失敗するようならば、WINSサーバの設定などをチェックする。Windows OSでは、NetBIOS名による名前の登録や解決が自動的に行われるので、Windows OS搭載PCに対するpingが失敗することはそう多くないだろう。

　しかしWINSとhostsファイル、lmhostsファイルで互いに異なるようなホスト定義が行われていると、名前解決の優先度の問題によって、間違ったホストに対してpingを実行してしまう可能性がある（また、NetBIOSの名前解決方法を強制的にブロードキャスト以外に設定しているなどすると失敗する可能性がある）。

　Windows以外のOSを搭載したPCに対しては、hostsファイルやDNSなどで対応しなければならないので、その設定を間違えるとやはりpingできないことがあるので注意したい。

　またFQDN形式のホスト名に対するpingが失敗するようならば、DNSサーバのアドレスやTCP/IPのドメイン名の設定などに問題がある。

　ルーターを越えた先にあるホストからpingへの応答がなければ、ルーティングの設定などをチェックする。

一般的な通信テスト「ping ＜インターネット上のサーバ＞」

　以上のチェックを全てパスするようなら、通信できない理由は、インターネットのサービスに接続するための（社内の）ルーターやDNSサーバ、Proxyサーバがダウンしているなど、プロバイダーのネットワークがダウンしている、インターネット上の目的のサーバそのものがダウンしている、pingへの応答がファイルで禁止されている、などが考えられる。

　あとはケース・バイ・ケースで、これらのホストに順次pingを実行したり、他のツール（そのホストが提供しているサービスに対応したツール）などで接続したりして、不通となっている場所やサービスを特定すればよい。