「ping は返ってくるのに、なぜかブラウザで Web サイトが開けない」
ネットワークの調査では、こうした場面がよくあります。
一見すると「相手に届いているのだから、Web も見られるはず」と思いがちですが、実際には ping と Web 通信は同じではありません。
ping は、相手まで最低限届いているかを見る確認です。
一方で Web ページを開くときには、DNS、TCP、HTTP/HTTPS など、いくつかの段階を順番に通る必要があります。
この記事では、「ping は通るのに Web が開けないのはなぜか」を、初心者向けにやさしく整理します。
あわせて、実務で使いやすい切り分けの順番も紹介します。
まず結論｜pingが通ってもWebが開けるとは限らない
先に結論を書くと、ping が通ったからといって Web が開けるとは限りません。
ping は、ICMP という仕組みを使って、相手から応答が返ってくるかを確認します。
つまり「その相手に最低限届いているか」を見るための確認です。
一方、ブラウザで Web サイトを開くときには、次のような段階があります。
- DNSで名前をIPアドレスに変換する
- 多くの場合はTCPで接続を作る
- HTTP/HTTPSでページの中身をやり取りする
このどこか一つでも失敗すると、Web は開けません。
たとえるなら、ping は「玄関のチャイムを鳴らして反応があるか」を見ている状態です。
チャイムに反応があっても、受付が閉まっていたり、目的の窓口が止まっていたりすれば、中には入れません。
Web が開けないときは、まさにそのようなイメージです。
pingとは何か？確認できること・できないこと
pingはICMPを使った疎通確認
ping は、ICMP を使って相手の応答を確認するコマンドです。
ネットワーク調査では、「そもそも相手まで届いているのか」を見る最初の確認としてよく使われます。
たとえばサーバーやルーターに ping を送って返事があれば、少なくともその相手に対して完全に通信断しているわけではなさそうと考えられます。
pingでわかること
ping でわかるのは、主に次のようなことです。
- 相手まで届いているかの目安
- 応答時間が極端に遅くないか
- 切り分けの入口として使えるか
たとえば、デフォルトゲートウェイには届くのに宛先サーバーには届かない場合、途中経路や宛先側を疑うヒントになります。
pingでわからないこと
一方で、ping だけではわからないことも多くあります。
- DNS が正常か
- TCP の 80 番や 443 番に接続できるか
- Web サーバーやアプリが正常か
- HTTPS の証明書や TLS 設定が正しいか
特に初心者がつまずきやすいのがここです。
ping は ICMP を使いますが、Web 通信は多くの場合 TCP の 80 番や 443 番を使います。
つまり、使っている通信の種類が違うため、ICMP は通っても Web 通信だけ失敗することが普通にあります。
pingコマンドの基本的な使い方や、Windowsでの実行方法については、こちらで詳しく解説しています。
Web通信はDNS → TCP → HTTP/HTTPSの順で進む
まずDNSで名前解決する
ブラウザで example.com のような URL を開くとき、最初に必要なのは DNS です。
DNS は、ドメイン名を IP アドレスに変換する仕組みです。
ここで失敗すると、相手のサーバーが生きていても Web は開けません。
たとえば、IP アドレスを直接指定すれば届くのに、ドメイン名では失敗する場合は、まず DNS を疑います。
次に多くの場合はTCPで接続を確立する
DNS で IP アドレスが分かったら、次は相手と通信を始めるための接続を作ります。
Web 通信では、多くの場合 TCP が使われます。
ここで重要なのは、ping と Web では使う仕組みが違うことです。
ping は ICMP、Web は多くの場合 TCP。
そのため、ping は成功しているのに TCP の 80 番や 443 番だけが止められていることがあります。
そのあとHTTP/HTTPSでページの中身を受け取る
TCP で接続できたら、HTTP または HTTPS を使って Web ページのデータを受け取ります。
ここでブラウザは HTML や画像、CSS などを受け取って画面を表示します。
最近の Web は HTTPS が主流です。
そのため、443 番ポートまでは届いていても、証明書や TLS の問題で失敗することもあります。
つまり、Web 表示は
- DNS
- TCP
- HTTP/HTTPS
という複数の段階で成り立っていて、どこか一つでも止まるとブラウザでは開けません。
Firewallとは？なぜpingは通るのにWebだけ止められるのか
Firewallは“通してよい通信”を選別する仕組み
Firewall は、ネットワーク上を流れる通信を見て、通してよいものだけを通す仕組みです。
送信元IP、宛先IP、プロトコル、ポート番号などを見て判断します。
このため、通信を全部まとめて許可・拒否しているわけではなく、通信ごとに別々に判断していると考えるのが大切です。
ICMPとTCP/80・443は別の通信として扱われる
Firewall から見ると、ping と Web は別物です。
- ping：ICMP
- Web：多くの場合 TCP の 80 番 / 443 番
そのため、
- ICMP は許可
- TCP/80 は拒否
- TCP/443 だけ許可
といった設定も普通にあります。
つまり、「ping に返事がある」ことと「Web ページが見られる」ことは、Firewall の観点では別の話です。
ポート番号とは“アプリの入り口番号”
Web 通信を理解するうえで、ポート番号も重要です。
IP アドレスが住所だとすれば、ポート番号はその建物のどの窓口に用があるかを示す番号です。
たとえば、
- 80番ポート：HTTP
- 443番ポート：HTTPS
のように使い分けられます。
サーバー自体には届いていても、この窓口が閉じていれば Web は使えません。
つまり、住所までは合っているが、目的の窓口が閉まっている状態です。
pingは通るのにWebが開けない典型的な原因
DNSで名前解決できていない
よくある原因の一つが DNS の失敗です。
- IP アドレスで ping は通る
- ドメイン名では失敗する
この場合、ネットワーク全体ではなく、名前解決の段階で止まっている可能性が高いです。
TCPの80番・443番ポートが閉じている
Web 用のポートに接続できないケースです。
- サーバー側でサービスが待ち受けていない
- Firewall で止められている
- 途中の ACL や経路制御で遮断されている
この場合、相手には届いているのに、Web の入り口だけ閉まっています。
Webサーバーやアプリが正常に動いていない
ネットワークやポートに問題がなくても、Web サーバーやアプリ自体が止まっていることがあります。
たとえば、
- Apache / Nginx が停止している
- アプリケーションエラーが出ている
- バックエンドとの連携に失敗している
といったケースです。
この場合、サーバー自体は ping に応答しても、ブラウザではページを表示できません。
HTTPS特有の問題が起きている
最近は HTTPS が主流なので、次のような問題もあります。
- 証明書エラー
- TLS 設定不整合
- 端末やブラウザとの互換性問題
この場合、443 番ポートまでは届いていても、その先の安全な通信開始で失敗していることがあります。
経路や中継機器の問題がある
途中にある機器が原因になることもあります。
- プロキシ
- UTM
- ロードバランサー
- 途中のルーターや Firewall
Web 通信は ping より通る仕組みが多いため、途中で制御される場所も増えます。
そのため、「相手サーバーの問題」に見えても、実際には途中機器で止まっていることがあります。
実務で使える切り分け手順｜どこで止まっているかを順番に確認する
手順1：物理接続と基本設定を確認する
まずは足元から確認します。
- LANケーブルやWi-Fi接続
- IPアドレス
- デフォルトゲートウェイ
- 自分の端末設定
ここが崩れていると、その先を調べても正しい答えにたどり着きません。
手順2：pingで最低限の疎通を確認する
次に ping で確認します。
- デフォルトゲートウェイに ping
- 宛先サーバーの IP アドレスに ping
ここで見るのは、「どこまで届いているかの目安」です。
ping はゴールではなく、切り分けのスタート地点です。
手順3：DNSで名前解決できるか確認する
次は DNS です。
- ドメイン名では失敗するか
- IP アドレスでは届くか
たとえば、nslookup を使うと名前解決の確認がしやすくなります。
nslookup example.com
ここで IP アドレスが返るかどうかを見ると、DNS の切り分けに役立ちます。
手順4：ポート80/443に接続できるか確認する
Web の窓口が開いているかを確認します。
Windows なら PowerShell の Test-NetConnection、Linux や macOS なら curl などが使えます。
例：
Test-NetConnection example.com -Port 443
ここで接続できなければ、Firewall やポート閉塞を疑います。
手順5：Firewallや経路制御を疑う
80 番 / 443 番に接続できない場合は、Firewall や途中の制御を確認します。
- 端末のローカル Firewall
- サーバー側 Firewall
- 途中のネットワーク Firewall
- セキュリティグループや ACL
- プロキシや UTM
大事なのは「どこの Firewall か」を分けて考えることです。
※DNS向け（例：8.8.8.8）の許可設定が漏れていないかも注意して確認しましょう
手順6：tracerouteやログで“どこまで進んだか”を見る
ここまでで分からなければ、traceroute やログを確認します。
- traceroute で途中経路のヒントを見る
- Firewall ログ
- サーバーのアクセスログ
- プロキシログ
ここまで確認すると、
- どこまで届いているか
- どこで止められているか
- 誰に相談すべきか
がかなり整理しやすくなります。
まとめ｜“通信が通る”には段階がある
ping が通ることは、相手まで最低限届いているサインです。
ですが、それだけで Web 通信の成功までは保証できません。
Web を開くには、次の段階を順番に通る必要があります。
- DNS で名前解決する
- 多くの場合は TCP で接続を作る
- HTTP/HTTPS で中身をやり取りする
- Firewall や中継機器の制御を通過する
つまり、「通信が通る」とは一つの状態ではなく、いくつもの段階がうまく動いている結果です。
トラブル時は、ping → DNS → TCP/ポート → HTTP/HTTPS → Firewall の順で見ると整理しやすくなります。
この考え方を身につけるだけでも、ネットワークトラブルはかなり分かりやすくなります。
DNS や traceroute の詳しい使い方は、関連記事もあわせて確認してみてください。
