Перейти к основному содержанию

Timeweb Cloud

Ичи03.07.2026ХостингХостингVPSTimewebTimeweb CloudЛичный опытОколо 12 минОколо 3484 слов

Timeweb Cloud

Timeweb Cloud - отдельная облачная платформа Timeweb для VPS, серверов, баз данных и инфраструктурных сервисов. Ее лучше не смешивать с обычным Timeweb-хостингом: опыт по Cloud хороший, но риски и инциденты у него другие.

Контекст использования

Timeweb Cloud - один из основных вариантов для VPS и серверов, когда важны стабильность, удобство и быстрая техническая поддержка.

В работе примерно 20-40 серверов у разных клиентов. Доступ есть к нескольким клиентским аккаунтам, поэтому впечатление основано не на одном тестовом сервере, а на регулярном использовании.

Плюсы

  • Надежная работа серверов (под сомнением в 2026 году);
  • быстрая техническая поддержка;
  • удобно быстро создавать и обслуживать серверы;
  • подходит для регулярной работы с большим количеством клиентских проектов;
  • есть российские локации, по которым поддержка подтверждала соответствие 152-ФЗ.

Минусы и риски

  • В июне 2026 года у Timeweb Cloud была серия DDoS-атак и сетевых деградаций;
  • у Timeweb Cloud бывают разные аварии и инциденты, которые они сами публикуют;
  • из-за атак и проблем дата-центра могут быть внешние риски, даже если сами серверы продолжают работать стабильно;
  • на слабых VPS нужно сразу закрывать базовую защиту, иначе агрессивное сканирование может быстро положить сервер;
  • по публичным источникам встречаются жалобы на частые инциденты, сетевые проблемы, спорную коммуникацию по авариям и неочевидный порядок получения компенсаций по SLA;
  • по 187-ФЗ и лицензиям ФСБ подтверждений нет: по ответу поддержки, таких лицензий у Timeweb Cloud нет.

Наблюдения и инциденты

В последнее время у Timeweb Cloud часто видны какие-то трудности и алерты, но по текущему личному опыту в этом году заметных проблем было немного.

Что было зафиксировано:

  • один раз тупила облачная база данных, но причина осталась не до конца понятной;
  • один сервер попал под DDoS или агрессивное сканирование: пытались подбирать пароли, получить .env и другие чувствительные файлы;
  • нагрузка доходила примерно до 1000 одновременных запросов;
  • самая слабая VDS такую нагрузку не вывозила;
  • после настройки fail2ban проблема была решена.

Вывод: даже если платформа работает стабильно, на слабых VPS нужно сразу закрывать базовую защиту: SSH, пароли, лимиты запросов, fail2ban, firewall и запрет доступа к служебным файлам вроде .env.

В сетевых тестах ниже скорость пересчитана в соответствие лимиту: процент от заявленного канала и фактическое значение в скобках. Например, 190/200 Мбит/с - это 95% лимита 200 Мбит/с. Для европейских тарифов используется лимит 200 Мбит/с, для российских Cloud-тарифов - 1 Гбит/с.

Тест Euro-5 Frankfurt

23 июня 2026 года был запущен тест сервера Timeweb Cloud в локации Frankfurt на тарифе Euro-5. Конфигурация: 4 vCPU по 3.3 ГГц, 8 ГБ RAM, 80 ГБ NVMe. Цена сервера - 2760 рублей в месяц, отдельно оплачивается IPv4, 180 рублей в месяц. Заявленный интернет-канал - 200 Мбит/с.

ПроверкаРезультат
ОСUbuntu 24.04.4 LTS
CPUAMD EPYC Processor, 4 потока
RAM7.8 GiB
Диск79G root-раздел, на момент теста было свободно 5.6G
Ближайшая внешняя точкаоколо 7.4 ms, потерь нет
Ya.ruоколо 54.1 ms, потерь нет
MTS Москваоколо 42.2 ms через ping, около 41.8 ms в mtr, потерь на конечной точке нет
Точка iperf3Upload с VPSDownload на VPS
Москва98% (195/200 Мбит/с)96% (191/200 Мбит/с)
Нижний Новгород97% (194/200 Мбит/с)97% (193/200 Мбит/с)
Тюмень93% (186/200 Мбит/с)94% (187/200 Мбит/с)
Франция, Париж99% (197/200 Мбит/с)96% (192/200 Мбит/с)
Нидерланды9% (18/200 Мбит/с)98% (196/200 Мбит/с)
США, Калифорниясервер был занятсервер был занят

