社内PCで ping を実行したら「Request timed out」または「要求がタイムアウトしました」と表示されることがあります。
この表示だけでは、相手PCやサーバーが故障しているとは判断できません。自分のPCの設定、途中のネットワーク、ファイアウォールによるICMP制御など、原因候補は複数あります。
確認するときは、影響範囲 → 自分のPC → デフォルトゲートウェイ → 通信先・経路 → ICMP制御 → 必要ならDNSの順で切り分けると、設定をむやみに変更せず原因を絞れます。
ping コマンド自体の基本的な使い方を確認したい場合は、pingとは？を先に確認してください。
pingの「Request timed out」とはどういう意味か
Windowsの ping は、相手へICMP Echo Requestを送り、Echo Replyが返ってくるかを確認するコマンドです。
一定時間内に対応するEcho Replyを受信できなかった場合に、次のように表示されます。
Request timed out.
要求がタイムアウトしました。
ここで分かるのは、時間内にpingの応答を受信できなかったということです。この表示だけでは原因までは決まりません。
たとえば、次のような可能性があります。
- 相手端末が停止している
- 自分のPCから相手までの途中で通信できなくなっている
- ファイアウォールやACLなどでICMPが遮断されている
- 相手端末やネットワーク機器がpingへ応答しない設定になっている
そのため、Request timed out を見ただけで「相手が故障した」と決めつけず、近いところから順番に確認します。
最初に1台だけか複数台か確認する
最初に確認するのはPCの設定ではなく、影響範囲です。
- 自分のPCだけで発生しているか
- 同じ部署・フロアの複数PCでも発生しているか
- 同じネットワークの端末全体で発生しているか
- 社内全体で発生しているか
自分のPCだけなら、そのPCの接続状態やIP設定を優先して確認します。
一方、複数台で同時に同じ宛先へ通信できない場合は、各PCの設定を1台ずつ変更する前に、共有しているネットワーク機器や通信経路側を疑います。
影響範囲からネットワーク全体を切り分けたい場合は、社内ネットワークにつながらないときの切り分け方も参考になります。
何にpingしたのかを確認する
同じ Request timed out でも、pingを送った相手によって次に確認する場所が変わります。
- デフォルトゲートウェイ
- 社内サーバー
- プリンターなどのネットワーク機器
- 別のPC
- 社外のIPアドレス
- ドメイン名
特に、IPアドレスを直接指定した場合と、名前を指定した場合は分けて考えます。
ping 192.168.1.20
のようなIPアドレス指定では、主にそのIPアドレスまでの到達性を確認します。
一方、
ping example.com
のような名前指定では、pingを送る前に名前をIPアドレスへ変換する処理も必要です。IPアドレス指定では通信できるのに名前指定だけ失敗する場合は、DNSなど名前解決側の問題も候補になります。
ipconfigで自分のPCの状態を確認する
相手側を調べる前に、自分のPCのネットワーク設定を確認します。コマンドプロンプトで次を実行します。
ipconfig /all
主に確認するのは次の項目です。
- IPv4アドレス
- サブネットマスク
- デフォルトゲートウェイ
- DNSサーバー
会社PCがDHCPからIPアドレスを取得する設定なのに、IPv4アドレスが 169.254.x.x になっている場合は、Windowsの自動プライベートIPアドレス設定（APIPA）が働いている可能性があります。
この場合は、DHCPから通常のIP設定を取得できていない可能性があるため、ping先より先にLAN・Wi-Fi接続やDHCPまでの経路を確認します。
ただし、169.254.x.x だけを見て「DHCPサーバーが故障した」と断定はできません。途中のLANケーブル、無線接続、スイッチ、VLANなどでも同じ状況は起こり得ます。
ipconfig の詳しい見方は、ipconfigとは？初心者向けに使い方・見方・確認できる項目をやさしく解説で確認できます。
まずデフォルトゲートウェイへpingする
IP設定に大きな違和感がなければ、ipconfig /all で確認したデフォルトゲートウェイへpingします。
ping 192.168.1.1
192.168.1.1 は例です。実際には、自分のPCに設定されているデフォルトゲートウェイのIPアドレスを使ってください。
ゲートウェイへpingが通る場合
少なくとも、そのping確認では自分のPCからデフォルトゲートウェイまで応答を受信できています。
目的の通信先へpingが通らないなら、次はゲートウェイより先の経路、通信先、ICMP制御などへ確認範囲を移します。
ゲートウェイでもRequest timed outになる場合
自分のPCに近い部分も原因候補になります。
- Wi-Fiや有線LANの接続状態
- PCのIP設定
- LANケーブルやポート
- 無線LANアクセスポイント
- VLANなどのネットワーク構成
- ゲートウェイ側のICMP応答制限
ただし、ゲートウェイ自体がICMP Echo Requestへ応答しない設定の場合もあります。ping結果だけで「ゲートウェイが故障している」「ネットワークが完全に切れている」と断定しないでください。
ゲートウェイは通るのに相手へ通らない場合
デフォルトゲートウェイへのpingは成功するのに目的の通信先では Request timed out になる場合、自分のPC直近より先へ確認範囲を絞れます。
次の順で見ます。
- pingしたIPアドレスが正しいか
- 相手端末が起動しているか
- 別のPCから同じ相手へ通信できるか
- VPNを使う通信ならVPNが接続されているか
- 相手までのルーティングやネットワーク機器に変更がなかったか
- ファイアウォールやACLでICMPが制限されていないか
- 相手端末自体がpingへ応答する設定か
ここでも、原因候補を全部試すのではなく、どこまでは応答を確認できたかを基準に次の確認場所を決めます。
Request timed outとDestination host unreachableの違い
pingでは Request timed out とは別に、Destination host unreachable や「宛先ホストに到達できません」と表示されることがあります。
Request timed out
一定時間内に対応するEcho Replyを受信できなかった状態です。
途中でパケットが失われた場合、相手が停止している場合、ICMPが遮断されている場合、相手が応答しない設定の場合など、複数の原因が考えられます。
Destination host unreachable
送信元PCまたは途中のネットワーク機器から、宛先ネットワークや宛先ホストへ到達できないことを示す応答が返っている状態です。
同一ネットワーク内では、宛先のMACアドレスを確認するARPに応答がない場合などでも発生します。また、経路やネットワーク構成の問題で途中機器が到達不能と判断する場合もあります。
つまり、
Request timed out→ 時間内にEcho Replyを受信できなかったDestination host unreachable→ どこかの機器から「宛先へ到達できない」という通知を受けた
という違いがあります。
どちらもping失敗ではありますが、同じ原因だと決めつけず、表示内容を切り分け材料にします。
pingが通らなくてもサービスは使えることがある
Webサイト、サーバー、ネットワーク機器などでは、ICMP Echo Requestへの応答を制限していることがあります。
そのため、
ping失敗 ＝ そのサービスへ通信できない
とは限りません。
ブラウザでWebサイトを開けたり、業務システムを利用できたりしても、pingだけは Request timed out になることがあります。
逆に、
ping成功 ＝ Web・ファイル共有・業務システムも正常
とも限りません。
pingで確認できるのはIPレベルの到達性を判断する材料です。Webやファイル共有などのサービスでは、DNS、TCP/UDPポート、アプリケーション側の状態など別の要素も関係します。
ファイアウォールを安易に無効化しない
Request timed out が出たからといって、原因確認のために会社PCのファイアウォールを全面的に無効化するのは避けます。
会社PCでは、セキュリティポリシーや管理設定が適用されている場合があります。ファイアウォールを無効化すると、別のセキュリティリスクを増やすだけでなく、元の設定へ戻せなくなる可能性もあります。
ICMP制御が疑われる場合は、次の方向で確認します。
- 会社の管理ルールを確認する
- 許可されている場合はファイアウォールログを確認する
- ICMPに関する許可・拒否ルールを確認する
- 管理者やベンダーへ設定を確認する
ファイアウォール自体の役割は、ファイアウォールとは？で確認できます。
tracertで通信経路を追加確認する
デフォルトゲートウェイまではpingが通るものの、離れた通信先へ届かない場合は、tracert が追加の切り分け材料になります。
tracert example.com
tracert は、宛先までの経路上でどの機器を通っているかを見るためのコマンドです。
ただし、途中に * やタイムアウト表示があっても、その地点のルーターが故障しているとは限りません。途中機器がtracertに必要なICMP応答を返さない一方で、その先への通信は転送している場合があります。
そのため、途中の1行だけではなく、その先まで結果が続いているか、最終的な宛先へ到達しているかも含めて見ます。
詳しい読み方は、tracertとは？で確認してください。
ドメイン名だけ失敗する場合はDNSも確認する
次のような結果になった場合は、名前解決側を確認します。
- IPアドレスを直接指定すると通信できる
- ドメイン名を指定すると名前を解決できない
Microsoftのpingドキュメントでも、IPアドレスへのpingが成功し、コンピューター名へのpingが失敗する場合は、名前解決の問題が考えられるとされています。
確認には nslookup を使えます。
nslookup example.com
DNSの切り分けが必要になった場合は、「DNSサーバーは応答していません」と表示されたときの対処法とnslookupとは？を参考にしてください。
ping結果だけでDNS障害と断定せず、IP指定と名前指定の違い、nslookup の結果、他端末の状況を組み合わせて判断します。
ベンダーや詳しい担当者へ伝える情報
自分たちだけで原因を特定できない場合は、確認結果を整理してベンダーや詳しい担当者へ引き継ぎます。
次の情報があると、調査範囲を絞りやすくなります。
- 発生日時
- 1台だけか、複数台か
- Wi-Fiか有線LANか
- pingした宛先
- IPアドレス指定か名前指定か
- pingの実行結果
- デフォルトゲートウェイへのping結果
ipconfig /allの主要情報tracertを実施した場合はその結果- 他PCから同じ宛先へ通信できるか
- 直前にネットワーク関連の変更がなかったか
コマンド結果はスクリーンショットやテキストで残しておくと、後から状況を説明しやすくなります。
まとめ
pingで Request timed out が表示されても、相手端末の故障とは限りません。
確認するときは、
- 影響範囲
- 自分のPCのIP設定
- デフォルトゲートウェイ
- 目的の通信先
- 通信経路
- ICMP制御
- 必要ならDNS
の順に、近いところから範囲を絞ります。
pingは原因を確定するためのコマンドではなく、どこまで通信できているかを確認し、次に見る場所を決めるための材料として使うのが基本です。