tracert и traceroute: как проверить маршрут пакета и найти проблемный узел

tracert (в Windows) и traceroute (в Linux и macOS) — это утилиты трассировки маршрута: они показывают список промежуточных узлов (хопов), через которые проходит пакет от твоего компьютера до целевого сервера, и время отклика каждого из них. Инструмент помогает понять, на каком участке сети теряются пакеты или растет задержка.

Ниже разберем, как трассировка устроена (поле TTL и ответы ICMP), как ее запустить в Windows и Linux, как прочитать вывод по столбцам, чем отличаются реализации в разных ОС и как по выводу найти проблемный узел. Примеры вывода приведены в реальном формате утилит; блок разбора вывода прогнан в песочнице.

Как работает трассировка: TTL и ICMP

В заголовке каждого IP-пакета есть поле TTL (Time To Live) — счетчик оставшихся переходов. Каждый маршрутизатор на пути уменьшает TTL на единицу. Когда TTL доходит до нуля, узел отбрасывает пакет и отправляет отправителю служебное сообщение ICMP «Time Exceeded» (тип 11) со своим адресом.

Трассировка использует это поведение как трюк. Утилита отправляет к цели серию пакетов с нарастающим TTL: сначала TTL=1, потом 2, потом 3 и так далее.

• Пакет с TTL=1 «умрет» на первом маршрутизаторе — тот вернет Time Exceeded и раскроет свой адрес.
• Пакет с TTL=2 дойдет до второго узла — ответит уже он.
• Так, увеличивая TTL, утилита по очереди «опрашивает» каждый узел вплоть до цели.

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

Разные протоколы в разных ОС — не путать

Одинаковые с виду tracert и traceroute по умолчанию шлют пробы разными протоколами, и это объясняет, почему их вывод на одном маршруте может отличаться.

• Windows tracert по умолчанию шлет эхо-запросы ICMP (как ping). Цель отвечает ICMP Echo Reply.
• Linux traceroute по умолчанию шлет UDP-датаграммы на высокие порты (начиная с 33434). Цель, где такой порт закрыт, отвечает ICMP «Port Unreachable» — это и есть сигнал «дошли».
• macOS traceroute — та же BSD-реализация, тоже UDP по умолчанию.

Отличие важно на практике: некоторые узлы фильтруют один протокол и пропускают другой, поэтому один и тот же маршрут может выглядеть по-разному в Windows и Linux. В Linux при необходимости можно переключиться на ICMP-пробы (traceroute -I) или TCP (traceroute -T), чтобы вывод стал ближе к tracert или прошел через фаервол.

Как запустить трассировку

В Windows отдельная установка не нужна — утилита встроена:

1. Нажать Win+R, ввести cmd, нажать Enter — откроется командная строка.
2. Ввести команду вида tracert otus.ru (можно указать домен или IP).
3. Нажать Enter и дождаться, пока трассировка дойдет до цели или упрется в лимит переходов.

В Linux утилита обычно ставится отдельно. На Ubuntu или Debian:

sudo apt update
sudo apt install traceroute
traceroute otus.ru

В macOS traceroute встроен, устанавливать ничего не нужно — команда та же, что в Linux. Вместо доменного имени всюду можно подставить IP-адрес.

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

Вывод Windows tracert для команды tracert otus.ru выглядит так:

Трассировка маршрута к otus.ru [178.248.237.68]
с максимальным числом прыжков 30:

  1     1 ms     1 ms     1 ms  192.168.1.1
  2    12 ms    11 ms    12 ms  bras.provider.net [85.21.0.1]
  3     *        *        *     Превышен интервал ожидания для запроса.
  4    14 ms    15 ms    14 ms  m9-crs.msk.provider.net [85.21.10.4]
  5    19 ms    18 ms    20 ms  yandex-gw.msk [87.250.239.1]
  6    21 ms    20 ms    21 ms  178.248.237.68

Трассировка завершена.