По маршрутам сервер действительно выглядит как Frankfurt: трасса до московской точки идет через Frankfurt / RETN / Telia и дальше в сеть МТС. Для европейской локации задержка до Москвы около 42 ms выглядит хорошей. iperf3 в большинстве направлений дает 93-99% от лимита 200 Мбит/с, то есть заявленный канал в целом подтверждается. Исключение - upload в Нидерланды, где был сильный провал и много retransmits; такие сетевые результаты лучше перепроверять в другое время. Производительность диска, CPU и памяти нужно оценить отдельным прогоном с установленными fio и sysbench.

Тест Cloud NL-15 Amsterdam

23 июня 2026 года был запущен тест сервера Timeweb Cloud в локации Amsterdam (AMS-1) на тарифе Cloud NL-15. Конфигурация: 1 vCPU по 3.3 ГГц, 1 ГБ RAM, 15 ГБ NVMe. Цена сервера - 720 рублей в месяц, отдельно оплачивается IPv4 за 180 рублей в месяц.

ПроверкаРезультат
ОСDebian GNU/Linux 13 (trixie)
CPUQEMU Virtual CPU version 8.2.0, 1 поток
RAM967 MiB
Диск15G root-раздел, на момент теста было свободно 12G
Ближайшая внешняя точкаоколо 8.1 ms через ping, около 7.8 ms в mtr, потерь на конечной точке нет
Ya.ruоколо 43.9 ms через ping, около 40.6 ms в mtr, потерь на конечной точке нет
MTS Москваоколо 45.1 ms через ping, около 43.5 ms в mtr, потерь на конечной точке нет

Автоматический тест российских iperf3-серверов через itdoginfo:

ГородDownloadUploadPing
Москва94% (188.8/200 Мбит/с)159% (318.8/200 Мбит/с)46 ms
Санкт-Петербург99% (198.1/200 Мбит/с)155% (309.8/200 Мбит/с)34 ms
Нижний Новгород87% (174.1/200 Мбит/с)161% (321.1/200 Мбит/с)48 ms
Челябинск83% (165.4/200 Мбит/с)158% (316.9/200 Мбит/с)66 ms
Тюмень79% (157.5/200 Мбит/с)155% (309.4/200 Мбит/с)65 ms

Ручные проверки iperf3:

Точка iperf3Upload с VPSDownload на VPS
Москва98% (195/200 Мбит/с)95% (190/200 Мбит/с)
Нижний Новгород97% (193/200 Мбит/с)95% (190/200 Мбит/с)
Тюмень96% (191/200 Мбит/с)94% (188/200 Мбит/с)
Франция, Париж99% (198/200 Мбит/с)96% (192/200 Мбит/с)
Нидерландысервер был занят98% (195/200 Мбит/с)
США, Калифорниясервер был занятсервер был занят
Тест диска fioРезультат
Последовательная запись652 MiB/s
Последовательное чтение2609 MiB/s
Случайное чтение 4K2551 IOPS, 9.96 MiB/s
Случайная запись 4K1088 IOPS, 4353 KiB/s
Тест sysbenchРезультат
CPU, 1 поток543-573 events/s
Память, 1 поток4406 MiB/s

По маршрутам сервер выглядит как Amsterdam: трасса до московской точки идет через Amsterdam / Cogent / Telia и дальше в сеть МТС. Для локации в Нидерландах задержка до Москвы около 43-45 ms близка к Frankfurt-тесту. Сеть на минимальном тарифе выглядит сильной: ручной iperf3 дает 94-99% от лимита 200 Мбит/с, а быстрый itdoginfo-тест по upload местами показывает результат выше лимита, что лучше считать особенностью методики и маршрута, а не гарантированной постоянной скоростью. Ограничение тарифа скорее в ресурсах: 1 vCPU и 1 ГБ RAM подойдут для небольших сервисов, но без запаса по памяти.

