pingは、指定した相手（サーバーやドメイン）と通信できるかを確認する、ネットワーク調査の最も基本的なコマンドです。「サーバーにつながらない」「サイトが見られない」といったとき、まずpingでそもそも相手まで届いているのかを確認するのが定石です。ICMPという仕組みで小さなパケットを送り、返ってくるまでの時間（応答速度）やパケットの損失を測ります。
シンプルなコマンドですが、注意点があります。Linuxのpingは-cを付けないと無限に送り続けること、そして最も重要なのが「pingに応答が無くても、そのサーバーが落ちているとは限らない」ことです。多くのサーバーはセキュリティのためping（ICMP）をブロックしていますが、Webサイト自体は正常に動いています。この記事では、実際のホスト（当サイトのサーバーを含む）にpingを送りながら、正しい使い方と読み方を整理します。
ping ホストで到達性を確認。Linuxは-c 回数を付けないと止まりません（Ctrl+Cで停止）。- ドメイン名を指定すると自動でIPアドレスに名前解決されます。
time=◯msが応答時間（小さいほど速い）、ttlは経由できるルーターの残り回数です。- 統計の
packet loss（損失）とrtt min/avg/max（応答時間）で回線品質が分かります。 - 【最重要】応答が無くても「落ちている」とは限りません。ICMPブロックの可能性があります。
-Wでタイムアウト、-iで送信間隔、-sでサイズを調整できます。
HTTPレベルの疎通確認はcurl（-I）、接続の効率化は~/.ssh/config、通信の中身確認はcurl -vもあわせて参考になります。
pingの基本と-c（回数指定）
ping ホスト名で疎通確認を始めます。Linuxのpingは、放っておくと止まらずに送り続けるため、-c 回数で回数を指定するか、Ctrl+Cで止めます（Windowsのpingは既定で4回で止まりますが、Linuxは無限です）。
# -c 3: 3回だけ送って止まる ping -c 3 codingls.com # PING codingls.com (202.226.39.59) 56(84) bytes of data. # 64 bytes from ... (202.226.39.59): icmp_seq=1 ttl=54 time=10.8 ms # 64 bytes from ... (202.226.39.59): icmp_seq=2 ttl=54 time=13.7 ms # 64 bytes from ... (202.226.39.59): icmp_seq=3 ttl=54 time=11.3 ms # -c を付けないと止まらない（Ctrl+C で停止） ping codingls.com
実際に当サイトのサーバー（codingls.com）へping -c 3を送ったところ、3回とも応答があり、それぞれ約10〜13msで返ってきました。各行のicmp_seqは送信の連番、time=◯msが往復にかかった時間（応答速度）です。この数値が小さいほど「近くて速い」ことを意味します。Linuxのpingは-cを付けないと無限に続くので、スクリプトやサーバー上で使うときは必ず回数を指定してください。
名前解決と出力の読み方（ttl / time）
pingにドメイン名を渡すと、自動でIPアドレスに変換（名前解決）してから通信します。これにより、「DNSが正しく引けているか」も同時に確認できます。
ping -c 1 google.com # PING google.com (172.217.221.100) 56(84) bytes of data. # ↑ ドメインが自動でIPに解決された # 64 bytes from ... (172.217.221.100): icmp_seq=1 ttl=104 time=6.16 ms # ↑ttl ↑応答時間 # ttl = 経由できるルーターの残り回数（減っていく） # time = 往復にかかった時間（ミリ秒。小さいほど速い）
実機でも、ping google.comがドメインを自動的にIPアドレス（172.217.221.100）に解決してから通信することを確認しました。もしここで名前解決に失敗すれば、DNSの設定に問題があると切り分けられます。出力のttl（Time To Live）は「パケットが通過できるルーターの残り回数」で、経由するルーターごとに1ずつ減ります。timeは往復時間（RTT）で、国内サーバーなら数ミリ秒〜数十ミリ秒、海外なら数百ミリ秒が目安です。この数値が大きい・ばらつくときは、回線が遅い・混雑しているサインです。
統計サマリーの読み方（パケットロス・rtt）
pingを止めると（または-c回数分終わると）、最後に統計サマリーが表示されます。ここが回線品質を判断する最重要ポイントです。
ping -c 4 8.8.8.8 # ... # --- 8.8.8.8 ping statistics --- # 4 packets transmitted, 4 received, 0% packet loss, time 3005ms # ↑ 損失0% = 全部届いた（良好） # rtt min/avg/max/mdev = 3.513/7.683/13.727/4.353 ms # ↑最小 ↑平均 ↑最大 ↑ばらつき
実機で8.8.8.8（Google DNS）へ4回送ったところ、0% packet loss（損失ゼロ＝全部届いた）で、rtt min/avg/maxが3.5/7.7/13.7msという良好な結果でした。見るべきは主に2つです。packet loss（パケットロス）は「送ったうち何%が届かなかったか」で、0%が理想、数%でも出ていれば回線が不安定なサインです。rttのavg（平均応答時間）は速度の目安、mdev（ばらつき）が大きいと通信品質が安定していないことを示します。「サイトが時々重い」といったときは、pingを長めに送ってこのlossとばらつきを見ると、回線側の問題か切り分けられます。
【最重要】応答が無くても落ちているとは限らない
pingを使ううえで絶対に誤解してはいけないのがこれです。pingに応答が無い（100% packet loss）からといって、そのサーバーが落ちている・Webサイトが見られないとは限りません。多くのサーバーは、セキュリティのためping（ICMP）への応答を意図的にブロックしているからです。
# ICMPをブロックしているホストは、応答が返らない ping -c 2 -W 2 192.0.2.1 # --- 192.0.2.1 ping statistics --- # 2 packets transmitted, 0 received, 100% packet loss # しかし、そのサーバーの Web サイトは正常なことがある！ # → ping ではなく curl で HTTP レベルの疎通を確認する curl -I https://example.com/ # 200 が返れば Web は生きている
実機で、応答しないアドレス（192.0.2.1＝ドキュメント用の予約アドレス）へpingを送ると、2 packets transmitted, 0 received, 100% packet lossという「まったく届かない」結果になりました。しかし、これだけでは「サーバーが落ちている」とは判断できません。近年は、DDoS攻撃の的にされるのを避けるなどの理由で、多くのWebサーバー・クラウドサービスがICMP（ping）への応答を無効化しています。つまり「pingは通らないが、Webサイト（HTTP/HTTPS）は正常に動いている」という状況がごく普通に起こります。「pingが通らない＝サーバーダウン」と早合点すると、原因の切り分けを誤ります。Webサービスの生死を確かめたいなら、pingではなくcurlで実際にHTTPリクエストを送り、ステータスコード（200など）が返るかを見るのが確実です（curl -I https://サイト/）。pingは「ネットワーク層まで届くか」の確認、curlは「アプリケーション層（Web）が応答するか」の確認、と役割を分けて理解してください。
失敗の見分け方（名前解決 vs 到達不可）
pingが失敗するとき、「名前解決の失敗」と「到達できない（応答なし）」は別の問題です。メッセージで見分けられます。
# 名前解決の失敗（DNSの問題） ping -c 1 this-does-not-exist-xyz.invalid # ping: this-does-not-exist-xyz.invalid: Name or service not known # ↑ そもそも名前をIPに変換できていない = DNS/タイプミスの問題 # 到達できない（IPは分かるが応答なし） ping -c 2 192.0.2.1 # 100% packet loss # ↑ IPは分かるが返事が無い = 経路/ファイアウォール/ICMPブロック
実機でも、存在しないドメインへのpingはName or service not known（名前解決できない）というエラーになりました。これはDNSの問題かドメイン名のタイプミスを意味し、「サーバーに届かない」以前の問題です。一方、名前解決はできるのに応答が無い場合は100% packet lossとなり、これは経路の問題やファイアウォール・ICMPブロックを示します。この2つを区別できると、トラブルの原因を素早く絞り込めます。
主なオプション一覧
pingでよく使うオプションをまとめます。
| オプション | 働き |
|---|---|
-c 回数 |
送信回数を指定（Linuxでは必須級） |
-W 秒 |
応答待ちのタイムアウト |
-i 秒 |
送信間隔（既定1秒） |
-s バイト |
送るパケットのサイズ |
time=◯ms |
応答時間（小さいほど速い） |
packet loss |
損失率（0%が理想） |
よくある失敗
pingが止まらない
Linuxは-c 回数を付けないと無限に続きます。Ctrl+Cで止めるか、回数を指定します。
pingが通らないだけでサーバーダウンと判断する
ICMPブロックの可能性があります。Webの生死はcurlで確認します。
名前解決の失敗と到達不可を混同する
Name or service not knownはDNS/タイプミス、100% packet lossは経路の問題です。
応答時間の目安が分からない
国内は数〜数十ms、海外は数百msが目安です。極端に大きい・ばらつくときは回線を疑います。
ファイアウォール環境でpingできない
社内ネットワークなどICMPが制限される環境もあります。curlやポート指定の確認を併用します。
よくある質問
pingは、Windowsと違って回数を指定しないと無限に送り続けます。ping -c 4 ホストのように-cで回数を指定するか、実行中にCtrl+Cを押して止めてください。サーバー上やスクリプトで使うときは、必ず-cを付けるのが基本です。ping（ICMP）への応答をブロックしていますが、Webサイト自体は正常に動いていることがよくあります。実機でも、応答が無い（100% packet loss）状態を確認しましたが、これだけではダウンとは判断できません。Webの生死を確かめるにはcurlでHTTPステータスを確認してください。time=◯msは往復にかかった応答時間で、小さいほど速く、近いことを意味します。国内なら数〜数十ミリ秒が目安です。ttlは経由できるルーターの残り回数で、経由するごとに減ります。応答時間が極端に大きい、またはばらつくときは、回線が遅い・混雑しているサインです。まとめ
ping -c 回数 ホストで疎通確認。Linuxは-cを付けないと止まりません。- ドメインは自動で名前解決され、
time（応答時間）・ttlが表示されます。 - 統計の
packet lossとrttで回線品質を判断します。 - 応答が無くても落ちているとは限りません（ICMPブロック）。Webはcurlで確認。
- 失敗は名前解決エラーと到達不可（loss）を区別して切り分けます。
pingは、ネットワークトラブルの「まず最初の一手」として欠かせないコマンドです。「応答が無い＝サーバーダウン」ではないという一点さえ理解しておけば、原因の切り分けを誤りません。pingでネットワーク層を、curlでアプリケーション層を確認し、問題がどこにあるのかを的確に突き止めましょう。
- grep（文字列検索）
- find（ファイル検索）
- sed（置換・行編集）
- awk（列抽出・集計）
- cut（列の切り出し）
- chmod（パーミッション）
- tar（圧縮・解凍）
- リダイレクトとパイプ
- echo・printf（文字列出力）
- ps・kill（プロセス管理）
- 環境変数とPATH
- which・type（コマンドの正体）
- ln（シンボリックリンク）
- cp・mv・rm（コピー/移動/削除）
- touch・mkdir（ファイル/フォルダ作成）
- basename・dirname（パス分解）
- history（コマンド履歴）
- curl（HTTP通信・API）
- ping（疎通確認）
- dig・nslookup（DNS調査）
- jq（JSON処理）
- vim（基本操作・終了方法）
- cron・crontab（定期実行）
- test・[ ]（条件判定）
- read（入力の読み取り）
- date（日付・時刻）
- sort・uniq・wc（並べ替え/集計）
- xargs（一括処理）
- chown・chgrp（所有者/グループ変更）
- diff（ファイル比較）
- du・df（ディスク使用量）
- head・tail（先頭/末尾・ログ監視）
- cat・less（ファイル表示）
- alias（コマンドの別名）
- nohup（SSH切断対策）
- tmux（セッション管理）
- よく使うコマンドまとめ
- cd（ディレクトリ移動）
