F3 cloud · База знаний

Оформление

Диагностика сети: трассировка и проверка качества соединения (WinMTR, MTR, Speedtest)

Пошаговая инструкция F3 Cloud по диагностике качества соединения: Speedtest на сервере, трассировка WinMTR с ПК и обратная MTR с сервера. Что отправить в поддержку.

Диагностика сети: трассировка и проверка качества соединения (WinMTR, MTR, Speedtest) ​

Данная инструкция поможет быстро понять, где именно «теряются» миллисекунды и пакеты – на стороне провайдера пользователя, в магистрали, дата-центре или уже на самом сервере.

DANGER

Перед началом: отключите VPN/прокси и любые «ускорители» сети на компьютере и сервере.
Запускайте тесты при стабильной нагрузке – без активных загрузок/стримов.

Шаг 1. Тест скорости на сервере (Speedtest) ​

Подключитесь к серверу по SSH и выполните:

bash
wget -qO- bench.sh | bash

По результатам сохраните скриншот результата и прикрепите его в тикет.
Текстовый вывод отправлять не требуется.

DANGER

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

Шаг 2. Трассировка с вашего ПК до сервера (WinMTR) ​

  1. Отключите VPN.
  2. Скачайте WinMTR с официального сайта: https://winmtr.net/.
  3. Запустите WinMTR и в поле Host укажите IP вашего сервера.
  4. Нажмите Start и дождитесь 100–200 пакетов (1–3 минуты).
  5. Нажмите Stop.
  6. Отправьте скриншот результата в тикет.

WARNING

Совет: если нужно «дожать» редкие пики задержек – увеличьте длительность до 5–10 минут.

Некоторые маршрутизаторы/узлы могут не отвечать на ICMP-проброс – одиночная «потеря» на промежуточном хопе не всегда означает проблему. Важнее финальные хопы и «наследование» потерь вниз по трассе (см. раздел «Как читать результаты»).

Шаг 3. Обратная трассировка с сервера до вашего ПК (MTR) ​

На сервере выполните:

bash
sudo apt update && sudo apt install -y mtr && mtr -rw <IP-адрес_вашего_ПК>

Где вместо <IP-адрес_вашего_ПК> укажите реальный IP вашего компьютера (не из VPN). Узнать его просто: зайдите на https://2ip.ru/.

Сделайте скриншот результатов и приложите к обращению:

bash
mtr -rw <IP_ПК> | tee mtr-to-client.txt

WARNING

Пара «прямой WinMTR» + «обратный MTR» позволяет увидеть проблему с двух сторон маршрута и быстрее локализовать участок с потерями/джиттером.

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

  • Loss% (потери): важно смотреть не на один хоп, а на «наследование» потерь. Если потери появляются на хопе №n и сохраняются на всех последующих хопах – проблема, как правило, начинается на/после №n. Если потери видны на одном хопе, но на следующем хопе их нет – чаще всего промежуточный узел ограничивает ответы ICMP (rate limit) и это не означает реальную потерю трафика.
  • Latency (Best/Avg/Wrst/Last): оценивайте значения на конечных хопах и общий тренд. Стабильный рост задержки и всплески ближе к концу трассы обычно указывают на перегрузку на маршруте ближе к целевому сегменту или на «последней миле».
  • Jitter (разброс): большой разрыв между Best и Wrst на последних хопах – признак нестабильности соединения.

Пояснения терминов:

хоп – промежуточный узел на пути от вашего устройства до сервера;

ICMP – служебные «диагностические» ответы сети (используются в ping/traceroute);

rate limit – ограничение частоты ответов (узел может отвечать не на все запросы);

тренд – общий характер изменения показателей (растут/падают/скачут);

всплески – кратковременные резкие увеличения задержки;

последняя миля – участок сети ближе всего к конечному пользователю (часто влияет провайдер/локальная сеть).

WARNING

Если вы не уверены в интерпретации, просто приложите результаты Speedtest, WinMTR и MTR – мы проанализируем их и вернёмся с выводами и рекомендациями.

Что прислать в поддержку F3 Cloud ​

Соберите одно обращение (тикет или письмо) и приложите:

  1. IP-адрес вашего сервера, а также вашу локацию и провайдера (со стороны клиента).
  2. Дату и примерное время, когда наблюдалась проблема (с указанием часового пояса).
  3. Результат Speedtest с сервера – скриншот.
  4. Результат WinMTR (ПК → сервер) – скриншот.
  5. Результат MTR (сервер → ПК) – скриншот.
  6. Дополнительные наблюдения (при наличии): «просадки в играх», «обрывы стрима/видеосвязи», зависимость от времени суток и т. п.

Частые вопросы (FAQ) ​

WinMTR показывает 100% потери на одном из промежуточных хопов – это плохо?

Не обязательно. Многие промежуточные маршрутизаторы ограничивают или игнорируют ответы на диагностические запросы (ICMP), из-за чего WinMTR может показывать «потери» именно на одном хопе.

Ориентируйтесь на два признака:

  1. Если на следующих хопах (и особенно на последнем, целевом) потерь нет – это, как правило, особенность ответа маршрутизатора и не является проблемой.
  2. Если потери и/или рост задержки сохраняются на последующих хопах и доходят до конца трассы – это уже признак реальной проблемы на маршруте.
Команда mtr не найдена на серверe

Установите mtr одной командой для вашей ОС.

Debian/Ubuntu:

bash
sudo apt update && sudo apt install -y mtr

CentOS Stream/Rocky Linux/AlmaLinux:

bash
sudo dnf install -y mtr
Сколько времени гонять трассировку?

Обычно достаточно 1–3 минут, чтобы увидеть стабильную картину (примерно 100–200 пакетов). Если проблема возникает «плавающе» (то есть появляется не всегда) – увеличьте длительность теста до 5–10 минут и приложите скриншот результата.

Хорошие практики ​

  • Запускайте тесты в одинаковых условиях: одна и та же сеть, одно и то же устройство и по возможности проводное подключение. Это важно, потому что Wi-Fi, разные устройства и разные точки доступа могут давать разный пинг, потери и скорость – результаты становятся несопоставимыми.
  • Не запускайте Speedtest и трассировку (WinMTR/MTR) одновременно – выполняйте по очереди. Параллельные тесты создают дополнительную нагрузку на канал и могут искусственно ухудшать показатели (скорость «режется», задержка растёт), из-за чего диагностика получается неверной.
  • Проводите тесты в момент, когда проблема действительно наблюдается (например, «вечером есть просадки», «в игре пинг скачет»). Тесты «когда всё нормально» часто не фиксируют причину и не помогают в расследовании.
  • Делайте скриншоты так, чтобы были видны ключевые данные: IP/адрес сервера (если отображается), таблица результатов и итоговые значения. Лишнее (личные вкладки, уведомления, переписки) лучше не захватывать – выделяйте только область с результатом.
  • Если у вас несколько сетей или устройств (дом/офис/LTE, разные провайдеры, разные роутеры) – присылайте набор тестов по каждой сети отдельно и прямо указывайте, где именно сделан тест (например: «домашний Wi-Fi Ростелеком», «офис кабель», «LTE МТС»). Это помогает понять, проблема связана с конкретной сетью/провайдером или воспроизводится везде.
  • Если используете VPN/прокси на стороне клиента – на время диагностики отключите их либо явно отметьте в тикете, что тесты выполнялись через VPN/прокси. Это важно, потому что VPN меняет маршрут и может добавлять задержку, что искажает результаты.

База знаний F3 Cloud

© 2026 F3 Cloud