Тест Cloud-50 SPB-3

23 июня 2026 года был запущен тест сервера Timeweb Cloud в локации SPB-3 на тарифе Cloud-50. Конфигурация: 2 vCPU по 3.3 ГГц, 4 ГБ RAM, 50 ГБ NVMe. Цена сервера - 1000 рублей в месяц, отдельно оплачивается IPv4 за 180 рублей в месяц.

ПроверкаРезультат
ОСDebian GNU/Linux 13 (trixie)
CPUQEMU Virtual CPU version 4.2.0, 2 потока
RAM3.8 GiB, swap 2.0 GiB
Диск50G root-раздел, занято 72%
Ближайшая внешняя точкаоколо 11.8 ms через ping, около 11.7 ms в mtr, потерь на конечной точке нет
Ya.ruоколо 11.7 ms через ping, около 15.3 ms в mtr, потерь на конечной точке нет
MTS Москваоколо 13.1 ms через ping, около 13.9 ms в mtr, потерь на конечной точке нет

Автоматический тест российских iperf3-серверов через itdoginfo:

ГородDownloadUploadPing
Москва108% (1083.9/1000 Мбит/с)127% (1274.0/1000 Мбит/с)9 ms
Санкт-Петербург112% (1115.1/1000 Мбит/с)132% (1315.9/1000 Мбит/с)2 ms
Нижний Новгород101% (1011.0/1000 Мбит/с)123% (1229.3/1000 Мбит/с)23 ms
Челябинск89% (893.6/1000 Мбит/с)109% (1093.9/1000 Мбит/с)35 ms
Тюмень91% (905.7/1000 Мбит/с)107% (1073.2/1000 Мбит/с)28 ms

Ручные проверки iperf3:

Точка iperf3Upload с VPSDownload на VPS
Москва99% (989/1000 Мбит/с)94% (944/1000 Мбит/с)
Нижний Новгород95% (953/1000 Мбит/с)95% (946/1000 Мбит/с)
Тюмень97% (966/1000 Мбит/с)94% (937/1000 Мбит/с)
Франция, Париж95% (948/1000 Мбит/с)92% (922/1000 Мбит/с)
Нидерландыconnection reset96% (957/1000 Мбит/с)
США, Калифорниясервер был занятсервер был занят
Тест диска fioРезультат
Последовательная запись331 MiB/s
Последовательное чтение1707 MiB/s
Случайное чтение 4K3595 IOPS, 14.0 MiB/s
Случайная запись 4K1539 IOPS, 6157 KiB/s
Тест sysbenchРезультат
CPU, 1 поток300 events/s
CPU, 2 потока543 events/s
Память, 2 потока3290 MiB/s

Для российских направлений SPB-3 заметно быстрее европейских локаций: задержка до Москвы около 13 ms, до Санкт-Петербурга в itdoginfo около 2 ms, а ручной iperf3 по России дает 94-99% от лимита 1 Гбит/с. Сеть выглядит как главный плюс этого тарифа. По CPU результат скромнее, чем у Amsterdam на одном потоке, поэтому для CPU-зависимых задач этот вариант стоит сравнивать с другими тарифами Timeweb Cloud, а для сетевых задач внутри РФ он выглядит заметно сильнее.

Тест Cloud MSK 15 MSK-1

23 июня 2026 года был запущен тест сервера Timeweb Cloud в локации MSK-1 на тарифе Cloud MSK 15. Конфигурация: 1 vCPU по 3.3 ГГц, 1 ГБ RAM, 15 ГБ NVMe. Цена сервера - 350 рублей в месяц, отдельно оплачивается IPv4 за 180 рублей в месяц. Заявленный интернет-канал - 1 Гбит/с.

