ping で接続確認

相手が落ちているのか、自分が出られていないのか

サーバーに接続できないとき、まず知りたいのは「そもそも相手まで届いているか」です。ここが分からないまま、アプリのログを読んだり設定を書き換えたりしても空振りに終わります。

ping は小さなパケットを 1 つ投げて、返事が返ってくるまでの時間を測るコマンドです。返事があれば、名前解決も経路も生きています。返事が無ければ、そこから先を疑う意味はありません。

ping -c 3 example.com
# 64 bytes from 203.0.113.10: icmp_seq=1 ttl=56 time=15.2 ms
# 64 bytes from 203.0.113.10: icmp_seq=2 ttl=56 time=15.3 ms
# 3 packets transmitted, 3 received, 0% packet loss

-c 3 は 3 回だけ送って止まる指定です。付けないと止めるまで送り続けます。time= が往復にかかった時間、packet loss が届かなかった割合です。

回線を太くしても縮まらない時間がある

往復時間の内訳は、光が距離を進む分と、データを送り出す分の足し算です。後者は回線を太くすれば減りますが、前者は距離で決まるので契約プランを上げても 1 ミリ秒も縮みません。日本から地球の裏側までは往復でおよそ 200 ミリ秒かかり、これはどんな回線でも同じです。

配信サービスや API が利用者の近くにサーバーを置くのは、この距離の分を短くするためです。往復時間が大きいときは、回線の細さより先に相手との距離を疑ってください。

返事が無い = 落ちている、ではない

ここが ping の一番の落とし穴です。多くの本番環境は、攻撃の的になるのを避けるために ping の返事をわざと止めています。HTTP は普通に通るのに ping だけ返らないという状況は、障害ではなくむしろ正常な設定です。

クラウドの実行環境でも、パケットを直接組み立てる権限が無いために次のように弾かれます。コマンドが壊れているわけではありません。

ping example.com
# ping: socket: Operation not permitted

その場合は、狙ったポートに TCP で挨拶できるかを見ます。

nc -vz example.com 443
# Connection to example.com 443 port [tcp/https] succeeded!

もうひとつ覚えておくと得をするのが、名前と IP の 2 段構えです。ping example.com は失敗するのに IP を直接書けば通る場合、壊れているのは経路ではなく名前解決です。両方失敗するなら経路の問題です。この 2 回打つだけで、疑う場所が半分に減ります。