Столбцы читаются так: номер узла (хопа), затем три замера времени отклика в миллисекундах (три пробных пакета), затем имя узла и его IP. Строка со звездочками означает, что на этот шаг ответ не пришел в отведенное время (тайм-аут).

Тот же маршрут через Linux traceroute otus.ru выглядит немного иначе:

traceroute to otus.ru (178.248.237.68), 30 hops max, 60 byte packets
 1  _gateway (192.168.1.1)  0.512 ms  0.481 ms  0.470 ms
 2  85.21.0.1 (85.21.0.1)  11.8 ms  11.9 ms  12.1 ms
 3  * * *
 4  85.21.10.4 (85.21.10.4)  14.2 ms  14.0 ms  14.3 ms
 5  87.250.239.1 (87.250.239.1)  18.7 ms  18.9 ms  19.1 ms
 6  178.248.237.68 (178.248.237.68)  20.6 ms  20.4 ms  20.7 ms

Логика та же (номер, три замера, узел), но формат записи и единицы времени отображаются подробнее, а имена по умолчанию могут не разрешаться в зависимости от настроек DNS. Ключевые различия удобно держать в одной таблице.

Полезные ключи

Ключи меняют поведение утилиты. Часть их совпадает по смыслу, но пишется по-разному в двух ОС.

• -d (Windows) / -n (Linux) — не разрешать IP в доменные имена. Вывод появляется быстрее, потому что утилита не ждет ответов DNS.
• -h N (Windows) / -m N (Linux) — максимальное число переходов. По умолчанию 30; если цель дальше, трассировка оборвется на лимите, и его стоит поднять.
• -w N — тайм-аут ожидания ответа. В Windows значение задается в миллисекундах, в Linux -w принимает секунды — единицы разные, это частый источник путаницы.
• -4 / -6 — принудительно IPv4 или IPv6 (поддерживается в обеих ОС).
• -I и -T (Linux) — слать ICMP- или TCP-пробы вместо UDP; помогает пройти узлы, которые режут UDP.

Справку по всем ключам выводят tracert /? в Windows и man traceroute в Linux.

Как найти проблемный узел

Трассировку запускают не ради списка адресов, а чтобы локализовать неполадку. Читать вывод стоит по симптомам.

• Звездочки на одном промежуточном узле, дальше маршрут идет. Это норма, а не поломка: узел настроен не отвечать на служебные пакеты или ограничивает их частоту (rate limiting). На доставку данных это не влияет.
• Резкий скачок задержки на узле и он держится до конца. Вероятное «узкое место» — перегруженный или далекий по географии участок. Смотреть надо на узел, где задержка выросла и осталась высокой, а не на разовый всплеск.
• Трассировка обрывается звездочками до самой цели. Либо целевой сервер или его фаервол не отвечают на пробы (сайт при этом может работать), либо проблема реально на последнем участке. Стоит сменить протокол (traceroute -I или -T) и повторить трассировку.
• Задержка растет плавно с каждым хопом. Это ожидаемо: чем дальше узел географически, тем больше время отклика. Само по себе это не проблема.

Важная оговорка: трассировка показывает путь «туда», а обратный маршрут может идти иначе, поэтому по одному замеру нельзя однозначно обвинить конкретного провайдера. Для выводов лучше сравнить несколько прогонов в разное время.

Если вывод сохранен в файл, простой скрипт быстро подсветит самый медленный узел по средней задержке:

data=$(cat <<'EOF'
 1  _gateway (192.168.1.1)  0.512 ms  0.481 ms  0.470 ms
 2  85.21.0.1 (85.21.0.1)  11.8 ms  11.9 ms  12.1 ms
 3  * * *
 4  85.21.10.4 (85.21.10.4)  14.2 ms  14.0 ms  14.3 ms
 5  87.250.239.1 (87.250.239.1)  41.7 ms  40.9 ms  42.3 ms
EOF
)
echo "$data" | awk '
{
  sum=0; n=0
  for (i=1;i<=NF;i++) if ($i=="ms") { sum+=$(i-1); n++ }
  if (n>0) {
    avg=sum/n
    printf "хоп %s: средняя %.1f ms\n", $1, avg
    if (avg>max) { max=avg; worst=$1 }
  } else {
    printf "хоп %s: нет ответа (*)\n", $1
  }
}
END { printf "\nсамый медленный узел: хоп %s (%.1f ms)\n", worst, max }
'

