Хостер сменил аплинк, маршрут изменился, задержка выросла: что может сделать клиент

MAATRIX

Однажды утром сайт или API, который месяцами работал стабильно, вдруг начинает откликаться на 30-60 мс дольше обычного — не упал, не тормозит критично, просто стал ощутимо «тяжелее». В логах хостера — сухая строчка о плановых работах на сети или вообще ничего. Причина в девяти случаях из десяти банальна: хостер сменил вышестоящего транзитного оператора (аплинк), маршрут вашего трафика до пользователей изменился, а новый путь оказался для вашей конкретной аудитории хуже старого. Разберём, почему это происходит, почему клиент не может на это повлиять и что делать, когда это уже случилось.

Что физически происходит, когда хостер меняет аплинк

У любого хостинга сеть подключена к остальному интернету не напрямую, а через одного или нескольких вышестоящих операторов связи (upstream, в разговоре — «аплинк»). Именно аплинк передаёт трафик хостера дальше, до сетей, где сидят конечные пользователи — провайдеров, мобильных операторов, других дата-центров. У аплинка, в свою очередь, есть собственные договорённости о пиринге и транзите с тысячами других сетей по всему миру, и качество маршрута до конкретного города или страны зависит именно от того, как этот аплинк с ними связан.

Когда хостер меняет основного аплинка — по коммерческим причинам (истёк контракт, предложили более выгодную цену за трафик), по техническим (у прежнего оператора участились сбои) или из-за расширения (пришёл новый оператор в дата-центр, старый стал избыточен) — меняется не «скорость интернета» в абстрактном смысле, а конкретный набор маршрутов BGP, по которым трафик хостера уходит наружу. Новый аплинк может отлично пиниться с одними регионами и посредственно — с другими, где старый работал безупречно. Разница не будет заметна всем клиентам одинаково: она проявится именно там, где расходятся качество маршрутов старого и нового аплинка.

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

Почему хуже стало не у всех клиентов одинаково

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

Причина в географии пиринга. Старый аплинк мог иметь прямое, хорошо загруженное соединение с крупным оператором в конкретной стране или регионе — трафик до пользователей этого оператора шёл коротким путём с минимальным числом промежуточных сетей. Новый аплинк с тем же оператором может пиниться хуже: транзитом через третью сеть, с меньшей пропускной способностью на стыке или просто географически более длинным путём. Для пользователей других операторов, которых новый аплинк как раз обслуживает лучше старого, ничего не изменится или даже станет быстрее.

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

Это решение полностью вне контроля клиента

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

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

Шаг 1: зафиксировать деградацию цифрами, а не на глаз

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

Базовый инструмент — mtr, который в отличие от разового traceroute собирает статистику по каждому узлу маршрута за минуты, а не даёт один случайный снимок; подробно про то, как читать его колонки и не обвинить в проблеме невиновный промежуточный узел, разобрано в статье про mtr вместо traceroute. Ключевая практическая задача здесь — не разовый запуск, а сравнение «было / стало», поэтому важно сохранять результаты с датой:

# отчётный режим mtr: 100 пакетов, без резолвинга DNS,
# результат сразу пишем в файл с датой в имени
mtr -rw -c 100 -n ваш-целевой-хост.example.com > mtr-$(date +%F_%H%M).txt

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

# каждые 4 часа снимать mtr-отчёт до ключевого направления
0 */4 * * * mtr -rw -c 50 -n ваш-хост.example.com >> /var/log/mtr-history.log 2>&1

Параллельно полезен долгий ping с логированием — он проще mtr, но нагляднее показывает динамику именно задержки во времени, а не только распределение по хопам:

ping -D ваш-хост.example.com | tee -a ping-history-$(date +%F).log

Если есть возможность сравнить показания с нескольких точек — например, попросить коллегу или клиента из другого региона тоже прогнать mtr до того же сервера — это резко усиливает аргументацию: разница между «у всех стало хуже одинаково» и «хуже только у пользователей одного региона/оператора» напрямую указывает на природу проблемы и облегчает разговор с поддержкой хостера. Стоит также сохранить, если они были, скриншоты или логи мониторинга (Zabbix, Grafana, Uptime Kuma и подобные) за период до и после предполагаемой смены аплинка — это ещё один независимый источник данных с готовой временной меткой.

Шаг 2: идти в поддержку с данными, а не с ощущением

Обращение с конкретными цифрами и файлами mtr/ping меняет разговор с поддержкой качественно. Вместо «у вас всё тормозит» появляется предметный запрос: «с даты X по маршруту до сети Y задержка выросла с A до B мс, вот отчёты mtr за оба периода, что изменилось на вашей стороне сети в этот период?»

Практический смысл такого обращения — не только пожаловаться, а получить у хостера три вещи:

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

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

Шаг 3: если хостер не чинит — реалистичные альтернативы

Если ответ от поддержки — «да, аплинк сменился осознанно, откатывать не будем», у клиента остаётся не так много рычагов, но они реальны.

Смена дата-центра или провайдера. Радикальный, но иногда единственный вариант, если деградация критична для бизнеса — например, задержка напрямую бьёт по конверсии интернет-магазина или по отзывчивости real-time сервиса. Прежде чем переезжать, стоит трезво оценить масштаб: если задержка выросла на единицы-десятки миллисекунд и не приближается к порогу, за которым начинаются реальные потери (у разных типов сервисов этот порог свой и его нужно оценивать по факту, а не по ощущению «стало хуже»), миграция может обойтись дороже проблемы, которую она решает. Если решаетесь на переезд — стоит заранее прогнать mtr до нового кандидата из тех же проблемных регионов, чтобы не наступить на те же грабли ещё раз.

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

Точечная оптимизация без переезда. Иногда полезно снизить чувствительность приложения к возросшей задержке, не трогая инфраструктуру: сжатие ответов, снижение числа round-trip'ов на страницу, keep-alive соединения, HTTP/2 или HTTP/3 вместо HTTP/1.1 там, где это применимо. Это не устраняет причину, но иногда достаточно смягчает следствие, особенно если рост задержки не катастрофичен.

Как отличить временную деградацию от постоянной

Не всякий рост задержки после смены аплинка — это навсегда. Сети переходят на нового оператора не мгновенно: анонсы BGP донастраиваются, часть трафика может первое время идти через временные или неоптимальные пути, пока инженеры хостера не доведут маршрутизацию до финального состояния. Отличить временный переходный период от постоянного результата снаружи напрямую нельзя — но несколько практических признаков помогают сориентироваться:

Продолжать замеры mtr/ping в течение хотя бы двух-трёх недель после первого обнаружения проблемы — не лишняя предосторожность, а единственный способ отличить одно от другого объективно, а не гадать по одному разговору с поддержкой.

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