ПроверкаРезультат
ОСUbuntu 22.04.5 LTS; скрипт рассчитан на Debian 13, поэтому тест шел в best-effort режиме
CPUQEMU Virtual CPU version 8.2.0, 1 поток
RAM957 MiB, swap не включен
Диск15G root-раздел, на момент теста было свободно 11G
Московская точка MTSоколо 1.9 ms через ping; в mtr были ICMP-потери на конечной точке, поэтому маршрут лучше перепроверить повторно
Ya.ru и публичный DNSICMP-тесты были нестабильными: часть ответов шла быстро, часть с большими задержками и потерями

Автоматический тест российских iperf3-серверов через itdoginfo:

ГородDownloadUploadPing
Москва112% (1120.4/1000 Мбит/с)127% (1270.0/1000 Мбит/с)1 ms
Санкт-Петербург90% (895.2/1000 Мбит/с)104% (1044.6/1000 Мбит/с)9 ms
Нижний Новгород103% (1027.9/1000 Мбит/с)116% (1162.0/1000 Мбит/с)6 ms
Челябинск76% (760.4/1000 Мбит/с)89% (894.0/1000 Мбит/с)22 ms
Тюмень89% (889.3/1000 Мбит/с)107% (1071.8/1000 Мбит/с)35 ms

Ручные проверки iperf3:

Точка iperf3Upload с VPSDownload на VPS
Москва100% (1000/1000 Мбит/с)96% (959/1000 Мбит/с)
Нижний Новгород63% (631/1000 Мбит/с)<1% (6/1000 Мбит/с), аномалия теста
Тюмень93% (927/1000 Мбит/с)<1% (3/1000 Мбит/с), аномалия теста
Франция, Париж65% (653/1000 Мбит/с)тест завис
Нидерландыошибка тестасервер был занят
США, Калифорниясервер был занятсервер был занят
Тест диска fioРезультат
Последовательная запись1300 MiB/s
Последовательное чтение4540 MiB/s
Случайное чтение 4K6888 IOPS, 26.9 MiB/s
Случайная запись 4K2961 IOPS, 11.6 MiB/s
Тест sysbenchРезультат
CPU, 1 поток910-927 events/s
Память, 1 поток4720 MiB/s

По MSK-1 видно сильное соответствие заявленному каналу на московском направлении: ручной iperf3 дал 96-100% от лимита 1 Гбит/с, а быстрый itdoginfo-тест по российским точкам показал 76-127% от лимита в зависимости от города и направления. При этом отдельные ручные download-тесты до Нижнего Новгорода и Тюмени провалились почти до нуля, а ICMP-тесты к Ya.ru и публичному DNS были нестабильными. Поэтому сетевой вывод по MSK-1 лучше формулировать осторожно: московское направление выглядит отлично, российская сеть в itdoginfo тоже сильная, но проблемные ручные направления стоит повторить в другое время. По CPU, памяти и NVMe минимальный тариф выглядит заметно бодрее, чем можно ожидать от 1 vCPU и 1 ГБ RAM.

Публичные проблемы

Проверка публичных источников 30 июня 2026 года показывает, что проблемы у Timeweb Cloud лучше считать не единичными отзывами, а отдельным фактором риска для рабочих проектов. В июне совпали сразу два типа риска: DDoS-атаки на инфраструктуру и аварии в нидерландской зоне ams-1.

Официальный статус

На странице статуса сервисов Timeweb Cloud на момент проверки 30 июня 2026 года были отмечены minor_problems по облачным серверам, S3, Kubernetes, DBaaS, балансировщикам, приложениям, VPC, container registry, бэкапам и части других сервисов. По выделенным серверам зона ams-1 отображалась как unavailable.

Это важное уточнение: статус-страница показывает не "все лежит", а разные уровни деградации по типам услуг и зонам. Для выбора площадки это все равно существенный риск, потому что один и тот же инцидент в дата-центре может по-разному задеть VPS, выделенные серверы, сеть, бэкапы и панель управления.

DDoS в июне 2026

В официальном канале Timeweb Cloud Alerts в июне 2026 года опубликована серия уведомлений о DDoS-атаках. Это именно Cloud-инциденты, их не стоит автоматически переносить на обычный Timeweb-хостинг.

По публичным сообщениям картина такая:

