ping は「相手まで IP パケットが届き、返事が戻ってくるか」を確かめる最も手軽なコマンドです。ただし、ping が通らない＝サーバーが落ちている、とは限りません。この記事では Linux・macOS・Windows での基本的な使い方、出力の読み方、そして「自分の端末 → ゲートウェイ → インターネット → 目的のサーバー」の順に確かめて、どこで止まっているかを絞り込む手順を説明します。
ping が確かめているもの
ping は ICMP（Internet Control Message Protocol）の Echo Request を送り、相手から Echo Reply が返ってくるかを見ます。分かるのは次の3点です。
- 相手まで IP レベルで到達できるか
- 往復にかかる時間（RTT、ミリ秒）
- 送った数に対して何回返事が戻らなかったか（パケットロス）
逆に、Web サーバーやデータベースといったアプリケーションが動いているかは ping では分かりません。ICMP は TCP や UDP とは別の仕組みなので、「ping は返るのにサイトが開かない」「ping は返らないのにサイトは見られる」という状況はどちらも普通に起こります。後者は、ファイアウォールで ICMP だけを止めている場合の典型です。
基本の使い方（Linux / macOS / Windows）
Linux と macOS では、ping は止めるまで送り続けます。回数を指定するには -c を使います。
# 4回だけ送る
ping -c 4 example.com
# IPv4 / IPv6 を明示する（Linux の iputils 版）
ping -4 -c 4 example.com
ping -6 -c 4 example.com
# 名前解決をせず IP で直接確かめる
ping -c 4 192.0.2.10Windows の ping は既定で4回送って終わります。回数は -n、止めるまで送り続けるのは -t（Ctrl+C で停止）です。
ping -n 4 example.com
ping -t 192.0.2.10
ping -4 example.comオプションの文字は OS ごとに違います。例えばパケットサイズは Linux が -s、Windows が -l です。迷ったら man ping や ping /? で手元の実装を確認してください。macOS の ping は BSD 系なので、Linux とは一部のオプションが異なります。
出力の読み方
正常に返ってきたときの Linux の出力は次のような形です。
64 bytes from 192.0.2.10: icmp_seq=1 ttl=54 time=12.3 ms
64 bytes from 192.0.2.10: icmp_seq=2 ttl=54 time=11.9 ms
--- 192.0.2.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 11.8/12.1/12.5/0.3 ms見るべきところは次のとおりです。
- packet loss：0% が理想です。数％の損失が続く場合は、回線の混雑や無線の電波状況を疑います。
- time / rtt：同じ国内のサーバーなら数ミリ〜数十ミリ秒が目安です。max と min の差（揺らぎ）が大きいときは、途中のどこかが混んでいる可能性があります。
- icmp_seq：番号が飛んでいれば、その回の返事が戻らなかったということです。
- ttl：返ってきたパケットの残り寿命です。送信元 OS の初期値（Linux 系は 64、Windows は 128 が多い）から経由したルーター数を引いた値になるので、相手の OS の手がかりになることがあります。ただし設定で変えられるため、参考程度にとどめてください。
エラー表示から分かること
ping が失敗したときは、表示の種類で原因の層を推測できます。日本語版 Windows では表記が日本語になり、バージョンによって細部が異なることがあります。
名前解決の失敗Linux の Name or service not known、Windows の「ping 要求ではホスト … が見つかりませんでした」は、ICMP を送る前の DNS で失敗しています。IP アドレスを直接指定して ping が通るなら、ネットワークではなく DNS 設定の問題です。
タイムアウト（返事がない）Windows の「要求がタイムアウトしました」や、Linux で何も表示されずに最後の統計で受信数が 0 になる状態です。経路の途中か相手側で ICMP が捨てられている、相手が停止している、経路がない、のいずれかです。この表示だけではどれか判断できないので、後述の順番で切り分けます。
到達不能（Destination Host Unreachable）誰かが「その宛先には届けられない」と返してきた状態です。表示の先頭に自分の IP が出ている場合は、自分の端末が同じネットワーク内の相手の MAC アドレスを ARP で解決できなかったことが多く、ゲートウェイや LAN 内の問題を示します。ルーターの IP が出ている場合は、そのルーターが先へ進む経路を持っていません。
どこで止まっているかを順番に確かめる
疎通確認は「近いところから遠いところへ」が基本です。いきなり目的のサーバーに ping して失敗しても、どこが悪いのか分かりません。
1. 自分自身（ループバック）
ping -c 2 127.0.0.1ここで失敗するのは珍しく、OS の TCP/IP スタックやローカルのファイアウォール設定がかなり特殊な状態です。
2. 自分の IP アドレスとデフォルトゲートウェイ
まず自分の IP とゲートウェイを確認し、ゲートウェイに ping します。
# Linux
ip -4 addr show
ip route show default
ping -c 4 192.168.1.1rem Windows
ipconfig
ping -n 4 192.168.1.1Windows で IP アドレスが 169.254 で始まっている場合は、DHCP でアドレスを受け取れていません。ゲートウェイに届かない場合は LAN 内（ケーブル、Wi-Fi、ルーター本体、IP 重複など）の問題です。ゲートウェイが応答しない場合の詳しい切り分けは、末尾の関連記事で扱っています。
3. インターネット上の IP アドレス
ゲートウェイまで通ったら、名前解決を挟まずに外部の IP アドレスへ ping します。公開 DNS サービスのアドレス（例：1.1.1.1 や 8.8.8.8）は ICMP に応答することが多く、よく使われます。ここで失敗するなら、ルーターより先（プロバイダーやルーターの WAN 側設定）の問題です。
4. ホスト名での ping
IP では通るのにホスト名では失敗するなら DNS の問題です。nslookup や dig で名前が引けるかを確かめます。
5. 目的のサーバー
最後に目的のサーバーへ ping します。ここだけ失敗する場合、サーバーの停止のほか、サーバー側やクラウドのファイアウォールが ICMP を受け付けていない可能性があります。途中のどこで止まっているかを詳しく見るには traceroute（Windows は tracert）を使います。
ping が返らなくてもサービスは動いていることがある
ICMP を受け付けない設定はよくあります。例えば AWS のセキュリティグループは、許可ルールを追加しない限り ICMP を含む受信を通しません。Windows Defender ファイアウォールも、既定ではエコー要求の受信を許可していない構成が一般的です。
そのため、Web サーバーの生死を確かめたいときは、実際に使うポートへ TCP で接続してみるほうが確かです。
# Linux / macOS：443番ポートに接続できるか
nc -vz example.com 443
# HTTP の応答ヘッダーまで確かめる
curl -I https://example.com/# Windows PowerShell
Test-NetConnection example.com -Port 443自分が管理するサーバーで ping による死活監視をしたい場合は、監視元の IP からだけ ICMP の Echo Request を許可するなど、必要最小限の範囲で開けるのが無難です。
応用：回線品質と MTU を確かめる
長時間の ping で不安定さを見る
「ときどきつながらない」という症状は、短い ping では再現しません。数分〜数十分送り続けて、損失率と RTT の揺らぎを見ます。
# 1秒間隔で600回（約10分）、最後の統計だけ見る
ping -c 600 -q 192.0.2.10Windows なら ping -t で送り続け、Ctrl+C で止めると統計が表示されます。
パケットサイズを変えて MTU 問題を探す
小さな ping は通るのに、大きなファイル転送や HTTPS の通信だけが途中で止まる場合は、経路上の MTU（一度に送れる最大サイズ）が原因のことがあります。フラグメント禁止を指定してサイズを変えながら試します。1472 バイトは、一般的な MTU 1500 から IP ヘッダー 20 バイトと ICMP ヘッダー 8 バイトを引いた値です。
# Linux：フラグメント禁止で 1472 バイト
ping -M do -s 1472 -c 3 192.0.2.10rem Windows
ping -f -l 1472 -n 3 192.0.2.10「フラグメントが必要」といった表示や応答なしになったら、サイズを少しずつ下げて通る最大値を探します。PPPoE 接続などでは MTU が 1500 より小さいことがあります。
注意点
- 大量・高速の ping を他人のサーバーに送るのは迷惑行為になり得ます。確認は自分が管理する機器か、公開されている確認先へ常識的な頻度で行ってください。
- ping の結果は ICMP の扱いに左右されます。途中のルーターは ICMP の処理を後回しにすることがあるため、RTT の数値はあくまで目安です。
- コマンドのオプションや表示は OS やバージョンで変わります（2026年10月現在）。本記事の例は、手元の
man pingやping /?で確かめてから使ってください。
まとめ
- ping は ICMP で IP レベルの到達性と往復時間を確かめるコマンドで、アプリケーションが動いているかは分からない
- 名前解決の失敗、タイムアウト、到達不能はそれぞれ別の層の問題を示す
- 自分 → ゲートウェイ → 外部 IP → ホスト名 → 目的のサーバー、の順に確かめると止まっている場所を絞り込める
- ICMP を止めている環境は多いので、サービスの確認は
ncやcurl、Test-NetConnectionで実際のポートに接続して行う - 長時間の ping で不安定さを、フラグメント禁止の ping で MTU 問題を探せる