traceroute и tracert: как читать трассировку маршрута

traceroute показывает, через какие маршрутизаторы проходит пакет от вашего компьютера или сервера до целевого хоста. В Windows аналогичная команда называется tracert. Обе утилиты помогают понять, где именно возникает задержка, обрыв или странный маршрут: у вас в локальной сети, у провайдера, на магистрали, у CDN или рядом с сервером.

Трассировка полезна, когда сайт открывается медленно, часть пользователей жалуется на недоступность, ping нестабилен, а по логам приложения всё выглядит нормально. Она не заменяет мониторинг, логи и метрики, но быстро даёт сетевой контекст: есть ли путь до узла, где растёт задержка и какие промежуточные устройства отвечают по дороге.

Главная сложность — вывод traceroute часто читают слишком буквально. Звёздочки, большие задержки на одном хопе или «потери» в середине маршрута не всегда означают проблему. Ниже разберём, как работает трассировка маршрута, чем traceroute отличается от tracert и как по выводу команды делать аккуратные выводы.

Что показывает traceroute

traceroute строит примерную цепочку сетевых узлов между источником и назначением. Каждый узел в этой цепочке обычно называют хопом — от английского hop, «прыжок».

Если выполнить:

traceroute example.com

утилита покажет список промежуточных маршрутизаторов:

traceroute to example.com (93.184.216.34), 30 hops max
 1  192.168.1.1        1.124 ms  0.921 ms  0.887 ms
 2  10.10.0.1          4.812 ms  5.103 ms  4.764 ms
 3  203.0.113.17       9.322 ms  9.517 ms  9.284 ms
 4  198.51.100.42     28.804 ms 29.112 ms 28.675 ms
 5  93.184.216.34     31.216 ms 31.002 ms 30.944 ms

В реальности вывод часто длиннее, с доменными именами, звёздочками, разными задержками и несколькими IP-адресами на одной строке.

traceroute отвечает на несколько практических вопросов.

1) Есть ли маршрут до хоста — если трассировка доходит до целевого IP, базовый сетевой путь существует. Это не гарантирует, что сайт или API работают на уровне HTTP, но исключает часть проблем уровня маршрутизации.

2) Где начинает расти задержка — если RTT резко увеличился на одном хопе и остаётся высоким дальше, вероятно, задержка появляется примерно в этой части маршрута.

3) Где маршрут обрывается — если после определённого хопа идут только * * *, это может быть фильтрация ICMP/UDP-ответов, перегруженный узел или реальный разрыв. Вывод нужно сверять с доступностью целевого сервиса.

4) Через какие сети идёт трафик — reverse DNS-имена и публичные IP могут подсказать провайдера, точку обмена трафиком, CDN, регион или магистральную сеть.

При этом traceroute не показывает «полную карту интернета». Он видит только ответы на специальные диагностические пакеты. Реальный пользовательский трафик может идти чуть иначе, особенно при балансировке, ECMP, CDN и асимметричной маршрутизации.

Как работает traceroute: TTL, ICMP, UDP и TCP

В основе traceroute лежит поле TTL в IPv4 или Hop Limit в IPv6. Каждый маршрутизатор по пути уменьшает это значение на единицу. Когда значение становится нулём, маршрутизатор отбрасывает пакет и обычно отправляет обратно сообщение ICMP Time Exceeded.

traceroute использует это поведение так:

1) Отправляет пакет с TTL=1 — первый маршрутизатор уменьшает TTL до нуля, отбрасывает пакет и отвечает ICMP Time Exceeded. Так утилита узнаёт первый хоп.

2) Отправляет пакет с TTL=2 — первый маршрутизатор пропускает пакет дальше, второй отбрасывает и отвечает. Так находится второй хоп.

3) Повторяет до цели — TTL увеличивается, пока пакет не достигнет назначения или не будет превышен лимит хопов.

Обычно на каждый хоп отправляется несколько проб, поэтому в строке вывода вы видите три времени — RTT для трёх отдельных пакетов.

Различие между реализациями — в типе пакетов.

1) Linux и macOS traceroute по умолчанию — отправляет UDP-пакеты на высокие порты. Когда пакет доходит до цели, хост отвечает ICMP Port Unreachable, потому что порт закрыт. Это сигнал: маршрут завершён.

