TTL（Time To Live）について学習まとめ

Posted at 2026-09-19

ネットワーク分析やトラブルシューティングで頻繁に目にする「TTL（Time To Live）」。

「PINGを打ったときに出てくる ttl=128 や ttl=64 って何？」
「パケットキャプチャで TTL=1 だと何が起きるの？」

この記事では、インフラエンジニアやWebエンジニア向けに、TTL値の基本概念から、パケット分析で読み取れる情報、実際のトラブル事例まで分かりやすく解説します。

1. TTL（Time To Live）とは？

TTL（Time To Live） は、IPパケットのヘッダーに含まれる数値で、直訳すると「生存時間」を意味します。

ただし、「時間（秒）」ではなく、「パケットが通過できるルーターの最大数（ホップ数）」を表しています。

ネットワーク内でルーティング設定のミス（ルーティングループ）があると、パケットが宛先にたどり着けず、ルーター間を無限にぐるぐる回り続けてしまうことがあります。

これを放置すると、無駄なパケットで回線やルーターの帯域が圧迫されてしまいます。

そこで、TTLという「寿命」を持たせることで、以下の仕組みでパケットを自動廃棄します。

パケットキャプチャ（Wireshark）や PING の応答に含まれる TTL 値を見ることで、ネットワークに関するさまざまな情報を読み取ることができます。

送信元OSの「初期TTL値」から、手元に届いた「受信TTL値」を引くことで、通信経路で通過してきたルーターの台数が分かります。

$$\text{経由したルーター数} = \text{初期TTL値} - \text{受信TTL値}$$

例えば、相手が初期値 64 で送信し、手元に ttl=52 で届いた場合、途中で 12台のルーター（54 - 52 = 12）を経由してきたことが判明します。

主要なOSは、パケット送信時の初期TTL値としてデフォルトで決まった値を持っています。

初期TTL値	推測されるOS / 機器
64	Linux, macOS, Android, iOS
128	Windows
255	Cisco などのルーター / ネットワーク機器、一部のUNIX

PINGの応答で ttl=115 と表示された場合、初期値 128 の Windows 端末から 13ホップ離れた場所からの応答だと推測できます。

通信中に突然 TTL 値が変化した場合は、途中の経路（ルーティング）が切り替わったことを意味します。

また、TTLが想定より極端に早く減少している場合は、ルーティングループが発生して同じルーター群を周回している可能性があります。

インフラ運用でよくハマるポイントの1つに、「アプリケーション固有の TTL=1 設定」 が挙げられます。

Windows Server Failover Clustering（WSFC）では、ノード間の生存確認を行うハートビート通信（UDP 3343番ポート）のパケット初期TTL値が**既定で 1** に設定されています。

同一サブネット内（L2通信）: ルーターを跨がないため、TTL=1 のまま相手ノードに届き、正常に通信できます。
異なるサブネット間（NVAやルーター経由）: ノード間に NVA（Network Virtual Appliance）やルーターが存在する場合、ルーターを通過した瞬間に TTL が 0 になり、パケットが破棄されてしまいます。

この場合、Wireshark等のキャプチャには以下のように記録されます。

送信パケット: Protocol: UDP, Dst Port: 3343, Time to Live: 1
エラー返答: ICMP Type 11 (Time To Live Exceeded in Transit)
例：ttl値はこのinternet protocol version 4のところで見れます。

このような場合は、クラスタ設定や対象プロトコルの設定で「クロスサブネット通信時の TTL 値（または閾値）」を拡大する（例: TTLを255に変更する）といったチューニングが必要です。

ネットワークトラブルシューティングの際は、ぜひ IP ヘッダーの TTL 値にも注目してみてください。