# Диагностика сети: трассировка и проверка качества соединения (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 меняет маршрут и может добавлять задержку, что искажает результаты.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://wiki.u1host.com/vps/network-troubleshooting-traceroute.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.