「サーバー繋がらない」を切り分ける3点セット
サービスがダウンしたとき、まず最初に確認するのが ping、続いて traceroute、そして両者の土台となる ICMP プロトコル。これらは L3 での「ネットワーク疎通の状態」を確認する基本ツールです。
この記事では、ICMP の正体と、ping / traceroute の仕組み、結果の読み方を初学者向けに整理します。
ICMP は「ネットワークの便り」
ICMP（Internet Control Message Protocol）は、IP の補助として動く制御・診断用のプロトコルです。データを運ぶ目的ではなく、「宛先に届かなかったよ」「TTL が切れたよ」のようなネットワーク状態の通知に使われます。
ICMP は IP の上で動きますが、TCP や UDP のようなポート番号は持ちません（IP プロトコル番号 1）。代わりに「Type」と「Code」というフィールドでメッセージの種類を識別します。
代表的な ICMPv4 のタイプ：
| Type | 名称 | 用途 |
|---|---|---|
| 0 | Echo Reply | ping の返事 |
| 3 | Destination Unreachable | 宛先不到達（ホストなし、ポート閉、FW拒否等） |
| 8 | Echo Request | ping の問い合わせ |
| 11 | Time Exceeded | TTL 切れ（traceroute が利用） |
| 12 | Parameter Problem | IP ヘッダー不正 |
ping: 一番シンプルな疎通確認
ping は Echo Request（Type 8）を送って、相手が Echo Reply（Type 0）を返すかを見るだけのツールです。返事が来れば「ネットワーク的には届いている」、返事がなければ「どこかで止まっている」と分かります。
$ ping example.com
PING example.com (93.184.215.14): 56 data bytes
64 bytes from 93.184.215.14: icmp_seq=0 ttl=56 time=12.345 ms
64 bytes from 93.184.215.14: icmp_seq=1 ttl=56 time=11.987 ms
64 bytes from 93.184.215.14: icmp_seq=2 ttl=56 time=12.012 ms
--- example.com ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.987/12.115/12.345/0.158 ms結果から読み取れること：
- time（往復時間, RTT）: 12ms ならネットワーク的に近い、200ms 超なら海外経由か無線が悪い
- ttl: 受信時の TTL から逆算してホップ数を推測（ttl=56 なら初期値64-56 = 8ホップ程度）
- packet loss: 0% が理想。数% でも長期通信では深刻な品質劣化
- stddev（ジッタ）: ばらつきが大きいと音声通話・ゲームで支障
ping が返ってこない = 落ちている、とは限らない
ping が返らないとき、即「サーバー死亡」と判断するのは早計です。次の可能性があります：
- ICMP がファイアウォールで遮断されている: AWS のセキュリティグループはデフォルトで ICMP を許可しない。クラウド上のサーバーは ping 不通でも HTTP は元気、というケース多数
- サーバー OS で ICMP 応答を無効化している（セキュリティポリシー）
- 経路上のルーターが ICMP を捨てている
本番のサーバー監視では、ping だけでなく curl https://example.com/healthz のような実際のサービス層での疎通を見るべきです。
traceroute: 経路を可視化する
traceroute はパケットがどんな経路でサーバーに届いているかを表示するツールです。「自宅 → ISP → 海底ケーブル → 米国 → サーバー」のような経路が hop ごとに見えます。
$ traceroute example.com
1 router.local (192.168.1.1) 1.234 ms
2 10.0.0.1 (10.0.0.1) 5.678 ms
3 isp-gateway-01.example-isp.jp 8.901 ms
4 jp-tokyo-edge.example-isp.jp 12.345 ms
5 * * *
6 us-la-edge.upstream-tier1.net 120.456 ms
7 edge.example.com (93.184.215.14) 122.789 ms仕組み: TTL を意図的に小さくする
traceroute の賢いところは、TTL（Time To Live）の仕組みを利用する点です。
- TTL=1 のパケットを送る → 最初のルーターで TTL=0 になり、Type 11（Time Exceeded）を返してくる
- TTL=2 → 2番目のルーターから返事
- TTL=3 → 3番目のルーター
- ...宛先に届くまで繰り返す
各 hop の応答元 IP を記録することで、経路全体が見えるという仕組みです。
結果の読み方
- * * *: そのルーターが ICMP を返さない設定。経路自体は通っている可能性が高い
- 急に時間が跳ねる hop: その間に長距離ホップ（海底ケーブル等）がある
- 途中で止まる: ルーティング切れ・FW 遮断・経路 BGP 障害の可能性
OS 別の細かい違い
- Linux / macOS の
traceroute: デフォルトで UDP を使い、宛先からの ICMP Port Unreachable で終端を検知 - Windows の
tracert: ICMP Echo Request を使う - mtr: traceroute + ping を継続実行する強化版。ロス率が見やすい
「Smurf 攻撃」と ICMP 制限
昔の DDoS 手法で、送信元を被害者に偽装した ICMP Echo Request をブロードキャストアドレスに送り、大量の Echo Reply を被害者に殺到させる「Smurf 攻撃」というものがありました。これに対抗するため、現代のルーターは ICMP Echo へのブロードキャスト応答を無効化しています。
サーバー側で ICMP を制限する場合も、「全部捨てる」ではなく Type 3（Destination Unreachable）と Type 11（Time Exceeded）は通すのが推奨です。これらを完全遮断すると Path MTU Discovery が動かなくなり、特定のパケットサイズで通信が詰まる「PMTU ブラックホール」現象を起こします。
覚えておきたいコマンド早見表
| 用途 | Linux / macOS | Windows |
|---|---|---|
| 疎通確認 | ping example.com | ping example.com |
| 経路調査 | traceroute example.com | tracert example.com |
| 継続的経路監視 | mtr example.com | pathping example.com |
| ポート疎通 | nc -zv example.com 443 | Test-NetConnection example.com -Port 443 |
おわりに
「ping が通らない」は便利な切り分け情報ですが、ICMP は途中で遮断されることが多いプロトコルなので、ping だけで判断しないのが現代的な作法です。実サービスのエンドポイントへの HTTP 確認や、明示的なポートチェック（nc / curl / Test-NetConnection）を組み合わせて、レイヤごとに切り分けていくのが正しいアプローチです。