「サーバーにつながらない」と連絡を受けて、どこから確かめようかとターミナルの画面を落ち着いて見ながら切り分けを始めた一人運用の保守担当者
障害対応・運用監視約13分

疎通しないときの切り分け手順｜ping・traceroute・digの基本

「さっきまで見られてたのに、急につながらなくなった」「メンテもしてないのに、サイトが開かないって連絡が来た」——そんな一言で呼ばれて、慌ててサーバーにログインしようとする。でも、そのログインすら通らないと、頭が真っ白になりますよね。

そういうとき、つい「サーバーが落ちたのかも」と最悪を想像して、あちこち一気に確認したくなります。でも「つながらない」の原因は、サーバー本体とは限りません。名前解決（ドメイン名をIPアドレスに変換する仕組み）がこけているのか、途中の経路で止まっているのか、そもそも相手の回線の問題なのか——場所によって、次にやることはまったく変わります。

この記事では、「つながらない」を手元（自分）に近い側から、相手のサーバーへと順番にたどっていく切り分けを、ping・traceroute・dig という3つの基本コマンドを使って一緒に整理します。全部を覚えなくて大丈夫です。まずは「どこで止まっているのか」を分けるところから、落ち着いて見ていきましょう。

結論：「つながらない」と言われたら、①名前解決を確かめる（dig でドメインがIPに引けているか）②相手まで届くかを確かめる（ping でIP宛に応答が返るか）③どこで止まっているかを見る（traceroute で経路の途中を確認）④サービスの口（ポート）が開いているかを見る——の順で、手元に近い側から一方向に進めます。まずは「名前で引けないのか、IPでも届かないのか」を分けるところから。

コマンドは Linux／一般的な環境を前提にしています。OSやツールの版、ネットワーク機器の設定（ICMPを止めている等）で挙動が変わります。ここを出発点に、本番へ反映する前に自分の環境と公式情報で確認してください。

まず「どこで止まっているか」を分ける

つながらないときに、名前解決・到達性・経路・ポートの順で手元に近い側から相手のサーバーへ切り分ける流れを示した図
「名前解決 → 到達性 → 経路 → ポート」の順で、手元に近い側から相手へたどる

いきなり「サーバーが生きているか」を見にいく前に、一段引いて「どこで止まっているのか」を分けます。ここを飛ばすと、「サーバーが落ちたと思って大騒ぎしたら、実はDNSの設定変更が原因だった」といった遠回りをしがちだからです。

順番の考え方はシンプルです。手元（自分の端末）にいちばん近いところから、相手のサーバーへ向かって、一方向に確かめていく。上流が白（問題なし）だと分かったら、その先へ進む。これだけです。

まずは「名前で引けないのか、IPでも届かないのか」の一本目の分かれ道を決めるだけで、見るべき場所がぐっと狭まります。

① 名前解決を確かめる（dig）

「つながらない」で意外と多いのが、サーバーは元気なのに名前解決だけがこけているケースです。ドメインの有効期限切れ、DNSレコードの設定変更、参照しているDNSサーバーの不調——原因はサーバー本体の外にあります。

dig（ダグ）は、ドメイン名からIPアドレスを引く様子を確認するコマンドです。

dig example.com

見るのは、出力の中の ANSWER SECTION です。ここに A（IPv4アドレス）や AAAA（IPv6アドレス）が返ってきていれば、名前解決はできています。

;; ANSWER SECTION:
example.com.   300   IN   A   93.184.216.34

逆に、ANSWER SECTION が空だったり、status: NXDOMAIN（そんな名前は存在しない）と出ていたら、名前解決の側に問題があります。ここが原因なら、ping や traceroute をいくら叩いても直りません。DNSレコード・ドメインの有効期限・参照先DNSのほうへ調べる先を切り替えます。

自分の端末の設定を疑うなら、参照先を変えて引いてみる

自分のPCやサーバーが見ているDNSがおかしいのか、それともドメインの設定そのものがおかしいのかを分けたいときは、参照するDNSサーバーを指定して引き比べます。

# 公開DNS（例）を指定して引いてみる
dig example.com @8.8.8.8

自分の普段の環境では引けないのに、別のDNS経由なら引ける——なら、原因は「自分が参照しているDNS側」に絞れます。ここまで分かると、相手を責めずに、自分の設定から確認できます。

② 相手まで届くかを確かめる（ping）

名前解決ができている（またはIPアドレスが分かっている）なら、次はそのIP宛にパケットが届いて応答が返るかを見ます。使うのは、いちばん基本の ping（ピング）です。

ping example.com

応答が返ると、こんな行が続きます。

64 bytes from 93.184.216.34: icmp_seq=1 ttl=56 time=12.3 ms

ここで見るのは、次の2つです。

ping が通らない＝サーバーが落ちている、とは限らない

ここは誤解しやすいところなので、一拍おきます。ping は ICMP という種類の通信を使いますが、セキュリティ上の理由で ICMP をわざと止めているサーバーやネットワークは珍しくありません。その場合、サーバーは元気に動いていても ping には応答しません。