ДатаЧто былоВосстановление
5 июня 2026DDoS по локациям SPB и MSKсети восстановлены, атака отражена в 18:15 мск
6 июня 2026повторный DDoS по SPB и MSKсети восстановлены, атака отражена в 20:30 мск
7 июня 2026повторный DDoS по SPB и MSKсети восстановлены, атака отражена в 22:30 мск
21 июня 2026DDoS на большое количество подсетей, позже уточнили, что затронуты все локацииработа сети нормализована, атака окончена в 17:30 мск
22-23 июня 2026волна DDoSатака окончена 23 июня в 3:50 мск
23 июня 2026новая волна DDoSатака окончена в 19:15 мск
24 июня 2026новая волна DDoSатака окончена в 20:00 мск
25 июня 2026DDoS-атака на инфраструктуру емкостью до 3 Тбит/сработа сети нормализована, атака окончена в 21:45 мск
26 июня 2026новая DDoS-атака на инфраструктурув Alerts-канале рядом с ней шли сообщения о Major-инциденте ams-1
29 июня 2026DDoS-атака на инфраструктурушла параллельно с повторным инцидентом ams-1
30 июня 2026DDoS-атака на инфраструктуруна момент проверки отдельного сообщения о полном завершении еще не было

Практический вывод: для важных проектов на Timeweb Cloud нужно не только смотреть SLA, но и подписаться на страницу статуса / Alerts-канал, заранее разнести бэкапы, мониторинг и план переезда по независимым площадкам. Для сетевых задач это отдельный риск: даже если виртуальная машина сама жива, атака на локацию может давать деградацию маршрутов или временную недоступность.

Инциденты ams-1 и Qupra

Отдельный июньский риск - зона ams-1 в Нидерландах. По официальным сообщениям Timeweb Cloud, инциденты были связаны с дата-центром Qupra и системой кондиционирования.

ДатаЧто былоСтатус по официальным сообщениям
26 июня 2026Major-инцидент ams-1, сетевая недоступность в Нидерландахк вечеру сообщили о поэтапном восстановлении и закрыли инцидент
29 июня 2026, утроповторная сетевая недоступность ams-1, проблема в системе кондиционирования Qupraв тот же день инцидент закрыли
29 июня 2026, вечерповторный инцидент на системе кондиционирования Qupraсообщали о снижении нагрузки, возможном замедлении и кратковременной недоступности сервисов
30 июня 2026аварийно-восстановительные работы продолжалисьподрядчик получил запчасти для чиллера, позже к ЦОД доставили мобильный чиллер

В официальном канале Timeweb 30 июня отдельно вышел пост "Про перегретый дата-центр": Timeweb написал, что сценарий отказа нового ЦОД из-за чиллеров был неожиданным, обслуживание со стороны цепочки подрядчиков Qupra идет медленно и без конкретики по срокам, а сам Timeweb запускает поиск нового ЦОД и дальнейшей миграции оборудования. Это сильный сигнал: проблема не ограничилась разовым сетевым сбоем, а дошла до вопроса о смене площадки.

Публичная дискуссия и компенсации

На Habr 30 июня 2026 года появилась пользовательская публикация "Почему я ухожу из Timeweb Cloud: как стабильный хостинг превратился в источник проблем". Автор писал про повторяющиеся проблемы с VPS в ams-1, недоступность около 46 часов, претензии к уведомлениям и к понятности SLA-компенсаций. Это пользовательская оценка, а не официальная статистика, но она совпадает по теме и датам с официальными сообщениями про ams-1.

В комментариях к этой публикации аккаунт Timeweb Cloud ответил, что постмортем по майскому инциденту задержался из-за фокуса на решении текущей ситуации, а все компенсации за май уже произведены или находятся на этапе согласования. Также Timeweb написал, что по аварии 26 июня компенсации будут обработаны в течение 30 дней, а заявление можно подать через тикет в панели управления.

Практический вывод: если проект критичен к доступности, заранее нужно понимать не только SLA на бумаге, но и процедуру получения компенсации: что считается инцидентом, куда подавать запрос, какой срок рассмотрения и какие данные нужно приложить.

Официальные разборы Timeweb Cloud

