ネットワークの切り分け8選｜pingは通るのに繋がらない

ネットワークって、繋がっているときは誰も見ないんですよね。

でも切り分けが必要になった瞬間、知っている人と知らない人で、解決までの時間が何時間も変わります。今回は、「pingは通るのに、繋がらない」のような謎の正体から、原因調査が一段速くなるものを8つ集めました。1つでも知らなかったら儲けものです。

① 自分を指すアドレスは、1つではありません

localhost といえば 127.0.0.1。そう覚えていますよね。

実は、127で始まるアドレスは、まるごと全部が自分なんです。

ping 127.0.0.1     → 自分に返ってくる
ping 127.1.2.3     → これも自分に返ってくる

127.0.0.0/8という広大な範囲が、丸ごとループバック用に予約されています。1600万個以上のアドレスが、全部「自分」なんですよね。

ちなみに ping 127.1 のような省略形も、多くの環境で 127.0.0.1 として解釈されます。知っていると、手打ちが少しだけ速くなる小ネタです。

② pingが通っても、繋がるとは限りません

「pingは通るので、ネットワークは大丈夫です」——ここ、切り分けの落とし穴です。

pingが確認しているのは、IPレベルで相手に届くかどうかだけ。アプリが使うポート（80番や443番）が開いているかは、まったく別の話なんですよね。

しかも逆もあります。セキュリティ設定でpingだけ拒否しているサーバーは珍しくないので、「pingが通らない＝落ちている」とも限りません。だから確認したいのはポートの疎通です。

curl -v telnet://example.com:443

「どの層まで届いているか」で切り分ける。これがネットワーク調査の基本姿勢です。

③ 「大きいファイルだけ送れない」現象があります

小さいデータは通るのに、大きいデータになると固まる。この不思議な症状には、PMTUブラックホールという名前があります。

1回で運べるデータの大きさには上限（MTU）があって、超えると分割されます。ところが分割の調整に使う通知が、途中の機器で遮断されていると、送信側が「大きいまま送り続けて、届かない」状態に陥るんですよね。VPNやトンネルを挟むと発生しやすくなります。

「サイズによって成否が変わる」なら、まずここを疑う。知らないと、まず原因にたどり着けない現象です。

④ DNSの切り替えは、TTL通りには進みません

「TTLを短くしたので、5分で切り替わります」——半分は正しいんです。

TTLは「この情報を何秒キャッシュしていいか」の目安ですが、間にいる機器やアプリが、独自の判断で保持し続けることがあるんですよね。

• 経路上のDNSサーバーが、独自のルールでキャッシュする
• OSやブラウザにも、それぞれのキャッシュがある
• アプリが、起動時に引いた結果を持ち続ける

とくに最後がやっかいで、Javaなど一部の実行環境にはIPを長時間（設定によっては永続的に）キャッシュする仕組みがあります。

切り替え作業のとき、「反映されない」の原因は自分たちの中にあるかもしれない、という話です。

⑤ 世界の通信は、海底ケーブルを通っています

国際通信は衛星経由——というイメージ、実は現在は違います。

大陸間の通信の99%以上が、海底ケーブルを通っています。太さは庭のホースほど。それが海底に張り巡らされているんですよね。

だから物理的な事故が、そのままインターネットの障害になります。船の錨、地震、そしてサメに噛まれるという報告まで実在します。

そして距離は、そのまま遅延になります。光の速度は有限なので、日本〜アメリカ間は往復で100ミリ秒前後かかり、物理的に大きくは縮められません。どんなにサーバーを速くしても、ここは変わらないんです。

CDNが世界中にサーバーを置く理由は、この物理法則から逃げられないからなんです。

⑥ IPアドレスは、とっくに枯渇しています

「IPv4アドレスが足りなくなる」——将来の話ではなく、すでに配布が終わっています。では、なぜ今も普通に使えているのか。