だから、ping が通らなくても「落ちた」と即断しないこと。Webサーバーなら、後述のポート確認（②の次）で「80/443番が反応するか」を見るほうが確実なこともあります。ping は「通れば到達性あり」と言える便利な道具ですが、「通らない＝死亡」ではない、と覚えておくと落ち着けます。

③ どこで止まっているかを見る（traceroute）

ping で応答が返らない、あるいは時々しか返らない。そんなときに、手元から相手まで、どこまで行けて、どこで止まっているかを見るのが traceroute（トレースルート）です。

traceroute example.com

出力は、経由するネットワーク機器（ルーター）が1行ずつ、手元に近い順に並びます。

 1  192.168.1.1        1.2 ms
 2  10.0.0.1           5.4 ms
 3  * * *
 4  * * *

見るのは、**どこまで応答があって、どこから *（応答なし）になるか**です。

ただし traceroute も、途中の機器が応答を返さない設定だと * になることがあり、** * イコール障害とは限りません**。「どのあたりの層で変化が起きているか」を大づかみにするための道具、と捉えると深追いせずに済みます。分からない項目に粘りすぎず、「手元側か・相手側か・途中か」の当たりがつけば十分です。

④ ホストは生きているのに「そのサービスだけ」つながらないとき

名前解決から経路まで順番にたどって「つながらない」の原因の場所を突き止め、ほっと一息ついている保守運用の担当者

ping は通る（ホストは生きている）、経路も最後まで届いている。なのに「Webサイトが開かない」「DBに接続できない」。こういうときは、ホストではなくサービスの口（ポート）を見ます。

Webなら80番・443番、といったように、サービスごとに使うポートが決まっています。そのポートが開いているか、反応するかを確かめると、「ホストは生きているが、Webのプロセスだけ落ちている／ファイアウォールで塞がれている」といった一段細かい切り分けができます。ポートの確認には curl（Webの応答を直接見る）や、nc・telnet でポートに接続してみる、といった方法があります。

ここまで来れば、「つながらない」は「名前は引ける・ホストには届く・でも443番だけ反応しない」というように、具体的な場所まで絞れています。あとは、そのサービス（Webサーバーのプロセス、ファイアウォール設定）を見にいけば大丈夫です。

具体例：3つの「つながらない」のたどり方

順番に当てはめると、こんなふうにたどれます。

大事なのは、手元に近い側（名前解決）から順番に確かめることです。入口を決めてから進めば、どこを見ればいいかは自然と狭まります。

影響：見る順番が決まっていると、何が変わるか

逆に、順番を決めずに毎回勘で探すと、同じ「つながらない」でも、対応する人や日によって時間が大きく変わってしまいます。ネットワークは目に見えない分、地図があるかどうかで落ち着きがまるで違います。

明日やること：正常なときの姿を1回見ておく

いきなり全部は要りません。明日できる、いちばん小さな一歩はこれです。

  1. いつも使っている自分のサーバーやサイトに対して、平常時に dig・ping・traceroute を一度ずつ叩いてみる。
  2. dig の ANSWER SECTION に何が返るか、ping の応答時間がだいたい何ミリ秒か、traceroute が何ホップで着くか——「ふつうの状態」を目に馴染ませておく。
  3. そのときの出力を、運用メモに1回貼っておく。障害時に「今と平常時で何が違うか」を比べる基準になる。
  4. 余力があれば、ping が ICMP を止められていて通らないホストがないか（＝ポート確認のほうが確実な相手か）も、平常時に確かめておく。

平常時の姿を知っておくと、異常のときに「どこがいつもと違うか」で気づけます。これが、切り分けをいちばん速くしてくれます。

疎通確認・切り分けチェックリスト

最低ライン（優先順位つき：これだけで回る） 1) 名前解決：dig <ドメイン> で ANSWER SECTION にIPが返るかを見る 2) 到達性：ping <IP または ドメイン> で応答が返るか・パケットロスがないかを見る（ICMPを止めている相手もいる点に注意） 3) 経路：届かないときは traceroute でどこまで行けて・どこで止まるかを見る

余力が出たら拡張

免除条件（省略可）

確認項目

全部に○が付かなくても大丈夫です。上の3つ（名前解決・到達性・経路）が押さえられていれば、何もないときよりずっと落ち着いてたどれます。

よければ、こちらも

疎通の切り分けは、障害対応全体の一部です。鳴った瞬間の段取りや、重さの切り分け、連絡の型もあわせて1枚にしておくと、当日とても楽になります。

「つながらない」は、目に見えない分いちばん心細い障害のひとつです。でも、手元に近い側から dig・ping・traceroute と順番にたどると決めておくだけで、あの真っ白になる時間は、ずいぶん短くなります。 今日は、いつものサーバーに平常時の3コマンドを一度叩いて、「ふつうの姿」を見ておくだけで十分です。それが、次に「つながらない」と言われたとき、あなたを迷子にさせない地図になります。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語