FirstVDS: Неадекватный ST, кривая маршрутизация трафика, газлайтинг, хамство начальника поддержки и просто ложь (часть 1)
«Продаем "воздушные замки" (вероятный оверселлинг, деградация оборудования или шейпинг), занимаемся газлайтингом, хамим и спорим с технически подкованным клиентом, даже когда у него доказательства обмана и недобросовестного поведения со стороны компании» - предложение для рекламного лозунга FirstVDS
В этой статье я хочу рассказать частный случай, как поддержка FirstVDS и ее начальство вводит клиентов в заблуждение и введет себя некорректно, с чем может столкнуться любой клиент этого провайдера.
Предыстория конфликта
Являюсь клиентом FirstVDS с 2023 года. Пользуюсь двумя серверами. Один из них находится на IP 213.159.215.203 (в основном речь в статье будет об этом сервере, ID - 14064327, тариф VDS-KVM-SSD-Восток-2.0) и на IP 62.109.30.243 (тариф VDS-KVM-SSD-Восток-3.0, ID - 15355913).
На основном сервере (213.159.215.203) у меня несколько сайтов, почтовый сервер (который, в основном, простаивает) и другое по мелочи. Конкретно этот VDS я арендую с 2024 года и до марта 2026 года с ним проблем не было.
Еще в 2024 году на этом сервере настроил выделенные сервера для Euro Truck Simulator 2 и American Truck Simulator. Дата-центр провайдера находится в Москве, я территориально нахожусь в Брянске, провайдер интернета - Билайн (к ним у меня претензий нет, далее в статье объясню наглядно почему), компьютер подключен по проводу к роутеру, тариф на 500мбит/с - выше, чем у самого VDS.
До марта 2026 года у меня пинг в игре был около 12мс в среднем. Я временно отключил сервера ATS и ETS2, т.к. искал причину вылета сессий в мультиплеере (оказалось, что это знаменитый баг в ATS версии 1.58 с Топикой (Штат Канзас), где игроков в мультиплеере выкидывает, но на поиск причины я потратил пару недель).
После диагностики и выяснения причин я включил сервера обратно и увидел такую картинку
Вместо привычных 12мс я увидел показатели около 50мс. Первое, о чем я подумал - надо проверить настройки подключения. Проверил, но учитывая, что я там ничего не менял странно было бы найти что-то новое, но для очистки совести я это попытался сделать. Конечно, я не мог сразу обвинить FirstVDS в высоком пинге и мне нужно было провести диагностику и исключить проблемы на моей стороне, чем я далее и занялся.
Эпизод 1: Диагностика
Диагностика перед обращением к техподдержке
Первым делом я начал проверять маршрутизацию, то есть как идут пакеты от меня к серверу и обратно.
Пинг к моему серверу выдает в среднем 30 мс, при этом на втором сервере пинг остался прежним. Это уже был тревожный звоночек, но он до конца не объяснял, почему пинг в игре 50мс. Нужно было искать другие источники потерь. Тогда я решил использовать команду top. Она и дала ответ по поводу причин.
На скрине видно, что ST (Steal Time) имеет значение 3,1 в момент создания скриншота (забегая вперед скажу, что это еще "цветочки" по значению, "ягодки" будут позже). На втором сервере ST был низким - не рос выше 1, что является нормой в индустрии.
Коротко о том что такое Steal Time и почему это важно для VPS/VDS:
Steal Time (украденное время) — это время, в которое ваш виртуальный сервер (VDS) хотел выполнить задачу, но не смог, потому что физический процессор (CPU) в этот момент был занят задачами «соседей» по хостингу.
Почему это важно для VDS?
VDS — это лишь часть мощного сервера. Хостер делит ресурсы одного «железного» процессора между несколькими клиентами. Если Steal Time высокий, значит, ваш сервер тормозит не из-за своих нагрузок, а потому что ему банально не дают работать.
Как он влияет на пинг?
Напрямую. Чтобы сервер ответил на сетевой пакет, процессор должен его обработать. Если в этот микромомент CPU «украден» соседом, ваш пакет встает в очередь. Результат: Пинг становится нестабильным (скачет), появляются «лаги» и фризы в играх или при работе терминала, хотя канал связи может быть идеальным.
Итог для UDP (игровой трафик): Если для сайта лишние 100 мс ожидания из-за Steal Time почти незаметны, то для UDP-трафика даже 2-3% st могут сделать сервис непригодным для комфортного использования.
Здесь еще нужно пояснить несколько моментов поводу ST:
- В ядре Linux значение %st (Steal Time) по определению означает время, когда виртуальный процессор был готов к работе (READY), но гипервизор (хост-машина) не дал ему физических циклов CPU. Вывод: Если ваш софт (игры, сайты) грузит процессор, растет %user или %system. Если растет %st — это процессор «ушел» к другому клиенту.
- Steal Time появляется только тогда, когда сумма запросов на процессорное время от всех VDS на одной ноде превышает 100%. Если бы провайдер честно выделял ядра (1 vCPU = 1 физическое ядро), ST всегда был бы равен 0%, даже если бы вы нагрузили свой сервер на максимум 24/7. Появление %st — это прямое доказательство того, что одно ядро продано нескольким людям. Как я уже сказал ранее - значение до 1 считается нормой, 1-3 - это "визитка" лоукостера, 3 и выше - это уже явный и наглый оверселлинг или шейпинг.
- В облачных технологиях есть термин Noisy Neighbor (шумный сосед). Если ваш пинг скачет из-за ST, значит, провайдер не настроил жесткие лимиты (CPU pinning/cpusets) или сознательно их игнорирует. Факт: Ваша внутренняя нагрузка (голос, трафик) — это ваша очередь задач. ST — это когда саму очередь замораживают, чтобы обслужить соседа.
Дополнительно я проверил как виртуалки "общаются" между собой и здесь роста пинга я не заметил, что логично, т.к. расстояние между ними ничтожно малое, но это доказывает стабильное сетевое подключение до того как трафик покинет дата-центр.
Обращение к поддержке (начало)
Понимая, что проблема выходит за пределы моей зоны ответственности, я обратился в поддержку с просьбой исправить проблему с ST.
Вначале диалог идет корректно, у меня даже запрашивают данные по трассировке, которые я забыл предоставить.
Чтобы не приходилось их искать в скринах я напишу эти данные.
Ко мне со стороны первого (проблемного) сервера
От меня к проблемному серверу (на скрине я это послал оператору в файле)
Ко мне с исправного (второго) сервера:
Данные результаты нам говорят о том, что трафик ко мне с проблемного сервера идет через Европу (Стокгольм или Франкфурт), а с нормального - напрямую подключается к сетям Билайна в Москве.
Для массовой аудитории могу пояснить это так: Когда трафик идет от вас, то за "маршрут" отвечает ваш провайдер (в моем случае это Билайн), когда трафик идет к вам за это отвечает тот кто оправляет. Простая бытовая аналогия - когда вы отправляете груз курьерской доставкой.
Представьте, что интернет-трафик — это поездка на такси. Когда вы едете в гости, маршрут выбирает ваш водитель. Когда гость едет к вам — маршрут выбирает его водитель. В первом тесте «курьер» провайдера зачем-то поехал из Москвы в Москву через Стокгольм (хоп 6 и 7 — это узлы Telia/Arelion в Европе). Это увеличило путь в три раза и добавило потерь. Во втором тесте другой «курьер» (с нормального сервера) поехал по прямой. Провайдер просто сэкономил на прямых стыках с российскими сетями (пиринге), отправив ваши данные по дешевому длинному пути или допустил ошибку при настройке оборудования - оба варианта равновероятны.
Возвращаясь к моей ситуации мы видим, что мой провайдер интернета (Билайн) свои обязанности выполняет добросовестно - он доставил пакеты от меня и ко мне за 11-12 мс.
Техническое доказательство: Почему в высоком пинге виноват FirstVDS, а не Билайн
Анализ трассировок (MTR) в обе стороны (от клиента к серверу и обратно) выявляет классическую асимметрию маршрута и отсутствие прямого пиринга у хостинг-провайдера.
1. Прямой маршрут (от клиента к VDS) — WinMTR
На хопах со 2-го по 6-й (сеть Билайна) мы видим эталонную работу магистрали:
- Хопы 5-6: Узлы 79.104.225.192 и 195.218.178.139. Это пограничные маршрутизаторы Билайна (AS12389).
- Результат: Пинг стабильно держится на отметке 11-12 мс, потери 0%. Это доказывает, что пакет «вылетает» из сети Билайна мгновенно и без повреждений.
- Аномалия: Прыжок задержки до 30 мс происходит только на хопе 213.159.215.203 (точка входа в инфраструктуру хостера). Пакет прошел через всю Москву за 11 мс, но «застрял» на последнем метре у хостера еще на 19 мс.
2. Обратный маршрут (от VDS к клиенту) — Linux MTR
Здесь вскрывается главная экономия провайдера (или ошибка в настройке сетей). Вместо того чтобы отправить ответ по тому же короткому пути, сервер VDS отправляет его «кругосветкой»:
- Транзит через Европу: На 6-м и 7-м хопах (62.115.141.22 и 62.115.139.187) мы видим узлы магистрала Arelion (Telia) в Стокгольме/Франкфурте.
- Доказательство: Пакет возвращается в сеть Билайна (хоп 81.211.14.154) уже с задержкой 30 мс. Билайн получает его «испорченным» из-за границы. Домашний провайдер не может физически ускорить пакет, который пришел к нему по кривому маршруту, выбранному отправителем.
3. Связь со Steal Time
Высокий Steal Time (3% и выше) на этом же сервере дополняет картину «экономии»:
- Провайдер сэкономил на железе, продав одно ядро CPU нескольким клиентам (оверселлинг).
- Провайдер сэкономил на связности, не настроив прямой пиринг (стык) с крупнейшим российским оператором, пустив игровой трафик по дешевым зарубежным транзитам или допустил ошибку в настройке анонса сети (BGP).
Итог: Мы видим ситуацию, когда магистральная сеть Билайна работает идеально (11 мс до границы), но FirstVDS создает «бутылочное горлышко» и в процессоре (ST), и в сети (асимметрия). Это на 100% зона ответственности дата-центра.
Техническая справка: Почему обратный путь выбирает отправитель?
В интернете маршрутизация работает на протоколе BGP (Border Gateway Protocol). Главное правило: каждый провайдер сам решает, через кого отправить исходящий пакет.
- Билайн: Видит кратчайший путь до сети FirstVDS и отправляет пакет напрямую (пинг 11 мс). Он свою работу выполнил.
- FirstVDS: Чтобы пакет вернулся ко мне так же быстро, хостер обязан «анонсировать» (объявить) свои сети напрямую Билайну. Если он этого не сделал (сэкономил на прямом стыке или не настроил фильтры), его маршрутизатор выбирает Default Route — самый дешевый путь через зарубежных транзитных операторов (например, Arelion/Telia).
- Асимметрия: В итоге пакет «туда» идет 11 мс по прямой, а «обратно» — 30 мс через Европу. Исправить это может только администратор сети FirstVDS, изменив приоритеты своих BGP-анонсов или оплатив прямой стык с российскими магистральными провайдерами (Билайн им является).
Вывод: Билайн не может «забрать» пакет у FirstVDS силой. Если FirstVDS выкинул пакет в сторону Стокгольма, Билайн увидит его только тогда, когда тот совершит круг по Европе и вернется в РФ. Это 100% сетевая недоработка на стороне дата-центра.
Эпизод 2: Попытка техподдержки "отфутболить" клиента, перекладывая ответственность на интернет-провайдера (Билайн) и решение проблемы маршрутизации через руководство
После того, как я подробно объяснил свою позицию и провел ликбез, я могу рассказать, что происходило дальше при общении с поддержкой FirstVDS
2026-03-17 06:38:36 я получаю первый "футбол" от поддержки:
Далее идет моя попытка объяснить, почему поддержка не права
Однако это не помогает. Техническую грамотность этого ответа со стороны сотрудника техподдержки я оставляю на вашу оценку:
Системные администраторы (3-я линия поддержки) рассмотрели этот запрос, после чего Вам был дан ответ. Мы не можем скорректировать маршрут и чем-либо помочь в текущей ситуации, к сожалению.
С уважением, Леда
менеджер отдела Заботы о клиентах
FirstVDS
Понимая, что с человеком на таком уровне компетенций вести разговор бесполезно, т.к. он не понимает о чем идет речь или намеренно вводит в заблуждение, я требую передать тикет начальству.
Я предупреждал об огласке, если меня будут "футболить" дежурными отмазками и я действительно не хотел это выносить на публику, но все же пришлось (о причинах скажу, когда дойду до "миграции" VDS). Ссориться с провайдером, которого рекомендовал своим клиентам как системный администратор и которым сам пользовался с 2023 года - последнее, чего я хотел, но поведение поддержки мне не оставило другого выхода.
Менее чем через час в диалог вступает Руководитель отдела Заботы о клиентах Татьяна
Справедливости ради я должен отметить, что проблему с маршрутизацией, которую Татьяна называет "нюансами в маршрутизации", исправили быстро, когда она подключилась к решению проблемы.
Также отдельно замечу, что на скрине явно видно согласие Татьяны перенести мой VDS на другую ноду (это важно для второй части статьи, где я расскажу про миграцию).
Далее проблему с маршрутизацией в целом можно считать решенной
Данные от проблемного сервера ко мне после исправления маршрутизации:
Аномального пути ко мне через Европу больше не наблюдается, трафик передается напрямую Билайну как и должно быть. Однако это решило только проблему с TCP трафиком, который менее чувствителен к ST. Сами значения ST остались высокими, о чем я заявил в поддержке и попросил сделать миграцию на другую ноду, на что от Татьяны уже было получено согласие (запомним, это важно).
Однако когда разговор дошел до миграции VDS на другую ноду на практике поведение Татьяны вышло за рамки адекватного отношения к клиенту.
Продолжение во второй части статьи.