「ping は通る」「DNS が引けない」「ポートが開いていない」。現場でよく聞くこの3つは、それぞれ違う層の話をしています。ここが分かると、「つながらない」と言われたときに、どこから確かめればいいかが決まります。前の記事ネットワークとは何かの言葉（住所・窓口・約束事・層）を使って、ブラウザに URL を打ってからページが出るまでを追います。
この記事の結論
- URL を打ってからページが出るまでは、DNS で名前を住所に変える → IP で相手まで届く → TCP で接続を作る → HTTP で中身をもらうの4段階です。
- DNS は「名前から住所を引く電話帳」。引けなければ、サーバーがどんなに元気でも「つながらない」になります。
- ping は「相手まで届くか」と「往復にかかる時間」だけを確かめる道具です。窓口（ポート）が開いているかは分かりません。
- ping が返ってこなくても壊れているとは限りません。途中のファイアウォールが ping の約束事（ICMP）だけを止めていることが多いからです。
- 「つながらない」は、名前 → 経路 → 通過 → 窓口の順に切り分けます。AWS でも順番は同じです。
URL を打ってからページが出るまでの4段階
ブラウザに https://example.com/ と打つと、裏では次のことが順に起きています。
URL TO PAGEURL を打ってからページが出るまで
名前を住所に変え、届き、つなぎ、中身をもらう
-
DNS
example.com → 203.0.113.10
-
IP
その住所までパケットが届く
-
TCP
443 番に接続を作る（3往復）
-
HTTPS
ページの中身をもらう
- 名前を住所に変える（DNS）。 ブラウザは
example.comという名前では通信できません。まず DNS に「example.com の IP アドレスは?」と聞き、「203.0.113.10」のような住所をもらいます。 - 住所まで届く（IP）。 もらった住所に向けてパケットを送ります。途中のルーターが宛先を見て、次のルーターへ手渡していきます。
- 接続を作る（TCP）。 相手の 443 番の窓口に「話していい?」と聞き、「いいよ」と返ってきたら「じゃあ始める」で接続ができます（3ウェイハンドシェイク）。
- 中身をもらう（HTTPS）。 接続の上で「このページをください」と頼み、HTML が返ってきます。HTTPS なので、この会話は暗号化されています。
「つながらない」は、この4段階のどこかで止まっている状態です。止まっている段階が分かれば、直す場所が分かります。
DNS は「名前から住所を引く電話帳」
DNS（Domain Name System）は、example.com のような人が読める名前を、203.0.113.10 のような IP アドレスに変換する仕組みです。仕様は 1987 年の RFC 1034 と RFC 1035 で定められ、いまもインターネットの土台です。
電話帳と違うのは、1冊の本ではなく、階層に分かれた電話帳を順にたどることです。
NAME RESOLUTION階層の電話帳をたどる
名前解決は、知っている人に順に聞く
-
端末
自分のキャッシュ
最近引いたなら覚えている（TTL の間）
-
リゾルバ
プロバイダや VPC の DNS サーバー
覚えていなければ、代わりに探しに行く
-
ルート
ルートサーバー
「.com のことは .com のサーバーに聞いて」
-
TLD
.com のサーバー
「example.com のことは、その権威サーバーに聞いて」
-
権威
example.com の権威サーバー
「203.0.113.10 です」
| 段階 | 誰に聞くか | 答え |
|---|---|---|
| 1 | 自分の端末のキャッシュ | 最近引いたなら覚えている |
| 2 | リゾルバ（プロバイダや会社の DNS サーバー、AWS なら VPC の中の DNS） | 覚えていなければ代わりに探しに行く |
| 3 | ルートサーバー | 「.com のことは .com のサーバーに聞いて」 |
| 4 | .com のサーバー（TLD） | 「example.com のことは、その権威サーバーに聞いて」 |
| 5 | example.com の権威サーバー | 「203.0.113.10 です」 |
答えにはTTL（有効期間）が付いていて、その時間だけ各段階が覚えておきます。だから、サーバーの住所を変えた直後は、古い住所を覚えている人がしばらく残ります。「DNS の切り替えは反映に時間がかかる」と言われるのはこのためです。
DNS が引けなければ、サーバーがどんなに元気でも「つながらない」。だから切り分けの最初は、名前が住所に変わっているかを確かめることです。コマンドなら dig example.com や nslookup example.com で、返ってきた IP アドレスを見ます。
CHECK 1ここまでの確認
URL を打ってからページが出るまでの4段階で、最初に起きることはどれ?
答えと解説
答え: 2. DNS で名前を IP アドレスに変える
ブラウザは名前では通信できないので、まず DNS に住所を聞きます。名前が引けなければ、サーバーがどんなに元気でも始まりません。
ping は「届くか」と「往復時間」だけを確かめる
ping は、相手の住所に小さな信号を送って、返事が来るかと往復にかかった時間を確かめるコマンドです。使っているのは ICMP という約束事（RFC 792）の「Echo Request（届きますか）」と「Echo Reply（届きました）」です。
$ ping -c 3 203.0.113.10
64 bytes from 203.0.113.10: icmp_seq=1 ttl=54 time=12.3 ms
64 bytes from 203.0.113.10: icmp_seq=2 ttl=54 time=11.9 ms
64 bytes from 203.0.113.10: icmp_seq=3 ttl=54 time=12.1 ms
返事が来れば、「相手の住所まで経路があり、相手が生きている」ことと、「往復に約 12 ミリ秒かかる」ことが分かります。
ここで大事なのは、ping が確かめているのはインターネット層（住所まで届くか）だけということです。上の層、つまり「443 番の窓口が開いているか」「Web サーバーのプロセスが動いているか」は分かりません。
| ping の結果 | 分かること | 分からないこと |
|---|---|---|
| 返事が来る | 経路があり、相手が生きている。往復時間 | 窓口（ポート）が開いているか、アプリが動いているか |
| 返事が来ない | 「経路がない」か「相手が落ちている」か「途中で ICMP が止められている」のどれか | どれなのかは ping だけでは決まらない |
「ping が通らない＝壊れている」ではありません。多くのサーバーやファイアウォール（AWS のセキュリティグループも既定では）は ICMP を止めているので、ping が返らないのに Web は普通に見られることは日常的にあります。逆に、ping が通るのに Web が見られないなら、問題は上の層（窓口かアプリ）にあると絞れます。
WHY PING FAILSping が返らないのに Web は見られる
止められているのは ping の約束事（ICMP）だけ
途中のファイアウォール（セキュリティグループ）
- ICMPping の信号 返らない既定では止められている
- 443HTTPS 見られる許可してある
「つながらない」は、名前 → 経路 → 通過 → 窓口の順に切り分ける
4段階の流れを下から順に確かめるのが、切り分けの基本です。
TROUBLESHOOTING ORDER切り分けの順番
名前 → 経路 → 通過 → 窓口の順に、下から確かめる
-
1.名前が引けるか
dig / nslookup。IP アドレスが返らなければ DNS の問題
-
2.経路があるか
ping / traceroute。返事が無ければ経路の問題。ただし ICMP が止められている可能性も
-
3.通過できるか
ファイアウォールの設定。AWS ならセキュリティグループとネットワーク ACL
-
4.窓口が開いているか
nc -zv / curl -v。拒否されるなら、待ち受けるプロセスが無い
切り分けの順番と、使う道具
- 名前が引けるか —
dig/nslookup。IP アドレスが返ってこなければ DNS の問題（設定・TTL・レコードの書き間違い） - 経路があるか —
ping/traceroute。返事が無いか、途中で止まるなら経路の問題（ルーティング・ゲートウェイ）。ただし ICMP が止められている可能性も考える - 通過できるか — ファイアウォールの設定を見る。AWS ならセキュリティグループとネットワーク ACL
- 窓口が開いているか —
nc -zv 203.0.113.10 443やcurl -v https://example.com/。接続が拒否されるなら、サーバー側でその窓口を待ち受けるプロセスが無いか、別のポートで動いている
traceroute（Windows では tracert）は、ping の応用です。パケットの寿命（TTL）を1、2、3と増やしながら送り、途中のルーターに「寿命が切れた」と返事をさせて、経路上の機器を順に表示します。どこで返事が途切れるかで、経路のどの区間に問題があるかが分かります。
curl -v は、DNS・TCP・TLS・HTTP の各段階を順に表示してくれるので、1本で「どこで止まったか」が見えます。未経験のうちは、ping と curl -v の2つを手元で打てるようになれば十分です。
CHECK 2ここまでの確認
ping の返事が来なかった。確実に言えることはどれ?
答えと解説
答え: 3. 経路が無いか、相手が落ちているか、途中で ICMP が止められているかのどれか
ping が確かめるのは「住所まで届くか」だけで、返事が無い理由は3つあります。多くのファイアウォールは ICMP だけを止めるので、ping が返らなくても Web は普通に見られます。
AWS でも順番は同じ
AWS の VPC で EC2 に「つながらない」ときも、確かめることは同じです。名前が付け替わっているだけです。
SAME ON AWSAWS でも順番は同じ
一般のネットワークの言葉が、AWS の名前に置き換わるだけ
一般のネットワーク
AWS での名前
一般のネットワーク: DNS サーバー
AWS での名前: Route 53、VPC の DNS
一般のネットワーク: ルーター、デフォルトゲートウェイ
AWS での名前: ルートテーブル、インターネットゲートウェイ、NAT ゲートウェイ
一般のネットワーク: ファイアウォール
AWS での名前: セキュリティグループ、ネットワーク ACL
一般のネットワーク: サーバーのプロセス
AWS での名前: EC2 の中のプロセス（ss -tlnp）
| 段階 | 一般のネットワーク | AWS での名前 |
|---|---|---|
| 名前 | DNS サーバー | Route 53、VPC の DNS |
| 経路 | ルーター、デフォルトゲートウェイ | ルートテーブル、インターネットゲートウェイ、NAT ゲートウェイ |
| 通過 | ファイアウォール | セキュリティグループ（インスタンス単位）、ネットワーク ACL（サブネット単位） |
| 窓口 | サーバーのプロセス | EC2 の中で動くプロセス（ss -tlnp で確認） |
この対応表は、VPC とは何かで1つずつ扱います。先に「一般のネットワークでどう切り分けるか」を持っておくと、AWS の設定画面の項目が「どの段階の話か」で読めるようになります。
CHECK 3ここまでの確認
「ping は通るのに Web が見られない」。次に確かめるのはどこ?
答えと解説
答え: 3. 通過（ファイアウォール）と窓口（プロセス）
ping が通っているので、名前と経路の段階は済んでいます。問題はその上、つまり門（セキュリティグループ）か窓口（443 番で待つプロセス）にあると絞れます。
まとめ
URL を打ってからページが出るまでは、DNS → IP → TCP → HTTP の4段階です。DNS は名前から住所を引く階層の電話帳で、引けなければ何も始まりません。ping は「住所まで届くか」と「往復時間」だけを確かめる道具で、窓口が開いているかは分かりませんし、返事が無くても壊れているとは限りません。「つながらない」は、名前 → 経路 → 通過 → 窓口の順に切り分け、AWS でも順番は同じです。次はAWS とは何かで、この土台の上に AWS の入口を置きます。
参照ソース
- RFC 1034 “Domain Names - Concepts and Facilities” — DNS の階層構造（ルート・TLD・権威サーバー）と、リゾルバが順にたどる仕組み、TTL によるキャッシュの根拠（1987年）
- RFC 792 “Internet Control Message Protocol” — ping が使う Echo Request / Echo Reply の仕様の根拠（1981年）
- RFC 9293 “Transmission Control Protocol (TCP)” — 3ウェイハンドシェイクによる接続確立の根拠（2022年）
- Amazon EC2 インスタンスへの接続のトラブルシューティング（AWS EC2 ユーザーガイド） — AWS で「つながらない」ときに、セキュリティグループ・ネットワーク ACL・ルートテーブルを順に確かめる手順の根拠。2026年9月時点の記載
