Провайдер режет скорость к одному сервису: как это доказать замерами, а не ощущениями

MAATRIX

Спидтест показывает полную полосу, до большинства сайтов всё летает — а конкретный сервис, будь то стриминг, игровой сервер, облачное хранилище или мессенджер, стабильно ползёт на скорости в разы ниже обычной. Первая мысль — «провайдер режет именно этот трафик», и иногда это правда: DPI-оборудование умеет распознавать поток по SNI в TLS ClientHello, по диапазону IP-адресов или по сигнатуре протокола и применять к нему отдельный, более узкий шейпер. Но такая же картина возникает от перегруженного транзитного узла именно на маршруте к сервису, от проблем на его стороне или от обычной деградации канала в часы пик. Разница между этими причинами не в ощущениях — она в наборе конкретных тестов. Дальше — эта методика по шагам.

Симптомы, которые путают: как выглядит targeted throttling снаружи

Прежде чем что-то доказывать, стоит зафиксировать, что именно вы наблюдаете, потому что «сервис тормозит» — это не диагноз, а повод для замера. Типичная картина, которая наводит на мысль о шейпинге конкретного сервиса:

• обычный speedtest.net или fast.com показывает скорость, близкую к тарифной, но скачивание файла или стрим именно с проблемного сервиса идёт в разы медленнее;
• деградация воспроизводится стабильно, а не время от времени — то есть это не разовый глюк, а устойчивое состояние в течение дней;
• проблема привязана именно к сервису (или домену/IP-диапазону), а не к времени суток — то есть она не исчезает ночью, когда общая нагрузка на сеть провайдера падает;
• на том же устройстве, в то же самое время, к другим сервисам с сопоставимым профилем трафика (например, тоже видео или тоже большие файлы) скорость нормальная.

Важно не путать сам факт «сервис Х медленнее сервиса Y» с доказательством шейпинга — это только повод копать глубже. У сервиса Х может быть просто более узкий канал на своей стороне, более длинный маршрут до вас или собственный троттлинг по вашей подписке (например, бесплатный тариф стримингового сервиса намеренно ограничивает битрейт). Задача следующих разделов — исключить эти альтернативы одну за другой, а не сразу называть виновником провайдера.

Три причины, с которыми легко перепутать таргетированный шейпинг

Перегруженный транзитный узел именно на пути к сервису. Провайдеры обмениваются трафиком через ограниченное число точек пиринга и транзитных операторов. Если маршрут к конкретному сервису проходит через перегруженный стык (типичный кейс — вечерний пик на одном конкретном пиринге, когда остальные маршруты провайдера в порядке), картина будет та же: к этому сервису медленно, ко всем остальным нормально. Это не преднамеренный шейпинг, а следствие маршрутизации — подробнее о том, почему маршрут пакета редко совпадает с географической близостью, разобрано в статье про несовпадение маршрута с географией.

Проблема на стороне самого сервиса. Перегруженный edge-сервер CDN в вашем регионе, рейт-лимит на API аккаунт, деградация конкретного дата-центра — всё это выглядит для вас идентично шейпингу: медленно именно к этому адресу. Отличить такую проблему можно только протестировав несколько разных серверов того же сервиса (раздел ниже) или сверившись со статус-страницей сервиса и жалобами других пользователей за тот же период.

Обычная деградация канала в часы пик. Если у провайдера в целом не хватает выходной полосы вечером, страдают все ресурс-требовательные сервисы примерно одновременно, но заметнее это там, где вы чаще смотрите на скорость — обычно в стриминге и играх. Разница с targeted throttling в том, что деградация часа пик плавает вместе с временем суток и затрагивает любой достаточно «тяжёлый» трафик в этот момент — это стоит проверить прогонами тестов в разное время суток, а не только когда проблема свежа в памяти.

Шаг 1: сравнение скорости к разным целям одновременно и с одной точки

Первый и самый дешёвый тест — не спидтест «вообще», а параллельное сравнение нескольких целей с одного устройства, в одно и то же окно времени, чтобы исключить влияние времени суток и текущей загрузки вашего собственного канала.

Идея: выбрать 3-4 контрольные точки — проблемный сервис, крупный CDN общего назначения (например, Cloudflare или другой независимый узел), ваш собственный VPS в удобной локации и, если есть возможность, speedtest-сервер провайдера. Затем прогнать замер ко всем одновременно или строго последовательно в пределах пары минут:

