Сайт не открывается, игра лагает, до рабочего сервера не достучаться - и непонятно, где именно проблема: у вас дома, у провайдера или на стороне сервера. Команда tracert показывает путь, по которому пакеты идут до нужного узла, и время ответа каждого промежуточного маршрутизатора. По этому списку обычно видно, на каком участке связь обрывается или начинает тормозить.

Как работает tracert

Каждый маршрутизатор на пути получает свой номер прыжка и отвечает компьютеру

У каждого IP-пакета есть поле TTL - число переходов, которое он может пройти. Каждый маршрутизатор уменьшает TTL на единицу, а когда значение доходит до нуля, выбрасывает пакет и отправляет отправителю ICMP-сообщение «время жизни истекло».

tracert пользуется этим специально. Первый эхо-запрос он отправляет с TTL = 1, и его отбрасывает первый же маршрутизатор - так становится известен его адрес. Затем TTL = 2, и отвечает второй узел. Так продолжается, пока не ответит сам адресат или не закончится лимит переходов. На каждый шаг уходит три запроса, поэтому в выводе три столбца с временем.

В Windows tracert использует ICMP (для IPv6 - ICMPv6). Это важно при разборе результатов: узел, который не отвечает на ICMP, будет выглядеть «пропавшим», хотя трафик через него идёт нормально.

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

Откройте командную строку или PowerShell (Win + R, cmd, Enter) и укажите имя узла или IP-адрес:

batch
tracert example.com

Права администратора не нужны. Если запустить tracert без аргументов или с ключом /?, команда выведет справку.

Трассировку можно в любой момент прервать сочетанием Ctrl + C.

Синтаксис и ключи

batch
tracert [-d] [-h макс_число] [-j список_узлов] [-w таймаут] [-R] [-S адрес_источника] [-4] [-6] имя_узла

Ключи можно писать и через дефис, и через косую черту: -d и /d работают одинаково.

Ключ Что делает
-d Не преобразовывать IP-адреса в имена узлов. Трассировка заметно ускоряется
-h число Максимальное число переходов. По умолчанию 30
-w мс Сколько ждать ответа на каждый запрос, в миллисекундах. По умолчанию 4000
-j список Свободная маршрутизация от источника через указанные узлы (до 9 адресов через пробел). Только IPv4, в интернете почти всегда блокируется
-R Трассировать путь туда и обратно. Только IPv6
-S адрес Адрес источника, с которого слать запросы. Только IPv6
-4 Использовать только IPv4
-6 Использовать только IPv6

На практике чаще всего нужны -d, -h и -w, остальные ключи пригодятся в редких сетевых задачах.

Примеры

Быстрая трассировка без определения имён:

batch
tracert -d example.com

Если узел далеко и 30 переходов не хватает:

batch
tracert -h 50 example.com

Ускорить трассировку через участок, где много узлов не отвечает: уменьшить таймаут до одной секунды и отключить имена.

batch
tracert -d -w 1000 example.com

Проверить путь только по IPv4 - полезно, когда у сайта есть и IPv4, и IPv6-адрес, а проблема проявляется лишь на одном из них:

batch
tracert -4 example.com

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

batch
tracert -d example.com > C:\Temp\trace.txt

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

Как читать результат

Задержка на маршруте растёт начиная с определённого прыжка и сохраняется до конца

Вот типичный вывод (адреса условные):

text
Трассировка маршрута к example.com [203.0.113.10]
с максимальным числом прыжков 30:

  1    <1 мс    <1 мс    <1 мс  192.168.1.1
  2     3 мс     2 мс     3 мс  100.64.12.1
  3     *        *        *     Превышен интервал ожидания для запроса.
  4     8 мс     7 мс     8 мс  198.51.100.33
  5    41 мс    40 мс    42 мс  198.51.100.97
  6    42 мс    41 мс    41 мс  203.0.113.10

Трассировка завершена.
  • Первый столбец - номер перехода (хопа).
  • Три столбца со временем - задержка ответа на каждый из трёх запросов. <1 мс значит, что ответ пришёл быстрее миллисекунды, так обычно отвечает домашний роутер.
  • Последний столбец - адрес узла, а если имя удалось определить, то имя и адрес в квадратных скобках.
  • Звёздочка означает, что ответа на запрос не было за отведённое время.

Первым почти всегда идёт ваш роутер (192.168.x.x, 10.x.x.x и подобные адреса). Дальше - оборудование провайдера; адреса вида 100.64.x.x - 100.127.x.x говорят о том, что провайдер использует общий NAT (CGNAT). Последняя строка - сам адресат, если он ответил.

Что означают звёздочки и рост задержки

Промежуточный узел не отвечает на запросы, но маршрут до сервера работает

Главная ошибка при чтении трассировки - считать каждую звёздочку или скачок времени поломкой. Маршрутизаторы прежде всего пересылают чужой трафик, а ответы на ICMP генерируют по остаточному принципу или не генерируют вовсе. Поэтому смотрите не на отдельную строку, а на то, что происходит после неё.

