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

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

{% hint style="danger" %}
**Перед началом:** отключите VPN/прокси и любые «ускорители» сети на компьютере и сервере. \
Запускайте тесты при стабильной нагрузке – без активных загрузок/стримов.
{% endhint %}

***

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

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

```bash
wget -qO- bench.sh | bash
```

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

{% hint style="danger" %}
Почему это важно: команда запускает автоматический тест, который измеряет скорость сетевого соединения и показывает базовые характеристики сервера – по результатам можно оценить качество канала и выявить возможные ограничения.
{% endhint %}

***

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

{% tabs %}
{% tab title="Windows (WinMTR)" %}

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

{% hint style="warning" %}
Совет: если нужно «дожать» редкие пики задержек – увеличьте длительность до 5–10 минут.

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

{% tab title="macOS / Linux (альтернатива)" %}
Если под рукой нет Windows, допускается аналогичная трассировка утилитой **mtr**:

**macOS (Homebrew):**

```bash
brew install mtr
sudo mtr -rw <IP_сервера>
```

**Linux (десктоп):**

```bash
sudo apt update && sudo apt install -y mtr
sudo mtr -rw <IP_сервера>
```

Дождитесь 100–200 пакетов и сохраните вывод в файл:

```bash
sudo mtr -rw <IP_сервера> | tee mtr-to-server.txt
```

Приложите скриншот к тикету.

{% hint style="warning" %}
Некоторые маршрутизаторы/узлы могут не отвечать на ICMP-проброс – одиночная «потеря» на промежуточном хопе **не всегда** означает проблему. Важнее финальные хопы и «наследование» потерь вниз по трассе (см. раздел «Как читать результаты»).
{% endhint %}
{% endtab %}
{% endtabs %}

***

### Шаг 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
```

{% hint style="warning" %}
Пара «прямой WinMTR» + «обратный MTR» позволяет увидеть проблему с двух сторон маршрута и быстрее локализовать участок с потерями/джиттером.
{% endhint %}

***

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

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

> **Пояснения терминов:**
>
> **хоп** – промежуточный узел на пути от вашего устройства до сервера;
>
> **ICMP** – служебные «диагностические» ответы сети (используются в ping/traceroute);
>
> **rate limit** – ограничение частоты ответов (узел может отвечать не на все запросы);
>
> **тренд** – общий характер изменения показателей (растут/падают/скачут);
>
> **всплески** – кратковременные резкие увеличения задержки;
>
> **последняя миля** – участок сети ближе всего к конечному пользователю (часто влияет провайдер/локальная сеть).

{% hint style="warning" %}
Если вы не уверены в интерпретации, просто приложите результаты Speedtest, WinMTR и MTR – мы проанализируем их и вернёмся с выводами и рекомендациями.
{% endhint %}

***

### Что прислать в поддержку U1HOST

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

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

***

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

<details>

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

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

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

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

</details>

<details>

<summary>Команда mtr не найдена на серверe</summary>

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

Debian/Ubuntu:

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

CentOS Stream/Rocky Linux/AlmaLinux:

```bash
sudo dnf install -y mtr
```

</details>

<details>

<summary>Сколько времени гонять трассировку?</summary>

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

</details>

***

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

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