# Один и тот же формат -w — сначала к проблемному сервису,
# затем сразу к контрольной точке (независимому CDN)
curl -o /dev/null -s -w \
  "connect: %{time_connect}s  ttfb: %{time_starttransfer}s  speed: %{speed_download} B/s\n" \
  https://проблемный-сервис.example/крупный-файл

curl -o /dev/null -s -w \
  "connect: %{time_connect}s  ttfb: %{time_starttransfer}s  speed: %{speed_download} B/s\n" \
  https://speed.cloudflare.com/__down?bytes=100000000

Если под рукой свой VPS, к нему можно гонять iperf3 — точный и управляемый тест пропускной способности без зависимости от HTTP-стека сервиса на другом конце:

# На VPS (сервер-приёмник)
iperf3 -s

# С клиента — TCP-тест на 30 секунд с параллельными потоками
iperf3 -c ваш-vps-ip -t 30 -P 4

Смысл этой связки: если проблемный сервис показывает низкую скорость, а параллельно к независимому CDN и к вашему собственному VPS скорость нормальная — общая пропускная способность канала не является узким местом, и проблема действительно локализована на пути или на классификации трафика именно к этому сервису. Если же в это же окно времени просела скорость вообще ко всем целям — это уже не таргетированный шейпинг, а либо общая перегрузка вашего канала, либо проблема на стороне провайдера в целом, и дальше нет смысла подозревать конкретный сервис.

Важно гонять тест несколько раз подряд и в разное время суток (минимум утро, день, вечерний пик), а не полагаться на один прогон — единичный результат легко объяснить случайным совпадением с чем угодно.

Шаг 2: тест через VPN или прокси — самый сильный различитель

Это ключевой тест, который отделяет реальный DPI-шейпинг от прочих причин. Логика простая: DPI-оборудование провайдера классифицирует трафик по открытым признакам — SNI в TLS-хендшейке, IP-адресу или подсети назначения, иногда по сигнатурам протокола внутри незашифрованного или частично зашифрованного потока. Если завернуть тот же трафик в VPN-туннель или через прокси, все эти признаки становятся невидимы для DPI: провайдер видит только зашифрованный поток к IP-адресу VPN-сервера, а не к реальному конечному сервису.

Методика: замерьте скорость к проблемному сервису напрямую (как в шаге 1), поднимите VPN-туннель (свой WireGuard/OpenVPN-сервер или коммерческий VPN) до точки физически близкой к вашей — не меняйте сразу и провайдера-классификатора, и континент, иначе будет неясно, что именно исправило скорость, — и замерьте скорость к тому же сервису через туннель тем же инструментом.

Интерпретация результата:

Оговорка: сам факт, что скорость через VPN другая, не всегда означает шейпинг — VPN меняет маршрут пакета целиком, потому что трафик идёт через другой узел выхода, с другим ASN и, возможно, другими пирингами. Это тот же эффект, из-за которого маршрут не совпадает с географией: путь через Франкфурт для пользователя из Москвы иногда оказывается быстрее прямого именно из-за того, какие сети между собой обмениваются трафиком — разобрано в статье про то, почему Франкфурт может быть быстрее Москвы для москвичей. Поэтому для чистоты эксперимента стоит повторить тест с VPN-сервером в разных локациях и убедиться, что восстановление скорости воспроизводится стабильно, а не один раз случайно.

Шаг 3: повторяемость на разных серверах внутри одного облака или CDN сервиса

Если сервис раздаёт контент через крупный CDN или облако (Cloudflare, AWS, свою сеть точек присутствия), полезно проверить, деградация касается конкретного адреса/edge-сервера или сервиса целиком. Практически это означает: найти 2-3 разных IP или домена, принадлежащих тому же CDN/облаку, но обслуживающих разные сервисы, и сравнить скорость к каждому.

Если у вас есть возможность обратиться к разным edge-узлам одного и того же CDN (например, через инструменты вроде curl --resolve, которые позволяют принудительно указать конкретный IP при сохранении домена в SNI):

# Принудительно обратиться к конкретному IP-адресу edge-сервера,
# сохранив нужный SNI/Host — полезно, чтобы сравнить разные точки
# присутствия одного и того же CDN
curl --resolve проблемный-сервис.example:443:1.2.3.4 \
  -o /dev/null -s -w "speed: %{speed_download} B/s\n" \
  https://проблемный-сервис.example/крупный-файл

Что говорят разные исходы:

