この記事は、 「ネットワーク初級編｜通信の仕組みをゼロから学ぶ」 の第29回です。
今回は、pingが通らないときに、どこから確認すればよいのかを順番に学びます。
pingが通らないときの確認順序｜初心者向けに原因を切り分ける7ステップ
pingが失敗したときに、いきなりルーターやサーバーを疑うと調査が遠回りになります。
自分の端末から近い場所を順番に確認すれば、問題が端末・接続・ゲートウェイ・経路・宛先・名前解決のどこにあるのかを切り分けられます。
「サーバーへpingが通りません」と言われたとき、最初からサーバー側を調べる必要はありません。
まず自分の端末が正しく動いているかを確認し、次にデフォルトゲートウェイ、その先の宛先へと、 近い場所から遠い場所へ確認範囲を広げるのが基本です。
この記事を読み終えるとできること
- pingが通らないときの確認順序を説明できる
- どの確認で失敗したかから原因範囲を絞れる
- タイムアウトと到達不能の違いを理解できる
- ping失敗とサービス停止を区別できる
pingが通らないとはどういう状態か
pingが通らないとは、送信したICMP Echo Requestに対して、期待したICMP Echo Replyを受け取れなかった状態です。
pingは、宛先へICMP Echo Requestを送り、相手からICMP Echo Replyが返るかを確認するコマンドです。
応答が返れば、少なくともその時点では、送信元から宛先まで往復できる可能性が高いと判断できます。
ただし、応答が返らない原因は1つではありません。
- 自端末のIPアドレス設定が誤っている
- LANケーブルが抜けている、またはWi-Fiに接続できていない
- デフォルトゲートウェイへ到達できない
- 途中のルーターに経路がない
- ファイアウォールがICMPを拒否している
- 宛先端末が停止している
- 宛先から送信元へ戻る経路がない
- ホスト名をIPアドレスへ変換できていない
pingの失敗だけでは、原因を確定できません。
どこまで成功し、どこから失敗したのかを確認して、問題の範囲を狭めるために使います。
結論：近い場所から遠い場所へ確認する
pingが通らないときは、次の順番で確認します。
pingが通らないときの基本確認フロー
確認の基本原則
成功した最後の地点と、失敗した最初の地点の間に、原因がある可能性が高いと考えます。
たとえば、自端末のIPアドレスへはpingが通るものの、デフォルトゲートウェイへ通らない場合、 問題は自端末からゲートウェイまでの範囲に絞れます。
確認前に宛先と条件を整理する
コマンドを実行する前に、まず「何を確認したいのか」を整理します。 ここが曖昧だと、pingが失敗しても正しく判断できません。
最初に確認する項目
- 送信元端末はどれか
- 宛先はIPアドレスか、ホスト名か
- 同じネットワーク内の通信か、ルーターを越える通信か
- 他の端末からは通信できるか
- 以前は通信できていたか
- 直前に設定変更や配線変更がなかったか
- pingだけが失敗するのか、WebやSSHなども使えないのか
IPアドレスとホスト名を分けて考える
次の2つは似ていますが、確認している範囲が異なります。
ping 192.0.2.10
ping server.example.com| 実行方法 | 主に確認できること |
|---|---|
ping 192.0.2.10 |
IP通信、経路、ICMP応答の可否 |
ping server.example.com |
名前解決に加えて、IP通信、経路、ICMP応答の可否 |
IPアドレスでは成功し、ホスト名では失敗する場合、通信経路よりもDNSや名前の入力ミスを疑います。
STEP 1：自端末のネットワーク設定を確認する
最初に、自端末がネットワークへ接続できる状態かを確認します。 ここで設定が誤っていれば、その先へpingを送っても正常には通信できません。
主な確認コマンド
ipconfig /all- IPv4アドレス
- サブネットマスク
- デフォルトゲートウェイ
- DNSサーバー
- DHCPの利用状況
主な確認コマンド
ip address
ip route
resolvectl status- IPアドレスとプレフィックス長
- インターフェースの状態
- デフォルトルート
- DNSサーバー
物理接続も確認する
- LANケーブルが奥まで接続されているか
- NICやスイッチポートのリンクランプが点灯しているか
- Wi-Fiが有効か
- 正しいSSIDへ接続しているか
- インターフェースが無効化されていないか
169.254.x.xが設定されている場合
WindowsなどでIPv4アドレスが169.254.x.xになっている場合、
DHCPサーバーからIPアドレスを取得できず、自動的にリンクローカルアドレスが設定されている可能性があります。
本来192.168.1.xなどを取得する構成なのに169.254.x.xになっている場合は、
DHCP、VLAN、無線接続、ケーブル、スイッチポートなどを確認します。
STEP 2：ループバックアドレスへpingする
次に、IPv4のループバックアドレスである127.0.0.1へpingします。
ping 127.0.0.1ループバックアドレスは、自分自身のTCP/IP機能へ向けた特別なアドレスです。 LANケーブルやWi-Fi、ルーターを通らず、端末内部で処理されます。
| 結果 | 考え方 |
|---|---|
| 成功 | 端末内部のTCP/IP機能は、少なくとも基本的に動作している |
| 失敗 | OSのネットワーク機能、TCP/IP設定、セキュリティソフトなど端末内部を確認する |
ループバックへのpingが成功しても、LANケーブルやWi-Fi、IPアドレス設定が正常とは限りません。 確認できるのは、主に端末内部のTCP/IP機能です。
STEP 3：自端末のIPアドレスへpingする
自端末に設定されているIPv4アドレスを確認し、そのアドレスへpingします。
ping 192.168.1.10この確認では、自端末のネットワークインターフェースにIPアドレスが設定されていることや、 端末がそのアドレスを自分のものとして処理できることを確認します。
自端末IPへのpingが成功しても、物理ケーブルの先にあるスイッチやルーターまで通信できるとは限りません。 次にデフォルトゲートウェイへpingし、LAN内の外部機器まで到達できるかを確認します。
STEP 4：デフォルトゲートウェイへpingする
異なるネットワークへ通信するとき、端末は通常、デフォルトゲートウェイへパケットを渡します。 そのため、ゲートウェイへpingが通るかは重要な確認ポイントです。
ping 192.168.1.1ゲートウェイへ通らない場合に確認すること
- 自端末のIPアドレスとサブネットマスクが正しいか
- デフォルトゲートウェイのアドレスが正しいか
- LANケーブルやWi-Fiが正常か
- 同じVLANへ接続されているか
- スイッチポートが無効になっていないか
- ARPでゲートウェイのMACアドレスを取得できているか
- ゲートウェイ側インターフェースが稼働しているか
- ゲートウェイがICMP応答を拒否していないか
自端末IPまでは成功し、ゲートウェイで失敗する場合、 問題は自端末から同一LAN内のゲートウェイまでにある可能性が高くなります。
STEP 5：宛先のIPアドレスへpingする
ゲートウェイまで通信できたら、次は目的の宛先をIPアドレスで指定してpingします。
ping 192.0.2.10ゲートウェイまでは成功するのに宛先IPへ失敗する場合、次の範囲を確認します。
- 途中のルーターに宛先ネットワークへの経路があるか
- 宛先側に送信元ネットワークへの戻り経路があるか
- 途中のファイアウォールやACLでICMPが拒否されていないか
- VPNやWAN回線が正常か
- 宛先端末が起動しているか
- 宛先端末のIPアドレスが正しいか
- 宛先端末のOSファイアウォールがICMPを拒否していないか
途中経路を確認する
tracert 192.0.2.10宛先までに通過するルーターを順番に確認します。
traceroute 192.0.2.10
# または
tracepath 192.0.2.10どの区間から応答が得られなくなるかを確認します。
tracertやtracerouteも、途中機器の設定によって応答が表示されない場合があります。
アスタリスクが出た地点を、必ず故障箇所と断定してはいけません。
STEP 6：ホスト名やドメイン名でpingする
宛先IPアドレスへのpingが成功したら、最後にホスト名やドメイン名を指定して確認します。
ping server.example.comIPアドレスでは成功し、ホスト名では失敗する場合、DNSによる名前解決に問題がある可能性があります。
nslookup server.example.com
ipconfig /displaydnsgetent hosts server.example.com
resolvectl query server.example.com
# digが使える環境
dig server.example.com名前解決で確認すること
- ホスト名やドメイン名の入力が正しいか
- DNSサーバーのアドレスが正しいか
- DNSサーバーへ到達できるか
- DNSレコードが登録されているか
- 古いDNSキャッシュを参照していないか
- 社内専用の名前を社外DNSへ問い合わせていないか
IPアドレスで成功し、名前で失敗するなら、IP通信そのものよりも名前解決を優先して調べます。
STEP 7：経路・制御・宛先側を確認する
自端末、ゲートウェイ、DNSの基本確認で原因が見つからない場合は、ネットワーク機器や宛先側の調査へ進みます。
- ルーティングテーブルを確認する 送信元側と宛先側の両方に、相手ネットワークへの経路が必要です。行きの経路だけでなく戻り経路も確認します。
- ACL・ファイアウォールを確認する ICMP Echo RequestまたはEcho Replyが拒否されていないかを確認します。
- NATやVPNの状態を確認する NAT変換、VPNトンネル、セキュリティポリシーなどが通信経路に含まれる場合は、その状態を確認します。
- 宛先端末の状態を確認する 電源、インターフェース、IPアドレス、サブネットマスク、デフォルトゲートウェイ、OSファイアウォールを確認します。
- 別の端末・別の宛先でも比較する 送信元固有、宛先固有、ネットワーク全体のどれかを切り分けます。
比較すると原因範囲を絞りやすい
| 確認結果 | 考えられる範囲 |
|---|---|
| 自分だけ失敗し、他端末は成功 | 自端末の設定、接続、OSファイアウォールなど |
| 同じLANの全端末が失敗 | ゲートウェイ、スイッチ、VLAN、上位回線など |
| 特定の宛先だけ失敗 | 宛先端末、宛先側経路、個別ACL、サービス側制御など |
| IPでは成功し、名前では失敗 | DNS設定、DNSレコード、名前の入力など |
pingの代表的な失敗メッセージ
pingの失敗時に表示されるメッセージから、原因の候補をある程度整理できます。 ただし、OSやネットワーク機器によって表示は異なるため、メッセージだけで断定しないことが重要です。
要求がタイムアウトしました
一定時間内に応答を受け取れなかった状態です。 宛先停止、ICMP拒否、経路障害、戻り経路不足など複数の原因が考えられます。
宛先ホストに到達できません
自端末または途中の機器が、宛先へ届けられないと判断した可能性があります。 ARP失敗や経路不足などを確認します。
ホストが見つかりません
ホスト名をIPアドレスへ変換できていない可能性があります。 入力ミス、DNS設定、DNSレコードを確認します。
「一般エラー」などが表示される場合
Windowsで「一般エラー」が表示される場合は、端末内のルーティング、インターフェース、VPNクライアント、 セキュリティソフトなど、送信前の処理で問題が起きている可能性があります。
メッセージは「どこを優先して調べるか」のヒントです。 必ずIP設定、経路、ARP、ファイアウォール、宛先状態などの確認結果と組み合わせて判断します。
pingが通らなくても通信不可とは限らない
pingが通らないからといって、Web、SSH、RDPなど、すべての通信ができないとは限りません。
ファイアウォールやサーバーでは、セキュリティ方針によってICMP Echo Requestへの応答だけを無効にしている場合があります。 この場合、pingは失敗しても、許可されたTCPやUDPのサービスは利用できます。
pingは失敗する
ping 192.0.2.10
Request timed out.HTTPSは利用できる
curl -I https://192.0.2.10
HTTP/1.1 200 OK目的のサービスを直接確認する
| 確認したい通信 | 確認例 |
|---|---|
| Webサイト | ブラウザ、curl、Test-NetConnection -Port 443 |
| SSH | ssh、Test-NetConnection -Port 22 |
| DNS | nslookup、dig、resolvectl query |
| 特定TCPポート | Test-NetConnection、ncなど |
ping成功＝アプリケーションも正常、ping失敗＝すべて通信不可、ではありません。
pingはネットワーク調査の入口です。最終的には、実際に利用したいサービスが動作するかを確認します。
実例でpingが通らない原因を切り分ける
次の構成で、PC-AからWebサーバーへpingが通らない状況を考えます。
確認結果
| 確認 | 結果 | 判断 |
|---|---|---|
ping 127.0.0.1 |
成功 | 端末内部のTCP/IP機能は動作 |
ping 192.168.10.20 |
成功 | 自端末IPは処理できている |
ping 192.168.10.1 |
成功 | ゲートウェイまでは到達可能 |
ping 192.0.2.10 |
失敗 | ゲートウェイより先、または宛先側を調査 |
次に調べること
- PC-Aのデフォルトゲートウェイが
192.168.10.1か - ルーターに
192.0.2.10への経路があるか - Webサーバー側に
192.168.10.0/24への戻り経路があるか - 途中のACLやファイアウォールでICMPが拒否されていないか
- Webサーバーが起動しているか
- WebサーバーのOSファイアウォールがICMPを拒否していないか
ここでPC-AのLANケーブルを何度も抜き差しする優先度は低いと判断できます。 ゲートウェイへのpingが成功しており、PC-Aから同一LAN内の通信は成立しているためです。
pingが通らないときのよくある失敗
同じコマンドを繰り返しても原因範囲は狭まりません。 自端末、ゲートウェイ、宛先IP、宛先名の順に確認します。
ICMPが拒否されているだけかもしれません。 WebやSSHなど、実際に利用したいサービスも確認します。
pingの応答が戻るためには、宛先から送信元への戻り経路も必要です。 片方向だけ経路がある状態では往復通信が成立しません。
ホスト名ではDNSも確認対象になります。 まずIPアドレスで試し、次に名前で試すと、DNS問題を切り分けやすくなります。
調査結果を順番に記録すると、原因範囲を説明しやすくなり、別の担当者への引き継ぎにも役立ちます。
現場で使える確認結果の報告例
障害対応では、「pingが通りません」だけでなく、どこまで確認したかを伝えることが重要です。
報告例
PC-A（192.168.10.20）からWebサーバー（192.0.2.10）への通信を確認しました。 ループバック、自端末IP、デフォルトゲートウェイ（192.168.10.1）へのpingは成功していますが、 WebサーバーのIPアドレスへのpingはタイムアウトします。 このため、PC-Aからデフォルトゲートウェイまでの接続は正常と考えられ、 現在はゲートウェイより先の経路、ACL、宛先側の戻り経路およびICMP応答設定を確認しています。
「確認した事実」「現時点で分かる範囲」「次に確認すること」を分けると、原因確定前でも正確に報告できます。
理解度チェック
記事の内容を確認するため、次の5問に答えてください。 解答を見る前に、自分で考えてみましょう。
問題1．pingが通らないとき、最も基本的な確認の考え方はどれですか。
- 最初から宛先サーバーを再起動する
- 自分に近い場所から遠い場所へ順番に確認する
- 同じ宛先へ何度もpingする
- 必ずDNSから確認する
解答を見る
自端末、ゲートウェイ、宛先IP、宛先名の順に確認すると、問題範囲を段階的に絞れます。
問題2．ping 127.0.0.1で主に確認しているものは何ですか。
- インターネット回線
- DNSサーバー
- 端末内部のTCP/IP機能
- デフォルトゲートウェイ
解答を見る
127.0.0.1はループバックアドレスで、端末内部のTCP/IP機能を確認します。
問題3．宛先IPへのpingは成功し、ホスト名へのpingは失敗しました。最初に疑うべきものはどれですか。
- DNSによる名前解決
- LANケーブルの断線
- 自端末の電源
- ループバック機能
解答を見る
IPアドレスで通信できるため、IP通信よりもDNS設定やDNSレコード、名前の入力を確認します。
問題4．デフォルトゲートウェイへのpingは成功しましたが、遠隔地のサーバーへのpingは失敗しました。原因候補として適切なものを2つ選んでください。
- 自端末からゲートウェイまでのLANケーブルが必ず断線している
- 途中ルーターに宛先への経路がない
- 宛先側に戻り経路がない
- ループバックアドレスが設定されていない
解答を見る
ゲートウェイまでは到達できているため、ゲートウェイより先の経路や宛先側の戻り経路を確認します。
問題5．「pingが失敗したため、Webサービスも停止している」と断定してよいですか。
解答を見る
ICMPだけが拒否されていて、HTTPSなどの通信は許可されている場合があります。実際のサービスを別に確認します。
実践演習：失敗した地点から原因を考える
PC-Aから社内サーバーへ接続できません。次の構成と確認結果から、原因範囲を考えてください。
確認結果
ping 127.0.0.1 → 成功
ping 10.10.1.20 → 成功
ping 10.10.1.1 → 失敗
ping 10.20.1.50 → 失敗課題1．どこまで正常と判断できますか
課題1の解答例を見る
ループバックと自端末IPへのpingが成功しているため、PC-A内部のTCP/IP機能と自端末IPの処理は正常と考えられます。
課題2．原因がある可能性が高い範囲はどこですか
課題2の解答例を見る
自端末IPまでは成功し、デフォルトゲートウェイで失敗しているため、 PC-Aの接続、IPアドレス・サブネットマスク・ゲートウェイ設定、スイッチポート、VLAN、ARP、ルーター側インターフェースなどを確認します。
課題3．最初に確認する項目を3つ挙げてください
課題3の解答例を見る
- PC-AのIPアドレス、サブネットマスク、デフォルトゲートウェイ
- LANケーブルまたはWi-Fiの接続状態
- スイッチポートのリンク状態とVLAN
- PC-AのARPテーブルでゲートウェイのMACアドレスを解決できているか
- ルーターの10.10.1.1側インターフェースが稼働しているか
自分の言葉で説明する課題
最後に、次の質問へ自分の言葉で答えてください。
後輩から「サーバーへpingが通りません。何から確認すればよいですか」と聞かれました。 1分程度で確認順序を説明してください。
説明例を見る
まず自端末のIPアドレス、サブネットマスク、デフォルトゲートウェイ、接続状態を確認します。 次に127.0.0.1、自端末IP、デフォルトゲートウェイの順にpingし、どこまで成功するかを確認します。 ゲートウェイまで成功したら宛先IPへpingし、必要に応じてtracertやtracerouteで経路を確認します。 IPでは成功して名前では失敗する場合はDNSを確認します。 また、pingが失敗してもICMPだけが拒否されている可能性があるため、実際に利用したいサービスも確認します。
まとめ
- pingが通らないときは、自分に近い場所から遠い場所へ確認する
- 最初に送信元、宛先、IP指定か名前指定か、影響範囲を整理する
- 自端末設定、127.0.0.1、自端末IP、ゲートウェイ、宛先IP、宛先名の順に確認する
- 成功した最後の地点と失敗した最初の地点の間に原因がある可能性が高い
- ゲートウェイより先で失敗する場合は、経路、戻り経路、ACL、ファイアウォール、宛先状態を確認する
- IPでは成功し名前では失敗する場合は、DNSを確認する
- pingが失敗しても、ICMPだけが拒否されている可能性がある
- 最終的には、WebやSSHなど実際に利用したいサービスを確認する
pingは原因を一発で特定するコマンドではなく、通信できる範囲とできない範囲を順番に切り分けるための道具です。
コメント
コメント一覧 （1件）
[…] 前回までに学んだIPアドレス、Ethernetフレーム、ARP… ITジャンプ pingが通らないときの確認順序｜初心者向けに原因を切り分ける7ステップ |… ネットワーク初級編 29／全32記事 この記事は、 […]