答えは、1つのグローバルIPを大勢で共有しているからです。家庭でも会社でも、内側のプライベートアドレスを、出口で1つの外向きアドレスに変換して通信しています（NAT）。

そのおかげで延命できていますが、副作用もあります。外から個々の端末を直接指定できないので、P2P通信やサーバー公開が難しくなるんですよね。

IPv6への移行がずっと言われ続けているのは、この根本的な窮屈さがあるからなんです。

⑦ 「接続が遅い」の正体は、速度ではないことがあります

回線速度を上げても、体感が変わらない。よくある話です。ネットワークの性能には、実は2つの別々の指標があります。

• 帯域幅（一度に運べる量）
• 遅延（1往復にかかる時間）

動画の視聴は帯域幅が効きますが、Webページの表示やAPI呼び出しは遅延の方が効くんですよね。細かいやり取りを何往復もするので、1往復の時間が全体を支配します。

「太い道路（帯域）を作っても、信号待ち（遅延）が多ければ到着は遅い」というイメージです。

遅いときは、速度ではなく往復回数を疑う。設計を変える発想が生まれるポイントです。

⑧ 通信の暗号化は、始まる前に相手を名乗っています

HTTPSなら通信の中身は暗号化されます。でも、ひとつだけ例外があります。

接続先のドメイン名だけは、暗号化の前に平文で流れているんです（SNIと呼ばれる仕組みです）。1つのサーバーに複数サイトが載っているので、「どのサイト宛てか」を先に伝えないと、正しい証明書を返せないんですよね。

つまり経路上の誰かからは、「何を見たかは分からないが、どこを見たかは分かる」状態です。

これを隠す仕組み（ECH）の普及がいま進んでいますが、「HTTPSだから全部隠れている」わけではない、というのは知っておきたいところです。

番外編：手元で確かめられる小ネタ

通信の経路を、目で見る

traceroute example.com

自分のパソコンから相手のサーバーまで、何台の機器を経由したかが一覧で出ます。海外のサーバーを指定すると、遅延がどこで跳ね上がるかが見えて面白いですよ。Windowsなら tracert です。

ポートが開いているかだけ確かめる

nc -zv example.com 443

②の切り分けが、この1行でできます。

DNSを引き直す

nslookup example.com 8.8.8.8

DNSサーバーを指定して引けるので、④の「どこのキャッシュが残っているか」を切り分けられます。

RJCでも、ネットワークと向き合っています

RJCが携わる保険、金融、決済、交通のシステムは、外部との通信が止まった瞬間に業務が止まる世界です。

だから障害対応では、「どの層で切れているか」を素早く切り分ける力が問われるんですよね。

こういう知識を、Techチームで共有しながら開発しています。切り分けができる人は、どの現場でも重宝されるんです。

よくいただくご質問

Q. まずどれから押さえるべきですか？
A. ②のping神話かなと思います。明日の障害対応から、切り分けの精度が上がります。

Q. ネットワークは、どう勉強すればいいですか？
A. 手を動かすのが最短です。今日の番外編のコマンドを、自宅のPCから叩いてみるだけでも景色が変わります。

Q. インフラ担当でなくても、必要な知識ですか？
A. 必要だと思います。アプリ側の障害だと思っていたものが、実はネットワーク起因ということが本当に多いんですよね。

Q. 未経験からでも、分かるようになりますか？
A. なります。ネットワークは目に見えない分だけ怖く感じますが、コマンドで観察できるようになると一気に具体的になります。

「繋がらない」を、層で分けて考える

今日の8つに共通していたのは、これでした。

繋がらないという1つの症状の裏に、IPの層、ポートの層、名前解決の層、経路の層と、いくつもの別々の話が隠れています。

「繋がらない」で止まらず、どこまでは届いているのかを確かめられる人が、いちばん早く原因にたどり着くんですよね。

みなさんがネットワークで踏んだ「ほぉー」、よかったら教えてください。