Звёздочки посреди маршрута, дальше узлы отвечают. Как переход 3 в примере выше. Этот маршрутизатор просто не отвечает на ICMP или ограничивает число ответов. Трафик через него проходит, проблемы нет.

Звёздочки до самого конца. Если после какого-то перехода все строки состоят из звёздочек вплоть до лимита в 30, возможны два варианта. Либо связь действительно обрывается на этом участке, либо дальше стоит межсетевой экран, который глушит ICMP, а сам сайт при этом открывается. Многие серверы и облачные площадки так и настроены. Проверьте доступность сервиса другим способом (открыть сайт, Test-NetConnection с портом - о нём ниже), прежде чем делать выводы.

Одна звёздочка из трёх. Один запрос потерялся или маршрутизатор ограничил частоту ответов. Если это единичный случай, внимания не стоит.

Скачок задержки на одном узле, дальше снова низкая. Например, на переходе 4 - 120 мс, а на 5 и 6 - по 40. Значит, этот маршрутизатор медленно отвечает на служебные запросы, но транзитный трафик через него идёт быстро. Это не проблема.

Задержка выросла и держится до конца. Как между переходами 4 и 5 в примере: 8 мс, а затем 40 и больше. Так обычно выглядит длинный участок пути - выход за границу страны или межконтинентальный канал - либо перегруженное соединение. Если раньше до этого узла было заметно быстрее, причина, скорее всего, на этом стыке.

Одни и те же адреса повторяются по кругу. Признак петли маршрутизации. Исправить её может только тот, кто управляет этим оборудованием, - обычно провайдер.

Сообщение «Заданный узел недоступен». Какой-то маршрутизатор на пути прямо сообщил, что не знает, куда отправлять пакет дальше. Адрес этого маршрутизатора в строке подскажет, в чьей сети проблема.

Сразу ошибка «Не удаётся разрешить системное имя узла». До трассировки дело не дошло: Windows не смогла получить IP-адрес по имени. Проблема в DNS, а не в маршруте. Проверить это поможет команда nslookup, а сбросить кэш DNS - ipconfig /flushdns.

Учтите, что маршрут туда и обратно может отличаться. tracert показывает только путь от вас до узла, а ответные пакеты могут возвращаться другой дорогой.

tracert или pathping

pathping - ещё одна встроенная команда Windows. Сначала она строит маршрут так же, как tracert, а затем долго опрашивает каждый узел и считает процент потерь на каждом участке.

batch
pathping -n example.com

Ключ -n здесь отключает определение имён, как -d у tracert. Сбор статистики занимает несколько минут, зато результат точнее показывает, где теряются пакеты. Правило простое: для быстрого ответа «где обрывается» хватит tracert, для жалоб на нестабильную связь и потери лучше подходит pathping.

Трассировка в PowerShell

В Windows PowerShell есть командлет Test-NetConnection с параметром -TraceRoute:

powershell
Test-NetConnection example.com -TraceRoute

Он выдаёт список адресов на пути без времени по каждому узлу, зато результат удобно обрабатывать в скриптах. Ограничить число переходов можно параметром -Hops:

powershell
Test-NetConnection example.com -TraceRoute -Hops 15

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

powershell
Test-NetConnection example.com -Port 443

Строка TcpTestSucceeded : True означает, что порт отвечает и сервис доступен, даже если ICMP на сервере закрыт.

В PowerShell 7 есть ещё Test-Connection с параметром -Traceroute, он показывает и задержки по узлам:

powershell
Test-Connection example.com -Traceroute

Аналоги в Linux и macOS

В Linux и macOS та же задача решается командой traceroute. По умолчанию она отправляет не ICMP, а UDP-пакеты, поэтому результаты могут отличаться от Windows: ключ -I переключает её на ICMP, а -T в Linux - на TCP, что помогает пройти через строгие межсетевые экраны. Ещё удобнее утилита mtr, которая непрерывно повторяет трассировку и сразу считает потери - по сути, tracert и pathping в одном окне.

Если нужно посмотреть маршрут до вашего сервера не со своего компьютера, а из другой сети или страны, помогут онлайн-сервисы трассировки: они запускают ту же проверку со своих узлов.

Что делать с результатом

  • Обрыв на первом переходе (роутер не отвечает или звёздочки сразу) - проблема в домашней сети: кабель, Wi-Fi, сам роутер.
  • Обрыв или большие задержки на первых узлах провайдера - звоните провайдеру и приложите вывод трассировки.
  • Всё хорошо до последних переходов, а сам сервер не отвечает - вопрос к хостингу или владельцу сервиса, но сначала проверьте порт через Test-NetConnection.
  • Ошибка разрешения имени - разбирайтесь с DNS, маршрут тут ни при чём.

Для обращения в поддержку лучше прислать вывод tracert -d и, если жалоба на потери, pathping -n: так специалисту сразу видны адреса без лишних имён.