В официальном канале Timeweb Cloud опубликован разбор нескольких инфраструктурных проблем за последние месяцы:

  • февраль: инцидент в ЦОД во Франкфурте из-за возгорания на площадке, полного отключения питания и закрытого доступа к стойкам примерно на 2 часа;
  • март: сетевые атаки новых масштабов и паттернов с пиками 1, 2, 14 и 16 марта;
  • 24 марта: сбой на уровне гипервизоров из-за флапа сети в московских стойках, зависших RDMA-сессий на стороне СХД, потери связности на 15 нодах и эвакуации части виртуальных машин;
  • 9-10 апреля: сбой на уровне СХД из-за софтового бага, который проявился под production-нагрузкой;
  • 4 мая: ошибка в БД во время плановых работ, которая привела к некорректным балансам и блокировкам.

Плюс здесь в том, что провайдер начал публично разбирать инфраструктурные сбои и писать, что именно меняет. Минус в том, что набор инцидентов сам по себе подтверждает: у Cloud сейчас есть заметный период турбулентности.

Пользовательские жалобы

Из внешних отзывов и публикаций повторяются несколько тем:

  • частые падения или деградации серверов на коротком промежутке времени;
  • жалобы на то, что пользователь узнает о проблеме не из уведомлений провайдера, а по факту недоступности сервиса или вручную через статус-страницу;
  • вопросы к тому, как на практике получить компенсацию по SLA;
  • сетевые проблемы с IP-адресами, DHCP, приватными сетями и RDP-сценариями;
  • спорные ответы поддержки в случаях, где пользователь считает проблему инфраструктурной, а не клиентской.

Это не означает, что каждый такой отзыв автоматически подтверждает массовую проблему. Но для выбора провайдера это полезные сигналы: перед размещением критичного проекта лучше заранее проверить уведомления, условия SLA, порядок компенсаций, работу приватных сетей, резервное копирование и план быстрого переезда.

Сертификация и 152-ФЗ

У Timeweb Cloud есть публичная страница про облако 152-ФЗ. На ней заявлено, что инфраструктура с серверами на территории РФ соответствует требованиям для информационных систем до УЗ-1 включительно.

Также 16 марта 2026 найдена формулировка про безопасное хранение данных: данные хранятся в защищенном виде в соответствии с требованиями 152-ФЗ, GDPR, индустриальных стандартов ISO и PCI DSS.

Практически это важно потому, что 152-ФЗ требует локализации персональных данных граждан РФ: при сборе такие данные должны записываться и храниться с использованием баз данных на территории России. Поэтому заявленное соответствие 152-ФЗ имеет смысл не только как "безопасность", но и как подтверждение российской локализации данных для подходящих сценариев.

По ответу поддержки от 16 марта 2026, все серверы, которые создаются в российских локациях Timeweb Cloud, соответствуют 152-ФЗ. Речь о локациях:

  • Москва;
  • Санкт-Петербург;
  • Новосибирск.

Акт оценки эффективности реализованных мер защиты персональных данных по приказу ФСТЭК России № 21 от 18 февраля 2013 г. доступен в PDF: cert-3.pdf.

В акте указано, что система защиты информационной системы «Платформа ТАЙМВЭБ.КЛАУД» соответствует требованиям к составу и содержанию мер по обеспечению безопасности персональных данных для 1-го уровня защищенности (УЗ-1). Также отдельно указано разграничение зон ответственности: часть мер обеспечивает Timeweb Cloud, а часть остается на стороне клиента и его виртуальных машин, сетей, сайтов, баз данных и прикладного ПО.

Поддержка также сообщила, что платформу можно проверить в реестре на сайте reestr.digital.gov.ru.

Итог

Timeweb Cloud остается рабочим вариантом для VPS и клиентских проектов, когда нужны удобная панель, российские локации и быстрая поддержка, но после июньских инцидентов его нельзя считать вариантом "поставил и забыл". Для важных проектов нужно заранее разносить бэкапы, мониторинг и план переезда, а зарубежные зоны вроде ams-1 проверять особенно осторожно.

Связанные материалы

Источники