Вывод скрипта:

хоп 1: средняя 0.5 ms
хоп 2: средняя 11.9 ms
хоп 3: нет ответа (*)
хоп 4: средняя 14.2 ms
хоп 5: средняя 41.6 ms

самый медленный узел: хоп 5 (41.6 ms)

Скрипт суммирует все замеры в строке, делит на их число и запоминает узел с максимальной средней задержкой. Для одного прогона это перебор, но при десятках сохраненных трассировок такой фильтр экономит время.

Расширенная диагностика: непрерывный мониторинг

Однократная трассировка — это моментальный снимок. Если сбой плавающий (появляется и исчезает), удобнее инструменты, которые опрашивают маршрут непрерывно и считают процент потерь на каждом узле.

• pathping — встроена в Windows, объединяет tracert и ping: сначала строит маршрут, потом какое-то время шлет пакеты и показывает потери по каждому узлу. Запуск: pathping otus.ru. Сбор статистики занимает несколько минут.
• mtr — стандартный инструмент в Linux и macOS, показывает маршрут и потери в реальном времени, обновляя таблицу. Ставится через пакетный менеджер (sudo apt install mtr на Ubuntu). Запуск: mtr otus.ru.
• WinMTR — порт mtr под Windows с графическим окном. Проект давно не обновлялся, но на актуальных Windows обычно работает; для встроенного решения проще начать с pathping.

Непрерывный мониторинг ценен именно на нестабильных проблемах: он копит статистику и показывает, на каком узле пакеты теряются регулярно, а не в один момент.

Выводы

• tracert (Windows) и traceroute (Linux, macOS) показывают путь пакета до сервера по узлам и время отклика каждого; одна утилита под две ОС различается протоколом проб по умолчанию.
• Механизм один: пакеты с нарастающим TTL «умирают» по очереди на каждом узле, и тот раскрывает свой адрес сообщением ICMP Time Exceeded.
• Вывод читается по столбцам: номер узла, три замера времени, адрес; звездочки на промежуточном узле часто норма (фильтр или rate limiting), а не поломка.
• Проблемный участок ищут по устойчивому скачку задержки или потерям, а не по разовому всплеску; путь «туда» и «обратно» может различаться.
• Для плавающих сбоев берут непрерывный мониторинг: pathping в Windows, mtr в Linux и macOS.

Где применяется и что учить дальше

Трассировка — базовый навык сетевой диагностики. С нее начинают разбор жалоб «сайт медленно грузится» или «сервис недоступен»: tracert и traceroute показывают, лежит ли проблема в домашней сети, у провайдера или на стороне сервиса. Тот же инструмент помогает при настройке VPN, маршрутизации и разборе задержек в играх и видеосвязи.

Смежные темы: Первое знакомство с Ubuntu.

FAQ

Почему tracert и traceroute на одном маршруте дают разный результат? По умолчанию они шлют пробы разными протоколами: Windows — ICMP, Linux и macOS — UDP. Узлы могут по-разному фильтровать эти протоколы, поэтому набор ответивших хопов и задержки иногда отличаются.

Можно ли по трассировке узнать точное местоположение сервера? Нет. Утилита показывает IP-адреса и иногда имена узлов, но геолокация по IP приблизительна, а имена отражают инфраструктуру провайдера, а не физический адрес. Для позиционирования это ненадежный источник.

Влияет ли VPN на вывод tracert? Да. При активном VPN трафик сначала идет в туннель до VPN-сервера, поэтому первые узлы маршрута будут относиться к сети провайдера VPN, а не к вашему обычному пути до сайта.