2) Windows tracert — использует ICMP Echo Request, то есть механизм, похожий на ping, но с увеличивающимся TTL.

3) ICMP-режим — в Linux можно запустить трассировку через ICMP:

traceroute -I example.com

4) TCP-режим — полезен, если UDP или ICMP фильтруются, а нужно проверить путь именно до веб-порта:

sudo traceroute -T -p 443 example.com

TCP-трассировка может лучше соответствовать реальному HTTPS-трафику, но тоже не является точной копией браузерного соединения. Для диагностики HTTP/HTTPS дополнительно используйте curl; подробные примеры есть в статье «Что такое curl и как им пользоваться».

Как запустить traceroute и tracert

В Linux утилита может быть не установлена по умолчанию. В Debian/Ubuntu:

sudo apt update
sudo apt install traceroute

В RHEL-подобных системах:

sudo dnf install traceroute

В macOS traceroute обычно уже есть. В Windows используется встроенная команда tracert из cmd или PowerShell.

Базовые команды:

traceroute example.com

tracert example.com

Полезные опции traceroute:

1) Не выполнять reverse DNS — ускоряет вывод и убирает задержки из-за DNS:

traceroute -n example.com

В Windows аналог:

tracert -d example.com

2) Ограничить максимальное число хопов — удобно, если маршрут длинный:

traceroute -m 15 example.com

В Windows:

tracert -h 15 example.com

3) Изменить число проб на хоп — по умолчанию часто 3:

traceroute -q 5 example.com

4) Изменить таймаут ожидания ответа:

traceroute -w 2 example.com

В Windows таймаут указывается в миллисекундах:

tracert -w 2000 example.com

5) Принудительно использовать IPv4 или IPv6:

traceroute -4 example.com
traceroute -6 example.com

tracert -4 example.com
tracert -6 example.com

Если проблема проявляется только у части пользователей, полезно сравнить трассировки с разных сетей: домашний интернет, мобильный оператор, сервер в другом регионе, VPN, внешняя точка мониторинга. Сервисы мониторинга доступности, включая Statuser, проверяют сайт с заданным интервалом и уведомляют о сбое — но для расследования маршрута всё равно нужны отдельные трассировки из проблемных локаций.

Как читать вывод трассировки

Разберём типичный вывод:

traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
 1  router.local (192.168.1.1)       1.112 ms  0.944 ms  0.901 ms
 2  10.20.0.1                        5.231 ms  5.487 ms  5.103 ms
 3  isp-gw.example.net (203.0.113.1) 8.941 ms  9.020 ms  8.873 ms
 4  * * *
 5  core.example.net (198.51.100.5)  29.442 ms 29.105 ms 28.990 ms
 6  93.184.216.34                   31.223 ms 31.018 ms 30.877 ms

Основные элементы вывода:

1) Номер хопа — первая колонка. Чем больше номер, тем дальше узел от источника. Но «дальше» — сетевое понятие, а не обязательно географическое.

2) Имя и IP-адрес — если включён reverse DNS, утилита пытается показать имя узла. По нему иногда можно понять город, провайдера или тип оборудования: msk, fra, core, border, ix, cdn.

3) Время ответа — значения в миллисекундах. Это не «задержка между хопами», а RTT от вашего хоста до этого маршрутизатора и обратно.

4) Звёздочки * — проба не получила ответа за таймаут. Маршрутизатор мог просто не отвечать на диагностические пакеты, продолжая нормально пересылать обычный трафик.

5) Несколько IP на одном хопе — признак балансировки. Разные пробы могут пройти через разные равнозначные маршруты.

Самое частое заблуждение: считать задержку на каждом хопе отдельным участком маршрута. Если на хопе 5 указано 30 ms, это не значит, что между хопом 4 и 5 добавилось ровно 30 мс. Это полное время туда-обратно до хопа 5.

Правильнее смотреть на динамику: где задержка резко выросла и сохраняется ли она на последующих хопах.

Типовые паттерны: где проблема на самом деле

Трассировку лучше читать не по одной строке, а по шаблонам.

1) Высокая задержка только на одном промежуточном хопе — обычно не проблема.

 5  198.51.100.10   180.2 ms  190.4 ms  175.8 ms
 6  198.51.100.20    32.1 ms   31.9 ms   32.4 ms
 7  203.0.113.50     33.0 ms   32.7 ms   33.1 ms

