Артём Савельев 
Трассировка маршрута: как найти, где теряются пакеты по пути к сайту
Пинг говорит, что «до сервера далеко или плохо», но не говорит, где именно. Трассировка отвечает на этот вопрос: она показывает каждый маршрутизатор на пути пакета и время до него. Разбираем, как запустить трассировку на любой системе, как читать её вывод без паники из-за звёздочек — и в каких случаях она действительно находит виновного.
Как это работает: элегантный трюк с TTL
У каждого IP-пакета есть поле TTL (time to live) — счётчик прыжков, восьмибитное число не больше 255. Каждый маршрутизатор по пути уменьшает его на единицу, а когда TTL доходит до нуля — выбрасывает пакет и отправляет вам сообщение «время истекло», подписанное своим адресом. Трассировка пользуется этим честно и нагло: посылает пакет с TTL=1 — и узнаёт первый маршрутизатор, потом с TTL=2 — узнаёт второй, и так далее до цели. Обычно предел — 30 прыжков (значение по умолчанию), но до большинства серверов Рунета пакет добирается за 8–15.
# Windows tracert example.ru # macOS / Linux traceroute example.ru # Лучший вариант: mtr — трассировка + статистика потерь в динамике mtr example.ru
Если есть возможность поставить mtr — ставьте: он гоняет трассировку непрерывно и показывает процент потерь и разброс задержки по каждому узлу, а не разовый снимок. Разовая трассировка ловит момент; mtr за пару минут набирает статистику, которой уже можно верить.
Читаем вывод: что означает каждая строка
Типичный вывод — пронумерованные строки с адресом узла и тремя замерами времени. Первая строка — ваш роутер, дальше сеть провайдера, магистрали, сеть хостинга и, наконец, сам сервер. Читается это по трём паттернам:
| Картина в выводе | Что это значит | Насколько тревожно |
|---|---|---|
| Время плавно растёт с каждым прыжком | Нормальная картина: каждый узел дальше предыдущего | Всё в порядке |
| Резкий скачок (+50–100 мс) на одном узле и дальше держится | Пакет ушёл на дальнюю магистраль (другая страна/континент) — или узел перегружен | Скачок между городами — физика; скачок внутри одного города — вопрос |
| Звёздочки (* * *) на промежуточном узле, но дальше маршрут идёт | Узел просто не отвечает на служебные пакеты — маршрутизаторам разрешено их игнорировать | Не тревожно: пакеты через узел проходят |
| Звёздочки начались с какого-то узла и до самого конца | Маршрут обрывается: дальше пакеты не проходят (авария, фильтр, блокировка) | Вот здесь и живёт проблема — на последнем ответившем узле |
| Потери в середине, но 0% на последнем узле (в mtr) | Промежуточный узел экономит на ответах вам, но транзит не теряет | Ложная тревога: важны потери именно на конечном узле |
Самая частая ошибка чтения трассировки — паника из-за звёздочек и «потерь» на промежуточных узлах. Маршрутизаторы обрабатывают служебные ответы по остаточному принципу: им важнее пересылать трафик, чем отвечать на ваши зонды. Правило простое: диагноз ставится по конечному узлу и по точке, где ответы пропали навсегда, — а не по каждому молчуну в середине пути.
Разбор примера: типичная трассировка построчно
1 192.168.1.1 1 ms 1 ms 1 ms ← ваш роутер 2 10.77.0.1 4 ms 5 ms 4 ms ← узел провайдера в районе 3 87.226.x.x 6 ms 6 ms 7 ms ← ядро сети провайдера 4 * * * ← магистральный узел молчит (норма) 5 188.128.x.x 18 ms 19 ms 18 ms ← стык с магистралью, другой город 6 95.167.x.x 42 ms 44 ms 43 ms ← магистраль, ещё дальше 7 193.107.x.x 45 ms 44 ms 45 ms ← сеть дата-центра 8 193.107.239.67 45 ms 45 ms 46 ms ← сам сервер
Что здесь видно за десять секунд: локальная сеть чистая (1 мс до роутера), провайдер добавляет считанные миллисекунды, главный прирост (+24 мс на шаге 5→6) — это переход на дальнюю магистраль, то есть география, а не поломка. Молчащий четвёртый узел никого не должен волновать: следующие за ним отвечают. Сервер стабилен: три замера последней строки почти одинаковы. Диагноз — маршрут здоров, задержка объясняется расстоянием. Если бы на шаге 6 время прыгнуло до 300 мс и держалось до конца — вопрос к этой магистрали; если бы строки 5–8 превратились в звёздочки — к узлу номер 4 и дальше.
Почему маршруты не ходят по прямой
Трассировки регулярно удивляют географией: пакет из Новосибирска во Владивосток может ехать через Москву, а между двумя соседними офисами — через другой город. Это не глупость сети, а её экономика: маршруты определяются не расстоянием, а договорами операторов о стыках (пирингах). Трафик идёт туда, где у вашего провайдера есть выгодный стык, — и иногда этот стык физически далеко. Для владельца сайта отсюда важный вывод: задержка до аудитории зависит не только от того, где стоит сервер, но и от того, как сети провайдеров аудитории состыкованы с сетью вашего хостинга. Проверить это можно только измерением из реальных сетей в реальных городах — по карте не угадаешь.
Ограничение, о котором забывают: маршрут — только ваш
Трассировка показывает путь от вас до сервера — и только его. У посетителя из другого города, у другого оператора, маршрут другой: он пойдёт через другие магистрали и упрётся (или не упрётся) в другие проблемы. Более того, обратный путь пакетов может отличаться от прямого — маршрутизация несимметрична. Поэтому «у меня трассировка чистая» и «у клиентов сайт тормозит» спокойно сосуществуют: вы просто смотрите на разные дороги.
Отсюда практический вывод: трассировка — инструмент локализации проблемы, которую уже заметили, а не инструмент наблюдения. Заметить же проблему «в других дорогах» можно, только регулярно проверяя сайт из тех мест, где живёт аудитория, — как мы разбирали в статье о проверке доступности из России.
Поддержка любит конкретику. Идеальное вложение к тикету: вывод mtr за 5 минут (сотня циклов), время замера, и одна фраза — «потери N% начинаются с узла X». Такой тикет решается в разы быстрее, чем «у нас всё тормозит».
Мини-алгоритм: пинг → трассировка → выводы
Рабочая связка диагностики выглядит так. Шаг 1: пинг до цели — есть ли вообще проблема и какая (высокая задержка? потери?). Шаг 2: трассировка или mtr — где начинается: в вашей сети (первые 1–2 прыжка), у провайдера (следующие несколько), на магистрали или у хостинга (последние). Шаг 3: если проблема на последних прыжках — проверка сайта из другой сети и других городов: если там всё хорошо, дорога плохая только у вас; если плохо везде — проблема на стороне площадки, и это уже разговор с хостером. Кто именно виноват в каждом случае — мы подробно раскладывали в статье «Сайт не работает: как понять, у кого проблема».
Трассировку запускают, когда уже что-то болит. Чтобы узнавать о боли раньше клиентов, Пруфен проверяет доступность и время ответа сайта по расписанию из 13 точек в разных городах — и когда сайт перестаёт отвечать хотя бы из части из них, вы получаете уведомление с картиной «где лежит, где живёт»: готовая замена ручной трассировке из пяти городов сразу.
Частые вопросы
Почему tracert и traceroute показывают разные картинки для одного сайта? Windows шлёт ICMP-зонды, классический Unix-traceroute — UDP. Файрволы по пути относятся к ним по-разному, отсюда разные звёздочки. Смысл вывода от этого не меняется.
Трассировка обрывается, а сайт при этом открывается. Как так? Сервер или его файрвол игнорирует служебные зонды, но нормально отвечает на HTTP. Это обычная настройка безопасности. Верить в таком случае стоит HTTP-проверке, а не трассировке.
Может ли трассировка показать блокировку? Косвенно: маршрут, стабильно обрывающийся на сети оператора (а из других сетей проходящий), — характерный признак фильтрации. Для уверенного диагноза нужно сравнить трассировки из нескольких сетей и городов.
Через VPN трассировка выглядит странно — почему? Потому что для вашей системы весь путь до VPN-сервера — один «виртуальный» прыжок: реальные маршрутизаторы внутри туннеля не видны. Первые узлы после туннеля — уже сеть VPN-провайдера. Для диагностики собственного подключения VPN нужно отключить.
Сайт работает по HTTPS, а трассировка «не проходит». Можно ли трассировать именно порт 443? Да, инструментами вроде tcptraceroute или tracetcp: они шлют TCP-пакеты на нужный порт, и файрволы пропускают их охотнее, чем классические зонды. Полезно, когда обычная трассировка обрывается на подходе к серверу, а понять путь всё-таки нужно.
Что значит время меньше миллисекунды на первом прыжке? Это ваш роутер — он в одном кабеле или одном Wi-Fi от вас. Если и здесь десятки миллисекунд, проблема вообще не в интернете, а в вашей локальной сети: перегруженный Wi-Fi-канал, старый роутер, помехи.