• Все edge-узлы этого CDN одинаково медленные, а другие сервисы на том же CDN в норме — сильный аргумент за то, что провайдер различает трафик не по IP-диапазону CDN (иначе резало бы всех его клиентов одинаково), а по более специфичному признаку — скорее всего по SNI/домену конкретного сервиса.
• Только один edge-узел или регион CDN медленный, остальные в порядке — больше похоже на локальную проблему точки присутствия сервиса или на перегруженный пиринг именно к этому дата-центру, а не на классификацию по домену.
• Весь CDN целиком медленный, включая посторонние сервисы на нём — проблема на уровне взаимодействия провайдера с сетью этого CDN в целом, не обязательно шейпинг конкретного сервиса. Для локализации участка пригодится методика из статьи про то, где именно теряются пакеты — traceroute/mtr с двух сторон покажут хоп, где начинается деградация.

Инструменты для замеров: iperf3, speedtest-cli и curl -w на практике

Три инструмента закрывают почти всю методику выше, и у каждого своя роль.

iperf3 — самый точный тест пропускной способности TCP/UDP, но у него есть ограничение: нужен сервер iperf3 -s на другом конце, который вы контролируете. Против произвольного сайта его не запустить — зато он идеально подходит как контрольная точка: свой VPS в нужной локации, к которому вы гоняете iperf3, показывает, действительно ли ваш канал в целом способен выдать заявленную скорость, независимо от того, что происходит с конкретным сервисом. Подробный разбор параметров (-P для параллельных потоков, -u для UDP-теста с оценкой джиттера, -R для реверс-режима) — в статье про измерение скорости через iperf3, там же нюансы, из-за которых один поток TCP может занижать реальную пропускную способность канала.

speedtest-cli / speedtest от Ookla — быстрый способ сравнить скорость к разным независимым серверам без своей инфраструктуры:

speedtest --list                  # список ближайших серверов
speedtest --server-id=12345       # тест к конкретному серверу по ID —
speedtest --server-id=67890       # так можно сравнить несколько сетей подряд

Ограничение: speedtest-серверы не связаны с проблемным сервисом напрямую, поэтому полезны только как контроль общей пропускной способности канала, а не как прямая проверка скорости к сервису.

curl -w — самый гибкий инструмент именно для замера к конкретному хосту сервиса, потому что curl умеет ходить по HTTPS с реальным SNI (то есть воспроизводит именно то поведение, которое видит DPI провайдера) и выдавать точные тайминги:

curl -o /dev/null -s -w \
  "dns: %{time_namelookup}s  connect: %{time_connect}s  tls: %{time_appconnect}s  ttfb: %{time_starttransfer}s  total: %{time_total}s  size: %{size_download} bytes  speed: %{speed_download} B/s\n" \
  https://проблемный-сервис.example/крупный-файл

Полезно обернуть такой вызов в цикл с sleep между итерациями и меткой времени через date -u, перенаправив вывод в файл (| tee -a throttle-log.txt) — так набирается серия замеров за несколько часов или дней, а не одна случайная точка, и по логу видно, коррелирует ли просадка с временем суток и насколько она специфична для одного адреса.

Как задокументировать результат и что делать дальше

Для разговора с поддержкой провайдера полезна не пересказанная история, а таблица с сырыми данными: время замера, цель, инструмент, результат напрямую и через VPN. Конкретные цифры каждый получит свои — они сильно зависят от тарифа, локации и самого сервиса, поэтому подставляйте только реальные результаты своих замеров, а не ориентировочные числа. Важна не абсолютная цифра, а паттерн: стабильная просадка именно к одному адресу, которая пропадает при смене классификации трафика (VPN) и не объясняется общей перегрузкой канала (контрольные точки в норме).

С такими данными на руках есть смысл написать в поддержку провайдера с просьбой прокомментировать именно этот маршрут — часто там либо подтверждают известную проблему на конкретном пиринге, либо эскалируют глубже. Если провайдер отказывается признавать проблему, а данные явно указывают на классификацию трафика по домену/SNI, стоит иметь в виду, что в ряде стран действует то или иное регулирование в духе net neutrality, ограничивающее избирательное замедление трафика операторами связи — но это общий факт, а не юридическая консультация: конкретные нормы и порядок обращения сильно различаются по юрисдикциям, и за точной трактовкой стоит обращаться к профильному юристу или в регулятора связи вашей страны, а не полагаться на статью в блоге.

Частые вопросы