Если следующий хоп снова отвечает быстро, маршрутизатор на хопе 5, вероятно, низко приоритизирует ICMP-ответы — он пересылает трафик нормально, но сам отвечает медленно.

2) Задержка выросла и осталась высокой дальше — это уже полезный сигнал.

 3  10.0.0.1          5.2 ms    5.4 ms    5.1 ms
 4  203.0.113.1      80.3 ms   82.0 ms   79.8 ms
 5  198.51.100.5     83.1 ms   84.2 ms   82.7 ms
 6  93.184.216.34    85.0 ms   84.8 ms   85.3 ms

Задержка появляется примерно между хопами 3 и 4 либо на обратном пути от хопа 4. Точно указать направление по обычному traceroute нельзя, но место для дальнейшей проверки становится понятнее.

3) Потери на промежуточном хопе, но дальше всё нормально — чаще всего маршрутизатор просто ограничивает ответы на диагностические пакеты.

 4  198.51.100.1     *  25.1 ms  *
 5  198.51.100.2     26.0 ms 25.8 ms 25.9 ms
 6  93.184.216.34    27.1 ms 27.0 ms 27.2 ms

Если последующие хопы отвечают стабильно, пакеты через него проходят.

4) Звёздочки до конца маршрута — неоднозначная ситуация.

 8  198.51.100.10    45.1 ms 44.9 ms 45.0 ms
 9  * * *
10  * * *
11  * * *

Возможны варианты: фильтрация ICMP/UDP, недоступность целевой сети, firewall, отсутствие маршрута, блокировка на границе. Сверьте с ping, TCP-проверкой порта, curl и логами сервера.

5) Целевой сайт открывается, но трассировка не доходит до конца — нормальная ситуация для некоторых хостингов, CDN и firewall: они пропускают HTTPS, но блокируют ICMP или UDP-трассировку.

6) Повторяются одни и те же IP — возможна маршрутная петля.

 6  198.51.100.1
 7  198.51.100.2
 8  198.51.100.1
 9  198.51.100.2

Такое встречается при ошибках маршрутизации. Если маршрут действительно зациклен, целевой хост недоступен, а трассировка будет идти до максимального TTL.

7) Первые хопы уже медленные — смотрите локальную сеть, Wi‑Fi, роутер, VPN или провайдера доступа. Сравните с подключением по кабелю и с другой сети. Для базовой проверки задержки и потерь полезна отдельная статья «Команда ping: как пользоваться и читать вывод».

Traceroute, ping, mtr и другие инструменты

traceroute хорош как быстрый снимок маршрута. Но он показывает один момент времени и несколько проб на каждый хоп. Для плавающих проблем этого часто мало.

ping отвечает на более простой вопрос: есть ли ответ от узла и какая задержка до него. Он не показывает промежуточный путь, зато удобен для длительного наблюдения за одной точкой.

mtr и WinMTR объединяют идеи ping и traceroute: строят маршрут и продолжают отправлять пробы, показывая статистику по каждому хопу. Если проблема плавающая, лучше запускать mtr на несколько минут и смотреть, где появляются устойчивые потери или скачки задержки. Подробнее разбор вывода есть в статье «Как читать трассировку в mtr и WinMTR».

tcpdump нужен, когда нужно увидеть реальные пакеты: DNS-запросы, TCP SYN, TLS-рукопожатие, ответы сервера, ретрансляции. Если трассировка ничего подозрительного не показывает, но соединение всё равно не устанавливается, захват трафика часто даёт больше фактов. Практический вводный материал — «Что такое tcpdump и как анализировать сетевой трафик из терминала».

hping3 полезен для ручной проверки TCP/UDP/ICMP-пакетов с разными флагами и параметрами. Им можно проверить, доходит ли TCP SYN до нужного порта, как отвечает firewall, отличаются ли ответы на разные протоколы. Базовый обзор есть в статье «Что такое hping3 и зачем он нужен».

DNS тоже не стоит забывать. Если домен резолвится в разные IP у разных пользователей, трассировки будут вести к разным узлам. Перед анализом маршрута полезно проверить DNS-записи через dig; см. «Утилита dig: как проверить DNS-записи и отладить домен».

Практический сценарий диагностики

Допустим, пользователи жалуются, что сайт иногда не открывается или открывается медленно. Начинать только с traceroute не стоит. Лучше идти по шагам.

