Медленный интернет: семь причин и как точно их различить

«Интернет тормозит» — самая бесполезная формулировка проблемы. За ней может стоять что угодно: перегруженная вечером сота, забившийся буфер вашего домашнего роутера, медленный маршрут до конкретного дата-центра, упавший CDN, проблема в самом приложении или просто Wi-Fi на 2.4 ГГц с десятью соседями. Если не отделить эти случаи друг от друга, вы будете звонить провайдеру там, где надо менять кабель, или менять тариф, где надо настроить роутер.

Эта статья — пошаговый план диагностики, который позволяет за 5–10 минут довести «медленный интернет» до конкретной причины. Без догадок, с конкретными командами и числами.

Алгоритм диагностики (сверху вниз)

Шаг 1: ping шлюза            ←  rtt > 1 мс? → проблема Wi-Fi/кабеля
    │ ok
Шаг 2: ping 1.1.1.1          ←  loss > 0%?  → проблема last mile
    │ ok
Шаг 3: bufferbloat-тест       ←  ping взлетает при загрузке? → bufferbloat
    │ ok
Шаг 4: speedtest               ←  далеко от тарифа? → перегрузка/shaping
    │
    ├─ медленно одинаково всем серверам → перегрузка
    └─ медленно только одному типу       → shaping или маршрут

Шаг 5: mtr                    ←  loss или RTT-скачок на N-м хопе → этот узел
    │ ok
Шаг 6: DevTools TTFB          ←  > 500 мс?  → проблема backend

Подход послойно

Любая сетевая проблема живёт на одном из шести слоёв, и инструменты для каждого свои:

1. Физика. Кабель, Wi-Fi, сигнал. Проверяется простым «у соседнего устройства такая же проблема?»
2. Канальный. Ошибки на интерфейсе. Команда ip -s link на Linux.
3. IP. Маршрут, ping, packet loss. Команды ping, traceroute, mtr.
4. Транспорт. TCP-retransmits, окно перегрузки, jitter. Команды ss -tin, tcptrace.
5. Прикладной. TTFB, время DNS, размер ответа. Браузерный DevTools на вкладке Network.
6. Серверный. Backend response time. Видно по TTFB, более точно — серверным мониторингом.

Инструменты, которые покрывают 95% случаев

Признаки перегрузки

Перегрузка — это когда канал упирается в потолок и пакетам приходится ждать. Характерные признаки:

• Зависит от времени суток. Вечер 19–23 — пик, утро тихо. Если днём всё хорошо, а вечером плохо, скорее всего перегрузка.
• Медленно везде. Все сайты, все сервисы. Не один-два конкретных.
• Растёт RTT под нагрузкой. ping в спокойное время 10 мс, а во время скачивания файла подскакивает до 200 мс — это ровно перегрузка буфера.
• Соседи видят то же. Один провайдер, одна проблема.

Признаки shaping

Shaping — это намеренное ограничение определённого класса трафика. Отличается от перегрузки тем, что выборочный:

• Стабильный потолок. Скорость упирается ровно в X Мбит/с и не двигается, как линейкой подрезано.
• Один тип медленный, другой нет. Загрузки с одного облака медленные, с другого нормальные. Стриминг тормозит, веб работает.
• Время суток не влияет. Если ограничение жёсткое, оно работает 24/7.
• График ровный. Перегрузка даёт «зубчатый» график (то быстрее, то медленнее), shaping — ровную линию.

Внутреннее устройство shaping разобрано в статье про QoS и про traffic shaping.

Асимметрия: download быстро, upload медленно (или наоборот)

Часто пользователи замечают, что скачивание идёт быстро, но отправить файл — мучение. Возможные причины:

• Тариф асимметричный. Большинство домашних тарифов: 100 Мбит down, 30 Мбит up. Это нормально по дизайну.
• Bufferbloat именно на upstream. Если канал отдаёт меньше, чем принимает, забивается чаще — отсюда задержки в обе стороны.
• Wi-Fi 2.4 ГГц с интерференцией. На отдачу влияет сильнее, чем на приём.
• Shaping upstream. Некоторые провайдеры режут upload жёстче.

Проблемы с маршрутом

Если медленно только до одного сервиса, а до соседних — нормально, проблема в маршруте, не в вашем канале:

• Запустите mtr -rwn -c 100 target.example.com — это сделает 100 ping-ов на каждый хоп и покажет статистику.
• Loss на одном из хопов посередине = проблема ровно на этом узле.
• RTT внезапно скачет на одном хопе с 30 мс до 200 мс = неоптимальный маршрут (CDN решил пустить вас «через Сингапур»).
• На последнем хопе loss до 50% = таргетный сервер сам тормозит, не сеть.

Когда виноват не интернет, а сервер

Признаки серверной проблемы:

• TTFB больше 500 мс в DevTools (Network → Timing → Waiting). Это backend, не сеть.
• ping до сервера нормальный, но HTTP-ответ долгий. Тоже backend.
• С другой сети та же проблема. Если разные провайдеры видят одинаковое замедление — серверная сторона.
• Status pages. Большие сервисы публикуют статус — есть смысл проверить status.cloudflare.com, isitdownrightnow.com.

Особенности мобильных сетей

На мобильном телефоне диагностика отличается:

• Скорость может прыгать из-за радиоканала каждые секунды.
• iperf3 на 30 секунд показывает усреднённую картину, но может скрывать рывки.
• Перегрузка соты в час пик добавляет случайную задержку.
• Полезно сравнить speedtest по 4G и 5G — иногда «лучшая» сеть оказывается хуже.

Подробно мобильная специфика разобрана в статье про скачки скорости мобильного интернета.

Итого

Замедление — это симптом, а не диагноз. Семь шагов алгоритма (ping шлюза → ping внешнего → bufferbloat → speedtest → mtr → DevTools TTFB → серверный статус) за 5–10 минут отделяют bufferbloat от перегрузки, маршрут от backend, last mile от core. Этот набор инструментов давно открытый и бесплатный — пользоваться им может любой, и стоит того, чтобы один раз освоить.