1) Проверьте симптом на уровне HTTP — откройте сайт из браузера, выполните curl -I https://example.com, посмотрите код ответа и время соединения. Если мониторинг доступности уже прислал алерт (например, от Statuser), зафиксируйте время сбоя и точку проверки.

2) Проверьте DNS — убедитесь, что домен резолвится в ожидаемые IP:

dig example.com A
dig example.com AAAA

Если у разных резолверов разные ответы, сравнивать трассировки нужно к конкретному IP, а не только к домену.

3) Запустите обычную трассировку:

traceroute -n example.com

На Windows:

tracert -d example.com

Опция без reverse DNS делает вывод чище и быстрее.

4) Запустите трассировку до конкретного IP — особенно если домен обслуживается CDN или балансировщиком:

traceroute -n 203.0.113.10

5) Сравните ICMP/UDP и TCP — если обычная трассировка обрывается, попробуйте TCP до порта сайта:

sudo traceroute -T -p 443 example.com

Если TCP-трассировка доходит, а UDP/ICMP нет, вероятна фильтрация диагностического трафика.

6) Снимите трассировки с нескольких сторон — с сервера, с домашней сети, из мобильного интернета, из региона пользователя. Проблема может быть только на одном операторе или направлении.

7) Сверьте с логами и метриками — если трассировка до сервера нормальная, а HTTP отвечает 502, 503 или 504, причина может быть в приложении, прокси, upstream-сервисе или базе. Для общего плана действий пригодится материал «Что делать, если упал сайт».

Главное — сохраняйте вывод команд вместе со временем, исходной сетью и целевым IP. Трассировка без контекста быстро теряет диагностическую ценность.

Ограничения traceroute

У traceroute много ограничений. Если их игнорировать, легко обвинить не тот узел.

1) Обратный маршрут может отличаться — RTT включает путь туда и обратно. Вы видите ответ от маршрутизатора, но не знаете, каким маршрутом этот ответ вернулся. Проблема может быть на обратном пути.

2) ICMP может ограничиваться — маршрутизаторы часто rate limit’ят ответы ICMP Time Exceeded, поэтому отдельный хоп может выглядеть «медленным» или «потерянным», хотя транзитный трафик проходит нормально.

3) Балансировка меняет картину — при ECMP разные пробы могут идти разными путями: в выводе появляются разные IP на одном хопе, скачки задержки и непоследовательные маршруты.

4) Firewall может пропускать сайт, но блокировать диагностику — HTTPS работает, а traceroute показывает * * *. Это не противоречие.

5) CDN скрывает реальную инфраструктуру — домен может вести к ближайшему edge-узлу, а не к origin-серверу. Трассировка до CDN показывает путь до точки CDN, но не путь от CDN до вашего origin.

6) NAT и приватные адреса запутывают вывод — адреса 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 могут встречаться внутри сети провайдера. Это не ошибка сама по себе.

7) География по имени хоста ненадёжна — fra, ams, msk в reverse DNS часто полезны, но не являются строгим доказательством физического расположения.

Поэтому вывод traceroute лучше рассматривать как улику, а не как приговор. Хорошая диагностика сочетает трассировку, ping, DNS-проверки, HTTP-проверки, логи, метрики и, при необходимости, захват пакетов.

FAQ

Чем отличается traceroute от tracert?
traceroute — команда в Linux/macOS, tracert — встроенный аналог в Windows. Главное практическое отличие: Windows обычно использует ICMP Echo, а Linux/macOS часто отправляют UDP-пакеты по умолчанию.

Звёздочки в traceroute означают потерю пакетов?
Не всегда. * * * означает, что утилита не получила диагностический ответ за таймаут. Маршрутизатор мог просто не отвечать на ICMP/UDP, но продолжать пересылать обычный трафик.

Почему сайт открывается, а traceroute не доходит до конца?
Целевой сервер, CDN или firewall могут пропускать TCP/443, но блокировать диагностические ответы. В таком случае попробуйте TCP-трассировку до 443 и проверьте сайт через curl.

Можно ли по traceroute точно понять, кто виноват в сбое?
Иногда — да, особенно при явной маршрутной петле или обрыве после сети провайдера. Но чаще traceroute только сужает область поиска. Для уверенного вывода нужны данные с разных точек и другие инструменты диагностики.